[ANN] Aconcagua - A model of Measures

Hi,
    we create a packaged named Aconcagua at SqueakSource.
    This model represents measures as first class objects, that is, an
object that encapsulates a number with its unit.
    We uploaded a FAQ to its SqueakSource wiki, with some examples. The
model includes almost 600 tests that can be used as examples also.
    We use this model in many of the financial applications we wrote and
it is used by the Gregorian Calendar model we are going to upload soon
(the one presented at ESUG last year).
    The package is going to be available for VisualAge, GemStone,
VisualWorks and Dolphin. (Right now only on Squeak, VisualAge and GemStone).
    There is also a practitioner report we wrote for OOPSLA about this
model:      
(http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CFID=72196433&CFTOKEN=8952623 
<http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CFID=72196433&CFTOKEN=8952623>)
 
    We hope you like it.
    Bye, Hernan.

--
______________________________
Lic. Hernán A. Wilkinson
Gerente de Desarrollo y Tecnología
Mercap S.R.L.
Tacuari 202 - 7mo Piso - Tel: 54-11-4878-1118
Buenos Aires - Argentina
http://www.mercapsoftware.com
---------------------------------------------------------------------
Este mensaje es confidencial. Puede contener informacion amparada
por el secreto profesional. Si usted ha recibido este e-mail por error,
por favor comuniquenoslo inmediatamente via e-mail y tenga la
amabilidad de eliminarlo de su sistema; no debera copiar el mensaje
ni divulgar su contenido a ninguna persona. Muchas gracias.
 
This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by e-mail immediately and
delete it from your system; you should also not copy the message nor
disclose its contents to anyone. Thanks.
 ---------------------------------------------------------------------

This sounds nice. Some comments:

1) I can't load it. Adding the repository via Monticello and trying  
to even select the version in the Monticello browser leads to the  
attached error stack.




I opened the version as a Zip file and loaded snapshot/source.st from  
it directly, instead, but it is inconvenient.

2) How does it relate to Helge Horch's Squeak port of Andrew Brault's  
Dolphin package? Did you know of this package?

http://home.netsurf.de/helge.horch/squeak/units.html

The code looks more elaborate and complicated (350 kb of source is  
not lightweight compared to 51 kb in Helge's package and 21 kb for  
the equivalent Slate code) but has the same class names in several  
places. However, I cannot tell if this complication is valuable or  
wasteful, because there are not enough comments in the source file  
(actually it looks like there are NO comments).

A lot of the extra work appears to be a huge unit-test suite, which  
is good. There is also some kind of graph model and some evaluation/
thunking mini-library. These seem to be useful only for portability  
(since you are not using other equivalent Squeak packages), so you  
may want to separate them for clarity.

I also am not an ACM member, so I cannot read your paper until OOPSLA.

3) I like the MeasureBag idea. Does it work for non-Integer values  
and why or why not?

4) "Measure" suggests measurement, which has precision and tolerance.  
Do you take these into consideration? If not, why name it Measurement  
instead of DimensionedUnit or something? It will be confusing if  
someone makes a separate type system that /does/ handle precision and  
tolerance.

Thanks!

On Mar 27, 2006, at 2:17 PM, Hernan Wilkinson wrote:
-Brian
http://tunes.org/~water/brice.vcf

Hi Brian.

This version of the package can´t be loaded into a 3.8xxx image. The package was created using a 3.9axxx image.
I don´t know why it can't be loaded into a 3.8xxx image, maybe the Monticello packages are not compatibles between 3.9axxx and 3.8xxx images.

If you want, try to load it into a 3.9axxx image.

Regards

Maxi.

Brian Rice escribió:

This sounds nice. Some comments:

1) I can't load it. Adding the repository via Monticello and trying to even select the version in the Monticello browser leads to the attached error stack.

27 March 2006 6:45:10 pm

