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