python-quantities-developers team mailing list archive

["Darren Dale" <dsdale24@xxxxxxxxx>]

On Sat, Jan 10, 2009 at 11:57 PM, John Salvatier
<jsalvati@xxxxxxxxxxxxxxxx>wrote:

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

In the abstract, I agree this approach makes more sense. Its sort of similar
to the original design of Quantities. But when you get down to actually
implementing it, you find that the implementation is not as elegant. The
benefit of having units derive from Quantity is that you dont have to
special-case operations between units and quantities, it just works. I'll
keep thinking about it though.


>
>
> 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?
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~python-quantities-developers<https://launchpad.net/%7Epython-quantities-developers>
> Post to     : python-quantities-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~python-quantities-developers<https://launchpad.net/%7Epython-quantities-developers>
> More help   : https://help.launchpad.net/ListHelp
>
>