VM: Mac OS - a SmalltalkImage
Image: Squeak3.8 [latest update: #6665]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir /Users/water/Developer/Squeak
Trusted Dir /Users/water/Developer/Squeak
Untrusted Dir foobar/tooBar/forSqueak/bogus

MCClassDefinition(Object)>>error:
	Receiver: a MCClassDefinition(ArithmeticObject)
	Arguments and temporary variables: 
		aString: 	'Instances of MCClassDefinition are not indexable'
	Receiver's instance variables: 
		name: 	#ArithmeticObject
		superclassName: 	#Object
		variables: 	an OrderedCollection()
		category: 	#'Aconcagua-ArithmeticModel'
		type: 	#normal
		comment: 	''
		commentStamp: 	''

MCClassDefinition(Object)>>errorNotIndexable
	Receiver: a MCClassDefinition(ArithmeticObject)
	Arguments and temporary variables: 

	Receiver's instance variables: 
		name: 	#ArithmeticObject
		superclassName: 	#Object
		variables: 	an OrderedCollection()
		category: 	#'Aconcagua-ArithmeticModel'
		type: 	#normal
		comment: 	''
		commentStamp: 	''

MCClassDefinition(Object)>>size
	Receiver: a MCClassDefinition(ArithmeticObject)
	Arguments and temporary variables: 

	Receiver's instance variables: 
		name: 	#ArithmeticObject
		superclassName: 	#Object
		variables: 	an OrderedCollection()
		category: 	#'Aconcagua-ArithmeticModel'
		type: 	#normal
		comment: 	''
		commentStamp: 	''

MCClassDefinition(Object)>>basicAt:put:
	Receiver: a MCClassDefinition(ArithmeticObject)
	Arguments and temporary variables: 
		index: 	1
		value: 	'{}'
	Receiver's instance variables: 
		name: 	#ArithmeticObject
		superclassName: 	#Object
		variables: 	an OrderedCollection()
		category: 	#'Aconcagua-ArithmeticModel'
		type: 	#normal
		comment: 	''
		commentStamp: 	''


--- The full stack ---
MCClassDefinition(Object)>>error:
MCClassDefinition(Object)>>errorNotIndexable
MCClassDefinition(Object)>>size
MCClassDefinition(Object)>>basicAt:put:
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MCClassDefinition(Object)>>instVarAt:put:
MCClassDefinition(Object)>>readDataFrom:size:
DataStream>>readInstance
DataStream>>next
DataStream>>readArray
DataStream>>next
OrderedCollection(Object)>>readDataFrom:size:
DataStream>>readInstance
DataStream>>next
MCSnapshot(Object)>>readDataFrom:size:
DataStream>>readInstance
DataStream>>next
[] in MCMczReader>>loadDefinitions {[:m | ^ definitions := (DataStream on: m contentStream) next definitions]}
ZipFileMember(Object)>>ifNotNilDo:
MCMczReader>>loadDefinitions
MCMczReader(MCVersionReader)>>definitions
MCMczReader(MCVersionReader)>>snapshot
MCMczReader(MCVersionReader)>>basicVersion
MCMczReader(MCVersionReader)>>version
[] in MCHttpRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: {[:r | r version]}
[] in MCHttpRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: {[:class | aBlock   value: (class on: s)]}
MCMczReader class(Object)>>ifNotNilDo:
[] in MCHttpRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: {[:s | (MCVersionReader readerClassForFileNamed: aString)   ifNotNilDo: [:cla...]}
MCHttpRepository>>readStreamForFileNamed:do:
MCHttpRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do:
MCHttpRepository(MCFileBasedRepository)>>loadVersionFromFileNamed:
[] in MCHttpRepository(MCFileBasedRepository)>>versionFromFileNamed: {[self loadVersionFromFileNamed: aString]}
[] in Dictionary>>at:ifAbsentPut: {[self at: key put: aBlock value]}
Dictionary>>at:ifAbsent:
Dictionary>>at:ifAbsentPut:
MCHttpRepository(MCFileBasedRepository)>>versionFromFileNamed:
MCFileRepositoryInspector>>versionSelection:
PluggableListMorph>>changeModelSelection:
PluggableListMorph>>mouseUp:
PluggableListMorph(Morph)>>handleMouseUp:
MouseButtonEvent>>sentTo:
PluggableListMorph(Morph)>>handleEvent:
PluggableListMorph(Morph)>>handleFocusEvent:
[] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.  ActiveEvent := anEvent.  result := focusHolder     han...]}
[] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
BlockContext>>on:do:
PasteUpMorph>>becomeActiveDuring:
HandMorph>>sendFocusEvent:to:clear:
HandMorph>>sendEvent:focus:clear:
HandMorph>>sendMouseEvent:
HandMorph>>handleEvent:
HandMorph>>processEvents
[] in WorldState>>doOneCycleNowFor: {[:h |  ActiveHand := h.  h processEvents.  capturingGesture := capturingGest...]}
...etc...
  

---

I opened the version as a Zip file and loaded snapshot/source.st from it directly, instead, but it is inconvenient.

2) How does it relate to Helge Horch's Squeak port of Andrew Brault's Dolphin package? Did you know of this package?

http://home.netsurf.de/helge.horch/squeak/units.html

The code looks more elaborate and complicated (350 kb of source is not lightweight compared to 51 kb in Helge's package and 21 kb for the equivalent Slate code) but has the same class names in several places. However, I cannot tell if this complication is valuable or wasteful, because there are not enough comments in the source file (actually it looks like there are NO comments).

A lot of the extra work appears to be a huge unit-test suite, which is good. There is also some kind of graph model and some evaluation/thunking mini-library. These seem to be useful only for portability (since you are not using other equivalent Squeak packages), so you may want to separate them for clarity.

I also am not an ACM member, so I cannot read your paper until OOPSLA.

3) I like the MeasureBag idea. Does it work for non-Integer values and why or why not?

