Thank you for your help.
I realize now how silly it has been to ask such a general question
here, with you guys just guessing. Even this not being the solution,
this has still been helpful for me to understand something more.
Hopefully, I'll get more into it.
By the way, any other comment about all the other facts?
Thanks
Maurizio
On 19 Mar, 23:48, William Stein <wst...@gmail.com> wrote:
> 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 Washingtonhttp://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
-~----------~----~----~----~------~----~------~--~---
