On May 22, 2007, at 12:10 AM, [EMAIL PROTECTED] wrote:
> >> I am in favor of something more like that, though I *loathe* adding >> anything further to the preparser. Maybe this is more pythonic: >> >> sage: sin(10 * degrees) >> >> i.e., degrees would be a Python object that represent 1 degree. >> The resulting object 10 * degrees would be a number with units. >> >> I would be interested in a general units package. > > Sounds... interesting... but is every trig function now going to > have to ask for the radian value? I'm not as against this as I > thought I'd be... but it looks like there are some wierd issues: Radians could be (naturally) unit-less. The "degree" unit would have a sin() method, and sin(x) already tries x.sin(). > * It would be cool to integrate some surface of revoluion to > determine the volume of a bottle, or some other surface of > revolution. Does GSL have to know units, or should we somehow > strip them out first? Then, will we have to know that a triple > integral returns a cubic unit? No, I'd imagine a "units" element would be (value, units), and one could do arithmetic and integrate/differentiate (variables could have units too) but not much more. > * Are we going to throw exceptions when units of differing type > are added? > > 1*meters + 2*meters*meters : NOT OK. TypeError, or some other error for sure. > 1*meters + 2*feet = ... in feet or meters? (I say meters) Leave unevaluated? To convert do meters(x)? There is the namespace pollution issue here though... I could see having degree global, but otherwise one would probably want to do from "sage.units import *" --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
