On Thu, Mar 19, 2009 at 3:45 PM, Maurizio <maurizio.gran...@gmail.com> wrote:
>
> Hi
>
> can anyone give an advice on how to adapt Quantities to let it be
> compatible with SAGE? I don't know how SAGE modifies the way to
> represent numbers, and why it does not comply with Quantities.
>
> For example, how does SAGE generate an instance of
> "sage.rings.integer.Integer"? I hope this can help me. Actually, I
> wasn't able to understand how Quantities deals with numbers, because
> it basically transform any python int or float multiplied by a
Does Quantities have any code that looks like this:
if isinstance(foo, (int, long)):
...
or anything remotely like that? If so, you just have to change it to
int_types = (int, long, Integer)
if isistance(foo, int_types):
...
William
> physical unit, into a numpy array (either a single element or a
> vector) with unit "dimensionless". I think there would be nothing
> wrong with continue using normal sage integers or float as
> dimensionless, even though I don't know how could we manage an object
> given by the multiplication of an integer and a physical unit: would
> this become a "quantity" instance? This would be fast to implement,
> because that's the way it is now. Nonetheless, this is not the way I
> would like it to do, because it would cause the necessity to add in
> quantity the way to deal with all the possible types in SAGE (also
> symbolics, in future?).
>
> Is there any chance to do something like putting the physical quantity
> like a property of the existing numerical (and in future any other)
> class? I'm just wondering if is there any good way to do this, and if
> I would be able to try to work on that.
>
> I've to admit, I'd like to be better in python programming, and to
> have more time to work on it. Until now, with a simple one-line
> modification, I has been able to let "quantities" accept the sum of
> coherent physical quantities, but I didn't manage to get the
> representation I was talking about on the previous post yet,
> especially because the "quantities" package is not really intended
> that way: the way I would have tried to produce something like that,
> is by distinguishing the units (e.g. Volts, Amperes, meters, ecc) from
> the multipliers (milli, micro, kilo, ecc) and then try to find a way
> to effectively combine them (in the expected way, like using the
> multipliers as a prefix to the unit: m+V = mV, centi+meter=cm, ecc).
> This seems more logical to me.
>
> Another option, is to try to write this from scratch, trying to derive
> the most from others available packages out there (it's not really
> that much of lines of code), but I would not prefer to produce ANOTHER
> package about that! What do you think?
> I would prefer to keep that package, and simply try to apply some
> short differential patch to it to get a SAGE compatible version, but
> I'm not sure if I'll be able to.
>
> Thank you for your time
>
> Maurizio
>
> On 16 Mar, 19:29, Maurizio <maurizio.gran...@gmail.com> wrote:
>> In fact my idea is a bit different, and I'll explain in a minute:
>> provided that the system is SI, you should get the result as a
>> multiplier (bigger than one) of the closest classic unit
>> representation
>> ex: meters -> nm - um - mm - m - km - ecc ecc
>> ex:
>>
>> x1 = 10cm
>> x2 = 1m
>> x1 + x2 = 1.1m
>>
>> y1 = 1V (Volt)
>> y2 = 0.5 V
>> y1 - y2 = 500 mV
>>
>> z1 = 500 mA [milliAmperes]
>> k = 3
>> z1 * k = 1.5 A
>>
>> Does this looks reasonable? I find this very comfortable!
>>
>> Regarding imperial system, the same could be done, even though this is
>> just a bit tougher because of the fractional multipliers, but the
>> principle can stay the same.
>>
>> Two optional features could be very important, in my opinion:
>> 1) locking one object unit representation to a certain order of
>> magnitude and/or metric system
>>
>> ex:
>> x1 = 1 cm
>> x1.lock('cm')
>> x2 = x1 + 1 m [x2 can inherit the lock property]
>> x2 = 101 cm
>> x2.lock('inches')
>> x2 = 39.76 inches
>> x2.unlock()
>> x2 = 1.01 m
>>
>> PS: locking property could also be specified when instantiating an
>> object
>>
>> 2) changing the standard metric system (imperial / SI / any other) so
>> that by default each value is scaled as previously proposed
>>
>> Any comment?
>>
>> Thanks
>>
>> Maurizio
>>
>> On 16 Mar, 16:06, Robert Dodier <robert.dod...@gmail.com> wrote:
>>
>> > Maurizio wrote:
>> > > Regarding the output of such expression you wrote, I agree that it
>> > > should give a standard unit output for each physical quantity, so by
>> > > presetting SI (or imperial, or anything else), it should give just
>> > > meters (or feets, or anything else)...
>>
>> > I'm pretty sure that would cause more trouble than it's worth.
>> > Whatever the standard, there could well be nonstandard combinations
>> > such as centimeters per day or liters per kilometer, which should
>> > be preserved as such. In the US, which is an important enough
>> > audience to be accomodated in the design of a units package,
>> > mixed-up units from different standards or no standards at all are
>> > very common, and should be preserved as such.
>> > And whatever the system or lack of it, it would be annoying to
>> > change fractional or multiple units (inches, kilometers, etc) to
>> > their base units (feet, meters, etc).
>>
>> > The point is to accomodate the user, who has a better idea about
>> > what they want to accomplish than the package writer.
>>
>> > FWIW
>>
>> > Robert Dodier
>>
>>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
