I will check this as soon as I can. I too was not very satisfied with the units module. In particular, I did not like the way SI prefixes are handled. Also, this:
sage: m=units.length.m sage: sqrt(m^2) sqrt(meter^2) When I'd expect to get "meter". Some features I'd like to see in a units module: * Type recognition. Doing something like sage: 2.5 * m/s^2 * 2 * kg 5.0 Newton instead of 5.0 kg*m*s^2 This is already on wolphram alpha: http://www.wolframalpha.com/input/?i=+2.5+*+m%2Fs^2+*+2+kg * Use SI prefixes instead of scientific notation: sage: c= 300000 m/s sage: 0.9 kg *c 81.0 mega Joule instead of 8.10000000000000e10*gram*meter^2/second^2 * To make units more easily accesible I suggest make a function that gets units in certain unit systems available sage: import_units(system='SI',only_base=False) #Imports all SI units sage: import_units(system='SI',only_base=True) #Imports all SI base units sage: import_units(system='SI',types='length time mass electric_charge') #imports only metre second kilogram and coulomb And others like that. I hope to review your code soon. Oscar On Aug 21, 8:18 pm, cousteau <cousteaulecommand...@gmail.com> wrote: > I found the "sage.symbolic.units" module very promising, but there > were some features it was missing, such as an easy way to enter units > (something like "units('kg*m/s^2')"), handling of SI prefixes (you can > do "units.si_prefixes.kilo*units.length.meter", but this is very > impractical), unit representation ("2*meter*milli" isn't very nice)... > I tried to modify the source code of the units module, but it wasn't > easy to understand and it didn't seem to be compatible with the ideas > I had in mind, so I rewrote it from scratch: > > http://trac.sagemath.org/sage_trac/ticket/9763 > > Some features it provides: > + Easy units input, in the form of "U('kg*m/s^2')" or "U('3600 kg m2 > s-2')", which will also handle SI prefixes > + Plain and LaTeX representation of values with units, the latter > using the "latex_name" argument > + Self-contained: all the information of a quantity (the number, the > expression representing the units, an array containing unit type > information, and the SI conversion factor) is stored in an object > + Working conversion between "padded" units, such as degrees Celsius > and kelvin, even if they are multiplied or divided by another unit (in > which case it assumes 1 kelvin/second = 1 celsius/second) > + Implicit conversion when adding units of the same type > > The problem with defining a new class is that it involves defining all > the "__add__", "__sub__", "__mul__", "__le__", etc... methods, which > work differently than in other Sage classes, and it might not > integrate very well with the rest of Sage. Also, the developers might > not like the idea of rewriting a module from scratch when there's > already a module with the same purpose (although this one is very > different), and might prefer to extend what they already have and > know. Anticipating this, I did a small attempt to port some of the > features to the already existing "units" module: > > http://trac.sagemath.org/sage_trac/ticket/9778 > > It's not such a rework as the one I did when writing the module from > scratch, but it features: > + SI prefixes: although tab completion doesn't include them, you can > write units such as "units.length.kilometer" and that unit will be > created automatically > + LaTeX representation: there are only a few units as an example, but > it can be easily extended by adding more entries to the "latexdict" > dictionary. Prefixed units will make the LaTeX representation from the > ones for the prefix and the unit. > = All the units, unit documentation, and everything else that was > already implemented in "units" is kept. > - Still lacks an easy way to enter units > - Conversion of temperatures behaves weirdly (example: try to convert > 32 fahrenheit to celsius and then to kelvin) > > I want to hear your opinions. Which one of them is the best solution? > Or none of them? Which one looks more interesting? I personally prefer > the first one. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
