Re: questions about units

m huang wrote:
> --- 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.

It is only that the return value of the Unit.pow() method is
declared as Unit. The actual class of the returned value in
your example 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.

This is really a non-problem. Just declare everything as
Unit and let the implementation worry about sub-classes.

> 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.

Applications are free to define new BaseUnits through
the BaseUnit.addBaseUnit() method. Or if your pet Unit
can be expressed from the system's 8 BaseUnits, then
create it that way.

> I am also thinking why not having one Unit class to treat all
> units uniformly.

Well, everything can be declared as Unit, and the application
can just ignore that the implementation may produce various

> > If you have real concerns and design ideas for units,
> > you should check out JSR 108 (javax.units):
> >
> >
> >
> > which is working on a Java extension for handling units.
> >
> We have been looking at this, and Dautelles' JADE project
> 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.

Yes, but the VisAD units allow applications to do what
they need with units, and have the great advantage of
being integrated with other forms of metadata: coordinate
systems, sampling topologies, missing data indicators,
error estimates, and data schemas. And integrated with
a visualization model, a distributed computing model, and
interfaces to a wide variety of file formats.

It is the integration of so many capabilities in one
coherent system that makes each capability so useful.

> There is also another quantity/unit system we are looking
> at -- Nano Titan's quantity library

Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI  53706
hibbard@xxxxxxxxxxxxxxxxx  608-263-4427  fax: 608-263-6738

  • 2002 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the visad archives: