On 5/22/07, [EMAIL PROTECTED] <[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: > > * 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? > > * Are we going to throw exceptions when units of differing type are > added? > > 1*meters + 2*meters*meters : NOT OK. > 1*meters + 2*feet = ... in feet or meters? (I say meters)
^^^^ that's what google's calculator does. This is going on quite a tangent, but I think it would be interesting to try: sage: a = 1*meters + 2*feet; a 2*meters + 2*feet sage: meters(a) 1.6096 * meters ~Bobby -- Bobby Moretti [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