4) "Measure" suggests measurement, which has precision and tolerance. Do you take these into consideration? If not, why name it Measurement instead of DimensionedUnit or something? It will be confusing if someone makes a separate type system that /does/ handle precision and tolerance.

Thanks!

On Mar 27, 2006, at 2:17 PM, Hernan Wilkinson wrote:

Hi,
   we create a packaged named Aconcagua at SqueakSource.
   This model represents measures as first class objects, that is, an object that encapsulates a number with its unit.
   We uploaded a FAQ to its SqueakSource wiki, with some examples. The model includes almost 600 tests that can be used as examples also.
   We use this model in many of the financial applications we wrote and it is used by the Gregorian Calendar model we are going to upload soon (the one presented at ESUG last year).
   The package is going to be available for VisualAge, GemStone, VisualWorks and Dolphin. (Right now only on Squeak, VisualAge and GemStone).
   There is also a practitioner report we wrote for OOPSLA about this model:      (http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CFID=72196433&CFTOKEN=8952623 <http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CFID=72196433&CFTOKEN=8952623>)
   We hope you like it.
   Bye, Hernan.

--
-Brian
http://tunes.org/~water/brice.vcf

--- In [hidden email], Brian Rice <water@...> wrote:
>
> This sounds nice. Some comments:
>
> 1) I can't load it. Adding the repository via Monticello and trying
> to even select the version in the Monticello browser leads to the
> attached error stack.

We created the monticello file with Squeak 3.9Alpha.
I just try it out on 3.8 and it does not work as you say. We will
upload a new file for 3.8. Thanks!!

>
> 2) How does it relate to Helge Horch's Squeak port of Andrew Brault's
> Dolphin package? Did you know of this package?
>
> http://home.netsurf.de/helge.horch/squeak/units.html

I did not know about it. Thank you for the link! We'll take a look.
All the models we know that treat this problem are in the FAQ, under
the question "Are there other models of the same problem?"

>
> The code looks more elaborate and complicated (350 kb of source is
> not lightweight compared to 51 kb in Helge's package and 21 kb for
> the equivalent Slate code) but has the same class names in several
> places. However, I cannot tell if this complication is valuable or
> wasteful, because there are not enough comments in the source file
> (actually it looks like there are NO comments).

Yeah, there are no comments. We are not use to comment the methods, we
only doit when there is something difficult to understand.
Anyhow, you have the test cases, there are plenty of them where you
can look for good examples.
Also, in the FAQ I wrote some examples you may find interesting.

>
> A lot of the extra work appears to be a huge unit-test suite, which
> is good. There is also some kind of graph model and some evaluation/
> thunking mini-library.

Yeah, the graph model (very simple one) is to convert measures from
different "domains". This is usefull when you have financial measures
like "10 * dollar" and want to convert that to Euros. In this case the
conversion is not fixed (like in all physical measures) and depends on
  different forces, like the financial market, date-time, etc.

> These seem to be useful only for portability
> (since you are not using other equivalent Squeak packages), so you
> may want to separate them for clarity.

Thanks, we will think about it.

>
> I also am not an ACM member, so I cannot read your paper until OOPSLA.

I'm not sure I can't send it... I have to see the copyright (I hate
all this copyright stuff...)

>
> 3) I like the MeasureBag idea. Does it work for non-Integer values
> and why or why not?

What do you mean with non-Integer values?. Let me give you some examples:
(20 * dollar) + (10 * euro) --> Returns a measure bag with 20 dollars
and 10 euros
(20 * dollar) + 1 --> Returns a measure bag with 20 dollars and the
number 1
(20 * apple) + (5 * orange) --> Returns a bag with 20 apples and 5 oranges

Again, this is useful for financial measures. It does not make sense
for example with physical measures.

>
> 4) "Measure" suggests measurement, which has precision and tolerance.

We have struggle with the name for a while. We don't use measurement
(althoug we used to use it) because it suggests an action (a verb).
We use Measure becuase it is a noum.
We almost call it Quantity, but the name does not comunicate well...
Because it is not a measurement, it does not have a precision and
tolerance.

> Do you take these into consideration? If not, why name it Measurement

Remember is not measurement but measure.

> instead of DimensionedUnit or something? It will be confusing if
> someone makes a separate type system that /does/ handle precision and
> tolerance.

I'm not sure DimensionedUnit is a better name, becuase it puts the
attention on the unit but we want to put it on the measures... but I
would like to listen to other peoples opinion, names for me are very
important...

Thanks again,
Hernan.

On 28.03.2006, at 13:40, hernan_wilkinson wrote:

