On Thursday, June 14, 2012, Aaron Meurer wrote: > On Jun 14, 2012, at 10:06 AM, Harold Erbin > <[email protected]<javascript:;>> > wrote: > > > Hi, > > > > I'm creating a new topic on the implementation of unit systems into > > sympy to gather all discussions under an explicit name ([1] and [2]). > > > > First a summary of the code: > > 1. First of all, dimensions are defined as Dict in order to let the > > possibility to add new dimensions. They combines themselves as elements > > of a group. It will then be possible to implement general computations > > using uniquely dimensions (dimensional analysis, etc.). This is totally > > coherent without unit system, even if it's possible to use dimension > > with them to add new possibilities. > > 2. Then units are defined. Their operations are consistent without the > > choice of an unit system (see below), but then it's quite useless except > > in some specific cases (like defining a system). > > 3. System can be viewed as vector space (or group, which is more used in > > literature).They are constructed by using "canonical" units (and so > > dimension), which have to be defined before. But when the system is > > created, it's possible to use other units as a basis, which is > > equivalent to change the basis of the vector space. This is the simplest > > way even if at some point we have to introduce a favored base. > > 4. Finally quantities are just a number with an unit. > > > > There is a real liberty to define unit systems which will be useful, > > instead of having hundred of units, and so one can really use only the > > system and the units he needs (for example astrophysicists can only use > > units with ua, Earth or Sun masses, the theoricists will use natural > > system, etc.). > > > > The main gap in this approach is that unit and quantity are almost the > > same things, since the factor of the unit can be moved to the quantity, > > and vice versa. I'm thinking how to improve this, maybe by keeping in > > the factor's unit only what is necessary to give 1 when expressed in > > terms of base units, or when it's a special unit (like liter...). > > > > I decided to let the possibility to add units or an unit with a > > quantity, because it's simpler when using interactive shell (in my > > opinion, but I was hesitating a lot) : > > m + m = 2*m > > 2*m = 3*m > > so the unit m is interpreted as the quantity 1*m. > > > > Now I'm again working on the problem we were speaking about with Aaron, > > which is the way that Mul combine the units, resulting in expressions > > like (cf the test file for more details) > > > 149598206033.591*kg**(1/3)*kg**-1**(1/3)*m**3**(1/3)*s**-2**(1/3)*s**2**(1/3) > > > > I did not solve yet the problem we were discussing in issues 1940 and > > 1941, because I was hoping that subclassing AtomicExpr could avoid to > > edit the Mul class (by seeing the current implementation of units). > > > > I have still a great list of things to implement, but the core is almost > > done (I have still to implement the constants and use them to define > > unit system). > > At the end, what is the best way to list all the things to still > > do/improve? (I will not be able to do all.) Should I put them in comment > > inside the code, or open one issue on github and list all the ideas? (or > > open one issue for each?). > > First I should note that issues should be opened in Google Code, not > GitHub. GitHub is just for pull requests. > > Either of those options is ok. A third option is to start a page on > the wiki. Each way has its own advantages. Comments on the code will > tell anyone who stars editing the module what needs to be done, and it > has the least chance of being "lost" if it is there. However if you > choose toput it somewhere else, you can just add a link in the code. > > Issues have a good level of permanence and have a nice discussion > format. Also anyone wanting to report a bug will hopefully find your > issue first. > > Wiki pages are good if you are scoping out a design. You can get nice > formatting, and other people can chime in if they want by just editing > the page. > > Aaron Meurer
Oh, and if you have actual code that you want comment on, the best way is to open a pull request, even if it's not ready to be merged yet. Aaron Meurer > > > > > The current code can be found here on github [3] (in the module > > physics/units). Tests shows some examples of the computations available. > > > > Best, > > > > Harold > > > > [1] https://groups.google.com/forum/?fromgroups#!topic/sympy/Vrvwf5CYmWw > > [2] https://groups.google.com/forum/?fromgroups#!topic/sympy/tpxqGzbCiMk > > [3] https://github.com/melsophos/sympy/tree/units > > > > -- > > You received this message because you are subscribed to the Google > Groups "sympy" group. > > To post to this group, send email to [email protected]<javascript:;> > . > > To unsubscribe from this group, send email to > [email protected] <javascript:;>. > > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > > -- Sent from my iPad. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
