python-quantities-developers team mailing list archive

["Darren Dale" <dsdale24@xxxxxxxxx>]

On Thu, Jan 8, 2009 at 5:05 AM, John Salvatier <jsalvati@xxxxxxxxxxxxxxxx>wrote:

> On Tue, Jan 6, 2009 at 6:33 AM, Darren Dale <dsdale24@xxxxxxxxx> wrote:
>
>> On Tue, Jan 6, 2009 at 3:51 AM, John Salvatier <jsalvati@xxxxxxxxxxxxxxxx
>> > wrote:
>>
>>> I was implementing Quantities.fill(scalar) and it made me think about
>>> assigning zeros to Quantity array elements.
>>> If a quantity is non-dimensionless and someone tries to assign zero to an
>>> array element, an error will be thrown, even if it makes sense to assign a
>>> zero to the element.
>>>
>>>  Example:
>>>
>>> x = [10, 5, 1, 3]  * BTU
>>>
>>> x[1] = 0    # this will throw an error because a float does not have
>>> units of BTU
>>>
>>> I worry about this because I imagine that a good deal of algorithms that
>>> we would like to work with Quantities assign zeros to some array elements in
>>> some circumstances, and that will break compatibility. I'm not really sure
>>> how to deal with that.
>>>
>>> What do you think?
>>>
>>
>> I think Quantities should not blur the distinction between a physical
>> quantity, which has both magnitude and dimensionality, and the magnitude
>> itself. If you want to modify the magnitude without worrying about the
>> units, the mechanism exists to do so:
>>
>> x.magnitude[1]=0
>>
>> That is true. However, my recurring concern is that if we want Quantities
> to be as useful as possible (and for people to use it), it should work with
> as many preexisting algorithms as possible. I suspect there is a big benefit
> for having quantities work with functions without intuitively and without
> modification or minimal modification (wrapping ect.) wherever possible.


I don't want to add support for a bunch of special cases, its not good
design and its not good behavior. x[1]=0 worked, why cant I do x+=1? If I do
x*=0, should I add a special case to yield a dimensionless quantity, or
should it retain its original dimensionality? I think we need to focus on a
clean and consistent design at this point in development, and discuss
support for special cases later on, when there is specific and strong
motivation for doing so. Special cases makes everything much harder going
forward, they have to be unit tested, supported, they make design changes
and refactoring more difficult.