--- Bill Hibbard <hibbard@xxxxxxxxxxxxxxxxx> wrote:
>
> > Say if I creat a unit
> > foo=SI.meter.multiply(2);
>
> There is not signature in any Unit class for multiply()
> taking an integer argument. It takes another Unit, and
> returns the product of the two units: 'this' and the
> argument.
Sorry my fingers were working faster than my eyes ;-)
I meant it to be
foo = SI.meter.pow(2);
>
> > and another unit
> >
> > bar= DerivedUnit({SI.meter},{2});
> >
> > Are foo and bar actually the same class objects? If yes,
> > why does DerivedUnit.multiply() return Unit instead of
> > DerivedUnit? If not, why not?
>
> In general, operations on Units that produce mathematically
> equal Units will not return the same instance.
Sorry for the confusion I made. I understand that the units
are not the same instance. I am wondering if they should be
the same Class of objects because as shown above, foo and
bar are both m^2, yet one is Unit and one is DerivedUnit.
> > More generally, I would like to know why are BaseUnit,
> DerivedUnit
> > and ScaledUnit on the same level of inheritance hierarchy?
> > Conceptually a BaseUnit is a DerivedUnit that has undergon
> > zero/no derivation, therefore can be treated "a kind
> > of", or "a subset of", or a subclass of what is now called
> > the DerivedUnit, and ScaledUnit can be also seen as a
> > special case of DerivedUnit. The Developers Guide (2.5 years
> > old) doesn't mention what is the thinking behind the DerivedUnit
> > and ScaledUnit.
>
> Applications don't generally need to worry about BaseUnit,
> DerivedUnit and ScaledUnit. They just need the lists of
> static BaseUnits (which they can declare as 'Unit') in SI
> and CommonUnit, plus the pow(), scale(), shift(), multipl()
> and divide() methods of Unit that can be used to create
> new Units.
>
But from my above question, the same unit constructed differently
gets you a different class of object, not only so, foo can't be
even given a name. Is this intended? or a side effect that is
supposed to be worked around (e.g. just use the DerivedUnit
constructor if I want to give it a name) ? I don't know. The
document doesn't tell. If I make assumptions, I am liable of
problems if I make a wrong one.
here I also reply to Don's comment.
"Don Murray" <dmurray@xxxxxxxxxxxxxxxx> wrote:
> I just deal with the
> Unit superclass which has the methods I need.
For the project I work on, we are thinking of creating an
application that has many units, some well established (e.g.
Jansky := 10^-26 W/m2/Hz) some just ad hoc, for the astronomer
community in general.
People like to think in their pet units, the radioastronomers
and the optical astronomers use different units for the same
quantity. It would be nice to have an arbitrary unit turned
to behave like a BaseUnit when the user wants.
I am also thinking why not having one Unit class to treat all
units uniformly.
> If you have real concerns and design ideas for units,
> you should check out JSR 108 (javax.units):
>
> http://www.jcp.org/en/jsr/detail?id=108
>
> which is working on a Java extension for handling units.
>
We have been looking at this, and Dautelles' JADE project
http://jade.dautelle.com/
VisAD's unit system appears to be related a past version of
JADE. But current implementation of JADE has improved and
left VisAD behind, I think.
There is also another quantity/unit system we are looking
at -- Nano Titan's quantity library
http://nanotitan.com/software/Libraries/quantity/index.htm
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
