>> 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...). > Why should there be a difference between a quantity and unit at all? > > If we keep in mind the analogy with vector spaces (and I actually > believe there's yet a stronger correlation), the bases or generating > sets of a vector (sub)space consist of vectors, just as the whole > vector space. Thus, I think that it is actually good that unit and > quantity are almost the same (in fact, a unit should be just a > quantity with some additional properties).
In fact, the unit system written "naturally" by using the multiplied base units are not a vector space but a group: the vector space representation is obtained with the exponents, and in this case, multiplication of units corresponds to addition of vector, power to multiplication. For example J = m**2 kg s**-2 is a group element, and the vector representation is (2, 1, -2). So the usual representation as product is not a vector space and multiplication by a number is something different. Some articles speaks about this [1]. It can be useful to have a distinction between quantities and units for several reasons, e.g.: from the "philosophical" point a view, an unit is something really fixed and defined, whereas a quantity is just a temporary object. Moreover, we can then define quantity with uncertainties with are clearly not units. In the same way, logarithmic units or units with offset (like °C) are not simple "number" as a quantity. So it could be useful to have a difference. On the other hand, I think that constant should really be viewed as the almost the same thing as an unit (we can subclass to say that the status is a little different). >> 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. In this case the best is maybe to do a wiki page and to add a link in the code and to open an issue pointing to the wiki page [1], so that it's possible to find the information in each case. > 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. Ok I will open a pull request. Harold [1] https://github.com/sympy/sympy/wiki/Unit-systems -- 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.
