python-quantities-developers team mailing list archive

["John Salvatier" <jsalvati@xxxxxxxxxxxxxxxx>]

Two more potential models (I think I went a little overboard thinking about
this):

1) Have a function that takes the different parts of a compound unit as
separate positional arguments and then puts them together into a compound
unit: compoundUnit = CompoundUnit( km**2  ,   m**-3) would print out as "
(km**2/m**3) "

2) have a special unit called "compound" which would be placed on the far
left hand side of a unit quantity and would have a flag that would prevent
units multiplied with it from reducing. So to create a compound unit, one
would write:  compoundUnit = UnitQuantity( compound * m**2 / m**3 ). The
drawbacks to this model is that it is sort of a novel mechanism, so it may
confuse people and that the syntax is very specific, the "compound" must be
placed at the very left of the reference quantity and cannot have any
parentheses in it.

John

On Sun, Jan 4, 2009 at 3:06 AM, John Salvatier <jsalvati@xxxxxxxxxxxxxxxx>wrote:

> I have been thinking a bit about how we should handle units that the user
> wants to be compound (like m**2/m**3, which currently reduces to 1/m) and
> units of the same "type" (like J and BTU). I think ideally, the quantity
> 10.0 * J/BTU (it currently stays as J/BTU) should come out as dimensionless
> under most circumstances, but there should be some way to force it to stay
> as a compound unit.
>
> Here is one way we could deal with this:
>
> Units which have exactly the same base type (like J and BTU) should cancel
> normally, but any quantity/dimension can be told to be "static" which makes
> it not cancel unless forced to do so. The .static property would be used
> when creating a compound unit. I envision something like this:
>
> kPa * L / J     ->     kPa * L / J
>
> but
>
> J/BTU     ->      (dimensionless)
>
> but
>
> J.static/BTU.static     ->      J/BTU
>
> but
>
> (J.static/BTU.static).simplified     ->      (dimensionless)
>
> Creating compound units would be done like: compoundUnit = CompoundUnit (
> (km**2).static/(m**3).static)
>
> We might also think about automatically simplifying any unit group that
> comes out dimensionless (kPa * m**3/J      ->      (dimensionless) but
> kPa * m**3/ ( J/m)      ->      kPa * m**3/ ( J/m) ) . However, I suspect
> this might be too confusing.
>
> Some other ideas:
> 1) Instead of using the .static property, we could have extra units like
> BTU_ and J_ etc. that would behave statically (not reduce unless forced) and
> use most of the above
> 2) Instead of the above, we could parse a string so that creating a would
> work like this: compoundUnit = CompoundUnit ("km**2/m**3")
> 3) Or we could simply use the existing framework; have the user name a unit
> and give it a reference quantity: compoundUnit = UnitQuantity ("km**2/m**3",
> km**2/m**3).  We could add an argument that tells the quantity it is a
> compound unit so that uses parentheses when it writes it out. I suspect this
> may end up being the simplest solution.
> 4) We could also change around quantities so that units are not reduced at
> all except when they are printed out (so m/m gets stored as m/m but is
> reduced when printed out). This would allow us to simply print out compound
> units as they are actually stored. However, I suspect this would be very
> awkward.
>
> Tell me what ideas you think are good or bad.