It is common behavior to post a version (sometimes, but not often,
labeled as "preprint" ;-)) of your  own papers on both your personal
homepage and the homepage of the group/institute you work for.

        Marcus

NB: I am replying after reading the paper thanks to non-public  
transmission, although as a practitioner's paper it mostly says the  
same as in cited papers, e.g. "Object-Oriented Units of Measurement".

NB: I am persistent with questions because I enjoy making a good  
design, not because I am critical.

On Mar 28, 2006, at 3:40 AM, hernan_wilkinson wrote:
However, the graph model is not needed unless a conversion from A to  
B to C is not transitive. That is, if I had ((A convertedTo: B)  
convertedTo: C) and wanted it to be different than (A convertedTo:  
C), then the graph model would be useful, but otherwise you can just  
use double-dispatch and have those methods consult whatever exchange-
rate service exists.

Specifically, you could have a convertTo: method just for financial  
measurements which did this generically for all financial conversions.

How does the graph model add to this? Does it give some extra  
statefulness or persistence? Do you have time-outs for financial  
conversion amounts? Why not put those timeouts or statefulness/
persistence in a CurrencyExchange class/service?
Well, I can accept that. Why don't we reconsider it as  
DimensionedNumber or DimensionedValue, then?

--
-Brian
http://tunes.org/~water/brice.vcf

>> I'm not sure I can't send it... I have to see the copyright (I hate
>> all this copyright stuff...)

Put the paper on your web: look at my web page....

Stef

--- In [hidden email], Brian Rice <water@...> wrote:
>
> NB: I am replying after reading the paper thanks to non-public
> transmission, although as a practitioner's paper it mostly says the
> same as in cited papers, e.g. "Object-Oriented Units of Measurement".
>
In some sense, it sure it does because it an old topic, it is not new,
that's why we wrote a practitioner report.
Although, there are some differences with the classic approach, that
is usually "static" (Object Oriented Units of Measurement proposes to
use type checking to verify unit conficts) and our approach is more
"dynamic".
It also have some clues on how we use it on the financial domain, that
for people that work on that domain I think they are new ideas...
(represent residual quantities of bonds with measure, prices with
measures, etc.)

> NB: I am persistent with questions because I enjoy making a good
> design, not because I am critical.
No problem, I like to have critics!

The graph is use when you need transitive conversions as you say. This
kind of transitive convertions "can be" common on the financial
domain. For example, you have the relation from dollar to euro, from
euro to peso, but want to convert from dollar to peso.
With the graph we also handle the situation where converting from
dollar to euro is not the same as converting from euro to dollar.
For the rest of the conversions (conversions on measures of the same
domain, for example meter to centimeter, days to hours, etc), we just
use double dispacth as you say.

>
> Specifically, you could have a convertTo: method just for financial
> measurements which did this generically for all financial conversions.

I guess I answered this on the previous paragraph

>
> How does the graph model add to this? Does it give some extra
> statefulness or persistence? Do you have time-outs for financial
> conversion amounts? Why not put those timeouts or statefulness/
> persistence in a CurrencyExchange class/service?

The graph model has nothing to do with persistence. Our application
uses GemStone so we get persistence from it. The same with time outs,
it is not related.
We do have an object that takes care about money conversion,
instruments valuations, etc. But those are higher level layers of
abstraction.
This package is simple and it is not tied to any kind of measure,
that's why we can use it in the financial domain, time domain, etc.
We solved the problems you are talking about but in higher layers...

In some sense your are rigth and that is what I said in the FAQ.
But if we think a little bit about things you can express in reality,
you could say "I have 1 liter of milk and 3 pices of cake". How do you
represent that if you don't allow to mix liters with pices?
Againg, this model has no restrinction on the things you can do with
measures, if you want to be sure that meters and seconds don't get
added, you need a higher level of abstraction to represent that. See
the concept of Evaluation that is useful for this.
> >
> >>
> >> 4) "Measure" suggests measurement, which has precision and tolerance.
> >
> > We have struggle with the name for a while. We don't use measurement
> > (althoug we used to use it) because it suggests an action (a verb).

I made a mistake here, Measurement is not an action but the result of
it (to take a measure, in Spanish it would be "Medicion").
On the other hand, Measure has a broader meaning and it is not tied
with the action of taking a measure (in Spanish it would be "Medida").

Well, let us thing about it...

Thanks
Hernan.
>
> --
> -Brian
> http://tunes.org/~water/brice.vcf
>

--- In [hidden email], stéphane ducasse <ducasse@...> wrote:
>
> >> I'm not sure I can't send it... I have to see the copyright (I hate
> >> all this copyright stuff...)
>
> Put the paper on your web: look at my web page....
>
> Stef
>

We'll do that, thanks.