python-quantities-developers team mailing list archive

[John Salvatier <jsalvati@xxxxxxxxxxxxxxxx>]

This would certainly work, but I think I may have a more elegant solution
(or maybe not).

What if instead of having UnitQuantity inherit from Quantity, we have it
inherit from Dimensionality and add multiplication/division between
dimensionality objects and numbers/Quantities (Quantity * Dimensionality =>
Quantity with appropriate units). So J/m would give a dimensionality, but 1
* J/m would give a Quantity.

This would also allow things like (x.units == J/m)

The only behavior I can think of that this will disallow is passing a unit
to a function that is expecting a Quantity (e.g.  func (inch)), but I
actually think this makes more sense, if you want to call a function for a
quantity with magnitude one, you should do func(1 * inch). Do you see any
other problems with this approach?

This would create a clearer distinction between units and quantities, which
I think will be useful.

Thoughts?

On Sat, Jan 10, 2009 at 5:35 PM, Darren Dale <dsdale24@xxxxxxxxx> wrote:

> On Sat, Jan 10, 2009 at 8:10 PM, John Salvatier <jsalvati@xxxxxxxxxxxxxxxx
> > wrote:
>
>> I am starting to think that an approach like this is best. I am not really
>> working on Quantities right now, just thinking about it as I work on other
>> things.
>>
>> I also think adding a .simplified property or method to Dimensionality is
>> a good approach to the other issues.
>>
>> I am trying to think if there is a good way to arrange things so that
>> x.units == J/BTU works as a new user might expect.
>
>
> Mmh, J/BTU yields a quantity, and I don't know if there will be an easy way
> to implement __eq__ between a quantity and a dimensionality object. I think
> we should advise in the documentation that units are expressed as unit
> quantities, so the appropriate comparison is not x.units == J/BTU but
> x.units == (J/BTU).units. How does that sound?
>
>
>>
>>
>> On Sat, Jan 10, 2009 at 5:01 PM, Darren Dale <dsdale24@xxxxxxxxx> wrote:
>>
>>> I felt like there should be a simple accessible property that is
>>> available to the user. dimensionality is not really meant to be messed with
>>> directly. I think dimensionality is important from a conceptual point of
>>> view, quantities have a magnitude and a dimensionality, the latter being
>>> composed of units of measure. But maybe we dont need a dimensionality
>>> property. The units property could return an immutable dimensionality
>>> object, instead of a string (which is just the repr of the dimensionality
>>> anyway). It would be like yielding a copy of the units, and the setter would
>>> behave just like it does now.
>>>
>>> I'll sleep on it and have a look tomorrow morning. If you want to
>>> investigate while I drag my feet, feel free and let me know when you have a
>>> branch ready to look at. All the unit tests make these kinds of changes so
>>> much easier to investigate!
>>>
>>> On Sat, Jan 10, 2009 at 7:24 PM, John Salvatier <
>>> jsalvati@xxxxxxxxxxxxxxxx> wrote:
>>>
>>>> I feel as though there is room for improvement, but I am not sure how.
>>>> Let me think about it.
>>>>
>>>> How come you have .units return a string? is there some specific use you
>>>> have in mind?
>>>>
>>>>
>>>> On Sat, Jan 10, 2009 at 4:18 PM, Darren Dale <dsdale24@xxxxxxxxx>wrote:
>>>>
>>>>> On Sat, Jan 10, 2009 at 4:50 PM, John Salvatier <
>>>>> jsalvati@xxxxxxxxxxxxxxxx> wrote:
>>>>>
>>>>>> The way the properties .units and .dimensionality currently work is
>>>>>> ok, but I feel as though they could be reworked so that doing common
>>>>>> operations is easier and more obvious (however, I am not sure exactly how to
>>>>>> do so).
>>>>>>
>>>>>> Here are some common operations:
>>>>>>
>>>>>> 1) check the equivalence of two sets of units
>>>>>>
>>>>>>    - currently x.units == y.units works, but works through string
>>>>>>    comparison which seems inelegant, but maybe doesn't have any actual
>>>>>>    drawbacks
>>>>>>
>>>>>> Its not clear to me what you think should be changed. Why can't you
>>>>> use dimensionality:
>>>>>
>>>>> >>> j=10*J
>>>>> >>> j.dimensionality==J.dimensionality
>>>>> True
>>>>>
>>>>> >>> j=J.simplified
>>>>> >>> j.dimensionality==j.dimensionality
>>>>> True
>>>>>
>>>>> >>> j.dimensionality==J.dimensionality
>>>>> False
>>>>>
>>>>> I think this works the way you expect it to.
>>>>>
>>>>>
>>>>>>    -
>>>>>>
>>>>>> 2) check the compatibility of two sets of units
>>>>>>
>>>>>>    - currently x.simplified.units == y.simplified.units is the most
>>>>>>    straight forward way to do this, but this adds unnecessary array
>>>>>>    multiplication
>>>>>>    - I think it would be intuitive if x.dimensionality ==
>>>>>>    y.dimensionality accomplished this but this would require some refactoring
>>>>>>
>>>>>> This is a good point. What if dimensionality also had a simplified
>>>>> method, which constructed a quantity, called its simplified, and returned
>>>>> the simplified quantity's dimensionality. Then you could do
>>>>> x.dimensionality.simplified == y.dimensionality.simplified without having to
>>>>> perform array operations.
>>>>>
>>>>> 3) check that quantity is dimensionless
>>>>>>
>>>>>>    - currently x.dimensionality = dimensionless.dimensionality
>>>>>>    accomplishes this
>>>>>>    - it would be intuitive if x.units == dimensionless accomplished
>>>>>>    this (could be tricky since dimensionless is a Quantity)
>>>>>>
>>>>>> I think the simplest check for dimensionless is the one I have been
>>>>> using for some time:
>>>>>
>>>>> >>> if dimensionless.dimensionality:
>>>>> >>>     print 1
>>>>> >>> if not dimensionless.dimensionality:
>>>>> >>>     print 2
>>>>> 2
>>>>>
>>>>>
>>>>> I don't know if there is a way to accomplish all of these at once in an
>>>>>> elegant way, I am just throwing out ideas and observations.
>>>>>>
>>>>>> I think that ".dimensionality" when contrasted with ".units" sounds
>>>>>> like a way to compare the compatibility of the units ( e.g. #2)
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>>
>>>>> How do my suggestions sound to you?
>>>>>
>>>>>
>>>>
>>>
>>
>