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

I'm looking into it.


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