Dimensional Analysis or Unit Conversion capability?
lenient7
conversion? For example, identifying dimension of energy as MASS *
LENGTH^2 * TIME^(-2) or converting inch into meter.
Robert Bradshaw
you could install into Sage. (There was talk about adding this at one
point, what is needed is a good list of all the best open-source
packages out there and a discussion of which one to choose and why).
Simon King
detail to Robert's reply: "There are Python packages that do this"
means that you can install them into Sage (being on a Linux command
line) by first doing
sage -sh
and then do whatever necessary to install that Python package
(probably "python setup.py install"). "sage -sh" means that you enter
a Sage shell, and hence "python" refers to the Python version of Sage.
Best regards,
Simon
Maurizio
On Jun 12, 7:41 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> you could install into Sage. (There was talk about adding this at one
> point, what is needed is a good list of all the best open-source
> packages out there and a discussion of which one to choose and why).
>
couple of months ago:
http://groups.google.com/group/sage-devel/browse_frm/thread/ae18ce618abd66d2/649bd604d0fd20c9?hl=en%CA%89bd604d0fd20c9
as you can see, I already tried to provide a list of all the best open-
source packages out there, I also proposed a couple of
modifications... I was actually quite interested in that stuff.
Nonetheless, there was not enough interest in the community, maybe, so
that discussion ended without any concrete effect.
I am willing to give new life to this discussion :) I am wondering
whether a brainstorming system (like the one adopted by Ubuntu -
http://brainstorm.ubuntu.com/ ) could be useful to catch the
community's needs :)
Regards
Maurizio
Robert Bradshaw
> Hi all
>
> On Jun 12, 7:41 am, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> No, but I believe there are several Python packages that do this that
>> you could install into Sage. (There was talk about adding this at one
>> point, what is needed is a good list of all the best open-source
>> packages out there and a discussion of which one to choose and why).
>>
>
> I want to mention that I started a discussion about this same topic a
> couple of months ago:
>
> http://groups.google.com/group/sage-devel/browse_frm/thread/
> ae18ce618abd66d2/649bd604d0fd20c9?hl=en%CA%89bd604d0fd20c9
>
> as you can see, I already tried to provide a list of all the best
> open-
> source packages out there, I also proposed a couple of
> modifications... I was actually quite interested in that stuff.
> Nonetheless, there was not enough interest in the community, maybe, so
> that discussion ended without any concrete effect.
It seemed there was a fair amount of interest, but it there wasn't a
obvious winning solution, and no one had enough incentive to advocate
and push through a full plan. (Usually this isn't an indication that
no one wants it, but that everyone is already busy trying to work on
stuff more relevant to their goals.)
> I am willing to give new life to this discussion :) I am wondering
> whether a brainstorming system (like the one adopted by Ubuntu -
> http://brainstorm.ubuntu.com/ ) could be useful to catch the
> community's needs :)
Yes, and thanks for the effort there. If I remember right, quantities
(?) looked pretty good, but it only can accept numpy scalars. It
would be good to summarize this discussion/the options on a wiki--
threads are good for a discussion but it becomes hard to get a big
picture once they get so big.
- Robert
Maurizio
> It seemed there was a fair amount of interest, but it there wasn't a
> obvious winning solution, and no one had enough incentive to advocate
> and push through a full plan. (Usually this isn't an indication that
> no one wants it, but that everyone is already busy trying to work on
> stuff more relevant to their goals.)
>
> > I am willing to give new life to this discussion :) I am wondering
> > whether a brainstorming system (like the one adopted by Ubuntu -
>
> Yes, and thanks for the effort there. If I remember right, quantities
> (?) looked pretty good, but it only can accept numpy scalars. It
> would be good to summarize this discussion/the options on a wiki--
> threads are good for a discussion but it becomes hard to get a big
> picture once they get so big.
>
> - Robert
adapting the external package to use the built-in SAGE numerical types
is a huge advantage in terms of usability.
For this reason, we contacted the quantity author, which took part to
the discussion. He recognized that interaction with SAGE types was the
first issue to deal with, but at the same time he was a little busy,
so he probably thought that we should have figured out the way to
solve this first issue at least.
I can probably work at a wiki page summarizing this stuff (not that
much of material, actually), but do you think anybody is going to take
advantage of this? I often see abandoned page in the wiki, and
moreover, if there had been enough interest in that, don't you think
that people would have shown up in the thread? This group has the
advantage that it has still quite good visibility, in my opinion
higher than that of the wiki (but I could be wrong). What do you
think? If you consider that a good point to start with, you could
start creating the wiki page and I could try to edit that a little,
and then we will see how it goes.
All the other people involved, and interested in a unit package,
please show just to say "hi"
Regards
Maurizio
Stan Schymanski
>
> All the other people involved, and interested in a unit package,
> please show just to say "hi"
>
>
the discussion with eager anticipation of something useful being
implemented. Unfortunately, I can't contribute anything other than bug
reports once something is implemented.
Good luck!
Stan
--
________________________________________
Stan Schymanski
Scientist
Max Planck Institute for Biogeochemistry
Postfach 10 01 64
D-07701 Jena
Phone: +49.3641.576264
Fax: +49.3641.577274
WWW: http://www.bgc-jena.mpg.de/~sschym
Biospheric Theory and Modelling Group
http://www.bgc-jena.mpg.de/bgc-theory/
_________________________________________
Jason Grout
>
> All the other people involved, and interested in a unit package,
> please show just to say "hi"
I'm still interested, but my time is even more limited than it was in
during the previous thread.
Jason
David Joyner
>
...
>
> All the other people involved, and interested in a unit package,
> please show just to say "hi"
say calculus /ODEs (eg, using DEs to solve a circuit or spring problem).
Not a high priority though.
>
> Regards
>
> Maurizio
> >
>
Robert Dodier
wrote:
> No, but I believe there are several Python packages that do this that
> you could install into Sage. (There was talk about adding this at one
> point, what is needed is a good list of all the best open-source
> packages out there and a discussion of which one to choose and why).
package for Sage, after reviewing existing packages, instead
of trying to bolt one of the existing packages onto Sage.
Unit conversion and dimensions analysis isn't very complicated,
so it's probably easier to just write it anew.
The existing packages have various features, so someone
can just pick and choose the features they want.
Shameless plug --- I wrote the ezunits package for Maxima,
which makes extensive use of symbolic computations,
and has a very convenient syntax for annotating units
and for unit conversions, and some interesting random
features; I like this one:
10000 ` m `` [mile, yard, foot, inch];
=> [6 ` mile, 376 ` yard, 0 ` foot, 608/127 ` inch]
Maybe ezunits can a source of some inspiration.
FWIW
Robert Dodier
Maurizio
> I'm going to suggest that interested parties just write a new
> package for Sage, after reviewing existing packages, instead
> of trying to bolt one of the existing packages onto Sage.
cons:
- nobody is volunteering, so the amount of work-time seems very
limited
- I don't like to reinvent the wheel, that's why I like SAGE so much
- I have very limited experience about Python programming (especially
classes and stuff like that)
- I would like to take advantage of others' experience about designing
a package like that
>
> Unit conversion and dimensions analysis isn't very complicated,
> so it's probably easier to just write it anew.
> The existing packages have various features, so someone
> can just pick and choose the features they want.
>
> Shameless plug --- I wrote the ezunits package for Maxima,
> which makes extensive use of symbolic computations,
> and has a very convenient syntax for annotating units
> and for unit conversions, and some interesting random
> features; I like this one:
>
> 10000 ` m `` [mile, yard, foot, inch];
> => [6 ` mile, 376 ` yard, 0 ` foot, 608/127 ` inch]
>
> Maybe ezunits can a source of some inspiration.
>
> FWIW
>
> Robert Dodier
By the way, do you think is it convenient to create a new wiki page
about this topic to summarize all this stuff? I have two questions:
first of all, I don't know how to do that, even if it seems pretty
easy to modify an existing page. The second question is: on the wiki
itself, the developers suggest to create a trac ticket with a wish
list, instead of creating wiki pages. Nonetheless, there is that SEP
(SAGE Enhancement Proposal) there, which seems a suitable place to
write.
Last doubt: is anybody going to read it? :)
Thanks
Maurizio
Robert Bradshaw
> Hi
>
>> I'm going to suggest that interested parties just write a new
>> package for Sage, after reviewing existing packages, instead
>> of trying to bolt one of the existing packages onto Sage.
>
> I have honestly taken this into account, but there are a couple of
> cons:
> - nobody is volunteering, so the amount of work-time seems very
> limited
> - I don't like to reinvent the wheel, that's why I like SAGE so much
> - I have very limited experience about Python programming (especially
> classes and stuff like that)
> - I would like to take advantage of others' experience about designing
> a package like that
>
>>
>> Unit conversion and dimensions analysis isn't very complicated,
>> so it's probably easier to just write it anew.
>> The existing packages have various features, so someone
>> can just pick and choose the features they want.
Yep, it's not very hard, but it's apparently not very important
either (relative to other stuff going on).
> By the way, do you think is it convenient to create a new wiki page
> about this topic to summarize all this stuff? I have two questions:
> first of all, I don't know how to do that, even if it seems pretty
> easy to modify an existing page. The second question is: on the wiki
> itself, the developers suggest to create a trac ticket with a wish
> list, instead of creating wiki pages. Nonetheless, there is that SEP
> (SAGE Enhancement Proposal) there, which seems a suitable place to
> write.
> Last doubt: is anybody going to read it? :)
A wiki page has a much more permanent and easy to read than an email
thread. A wishlist trac ticket is good for smaller, easily defined
chunks, but not for collaboratively deciding (and recording) what the
plan of attack is. It also makes it easier to pick up and see what
the current status of something is. This is more like a SEP (albeit a
small one) than a ticket.
- Robert
Maurizio
http://wiki.sagemath.org/SEP
Unfortunately, it seems I don't have the rights to modify the page I created. I attach here that page, can somebody upload it?
Any comment is greatly appreciated.
Maurizio
William Stein
> I created the wiki page for this in SEP:
>
> http://wiki.sagemath.org/SEP
>
> Unfortunately, it seems I don't have the rights to modify the page I
> created.
know how you setup things so you suddenly can't modify your own wiki
page.
> I attach here that page, can somebody upload it?
>
> Any comment is greatly appreciated.
>
> Maurizio
>
> >
>
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Maurizio
proposals.
I'm sorry but I have been misunderstood: I meant to say that in SEP
(Sage Enhancement Proposal) there was the link to the wiki page I
created: Units of Measurement.
In fact, I didn't mean to substitute that SEP page, but to just fill
the newly created page.
Can you restore the old SEP page, and put the content I sent into the
Unit of Measurement subpage, that is linked by SEP?
Thanks
Maurizio
On 14 Giu, 09:09, William Stein <wst...@gmail.com> wrote:
William Stein
>
> Well, actually SEP was containing a list of links to wiki pages of
> proposals.
>
> I'm sorry but I have been misunderstood: I meant to say that in SEP
> (Sage Enhancement Proposal) there was the link to the wiki page I
> created: Units of Measurement.
> In fact, I didn't mean to substitute that SEP page, but to just fill
> the newly created page.
>
> Can you restore the old SEP page, and put the content I sent into the
> Unit of Measurement subpage, that is linked by SEP?
click edit,
and learn to use moinmoin. Thanks!
William
David Joyner
I'm not sure when you created http://wiki.sagemath.org/Unit%20of%20Measurement
but a "secret question" has been added to the wiki which you have to
answer for each
edit. The answer to the question is (hopefully) pretty obvious. I
think the question
appears near the top of the page after each edit. If you forget, or
don't notice that
question is there, your edits will not be applied.
Maurizio
I am really surprised by how dumb should I have been yesterday. Today
everything looks easy :)
Anyway, I updated the wiki page since I successfully installed Unum in
SAGE. You can see the (pretty encouraging) results there:
http://wiki.sagemath.org/Unit%20of%20Measurement
Any other comment and suggestion is greatly appreciated.
Regards
Maurizio
> I'm not sure when you createdhttp://wiki.sagemath.org/Unit%20of%20Measurement
> answer for each
> edit. The answer to the question is (hopefully) pretty obvious. I
> think the question
> appears near the top of the page after each edit. If you forget, or
> don't notice that
> question is there, your edits will not be applied.
>
William Stein
>
> William, David, thanks for your help.
> I am really surprised by how dumb should I have been yesterday. Today
> everything looks easy :)
>
> Anyway, I updated the wiki page since I successfully installed Unum in
> SAGE. You can see the (pretty encouraging) results there:
>
> http://wiki.sagemath.org/Unit%20of%20Measurement
>
> Any other comment and suggestion is greatly appreciated.
"From my point of view, Unum is very stable. There is no known bug in
Unum 4.0. Very few bugs revealed in previous versions and they have
been corrected. Each new version is verified by a non-regression test
module with more than 200 cases ('test.py' which is part of the
distribution). Actually the design is quite simple, there is just one
class with about 400 lines of codes, including comments. The main
complexity is located in the methods for matching and normalizing
units, which have been thoroughly tested. All this is clearly made
possible by the power of the Python language, which features lists,
dictionaries and operator overloading."
>
> Regards
>
> Maurizio
>
> On 14 Giu, 15:27, David Joyner <wdjoy...@gmail.com> wrote:
>> Maurizio:
>> I'm not sure when you createdhttp://wiki.sagemath.org/Unit%20of%20Measurement
>> but a "secret question" has been added to the wiki which you have to
>> answer for each
>> edit. The answer to the question is (hopefully) pretty obvious. I
>> think the question
>> appears near the top of the page after each edit. If you forget, or
>> don't notice that
>> question is there, your edits will not be applied.
>>
>> On Sat, Jun 13, 2009 at 7:44 PM, Maurizio<maurizio.gran...@gmail.com> wrote:
>> > I created the wiki page for this in SEP:
>>
>> >http://wiki.sagemath.org/SEP
>>
>> > Unfortunately, it seems I don't have the rights to modify the page I
>> > created. I attach here that page, can somebody upload it?
>>
>> > Any comment is greatly appreciated.
>>
>> > Maurizio
> >
>
David Joyner
>
> On Sun, Jun 14, 2009 at 6:56 PM, Maurizio<maurizio...@gmail.com> wrote:
>>
>> Anyway, I updated the wiki page since I successfully installed Unum in
>> SAGE. You can see the (pretty encouraging) results there:
>>
>> http://wiki.sagemath.org/Unit%20of%20Measurement
>>
>> Any other comment and suggestion is greatly appreciated.
>
> Maybe we should include UNUM in Sage...? From the webpage about it:
http://home.scarlet.be/be052320/Unum_tutorial.html#_Toc68111424
Note that the license is GPLv2, not GPLv2+,
http://home.scarlet.be/be052320/license.txt
Maybe someone should contact the package author about that
before a definite move is made?
> "From my point of view, Unum is very stable. There is no known bug in
> Unum 4.0. Very few bugs revealed in previous versions and they have
Mike Hansen
> +1 > I like the "as" method
> http://home.scarlet.be/be052320/Unum_tutorial.html#_Toc68111424
"as" is going to be a keyword in Python 2.6 so this will actually have
to be changed. It makes sense to do it before it's in Sage since it
will break code.
> Note that the license is GPLv2, not GPLv2+,
> http://home.scarlet.be/be052320/license.txt
> Maybe someone should contact the package author about that
> before a definite move is made?
All of the license statements on the source code itself are GPLv2+.
There are also a few changes that should to be done such as something like
try:
from sage.all import Integer
ONE = Integer(1)
except ImportError:
ONE = 1.0
so that it plays nicer with exact arithmetic.
--Mike
Maurizio
> to be changed. It makes sense to do it before it's in Sage since it
> will break code.
>
Python is warning that as is a keyword in 2.6.
> > Note that the license is GPLv2, not GPLv2+,
> >http://home.scarlet.be/be052320/license.txt
> > Maybe someone should contact the package author about that
> > before a definite move is made?
>
> All of the license statements on the source code itself are GPLv2+.
>
> There are also a few changes that should to be done such as something like
>
> try:
> from sage.all import Integer
> ONE = Integer(1)
> except ImportError:
> ONE = 1.0
>
> so that it plays nicer with exact arithmetic.
>
> --Mike
was going to include some examples of Quantites in SAGE as well (for
"par condicio", as they say in Italy).
I don't know what about contacting the author or modifying the code,
but please consider also the effort needed to make it work with the
non-arithmetic functions:
1. trigonometric
2. integration, derivation
3. possibly compatibility with symbolics?
I would consider point (1) the minimum necessary to avoid making Unum
(or any other units package) inclusion meaningless.
Thanks for the interest, anyway
Regards
Maurizio
Maurizio
From the point of view of the code, I can give my impression, but I'm
not experienced in programming.
Unum looks simple and understandable.
Quantities looks more complex, and even finding the right way to look
at is difficult for me. Anyway, this could also mean that the package
is refined and designed from an experienced programmer, so this could
be a pro. Anyway, that would certainly prevent people like me to work
on it :)
Regards
Maurizio
Maurizio
Let me cite him (everything is better explained in the wiki):
- I have another idea for further development, which is more
technical. It is to remove the unit dictionary stored as Unum's class
attributes (which is the cornerstone of the current design !).
Currently, the unit symbol strings are used as keys for this
dictionary; numerous dictionary lookups may occur at unit
normalization or unification. The idea now is that each unum contains
direct references to other unums representing its inner units. More
precisely, basic units (as meter, second, etc) are, by definition,
terminal unums (without references); derived units (as Newton, Joule,
etc) have a dictionary with, as keys, unums representing basic/derived
units, and, as values, their exponents; finally, any quantity may be
derived with the same idea. The big picture at the end is that all
quantities, units and conversion rules boils down to a single
connected graph where each node is a unum. This redesign should save a
lot in time and memory consumption. It requires however to rewrite
almost all Unum's methods. I wrote a small prototype to validate the
concept, with promising results.
This is coming from the last entry of Unum Diary (
http://home.scarlet.be/be052320/Unum_diary.html ). Do you think could
be possible for us to get the prototype from him, and to adapt it to
work with SAGE, in order to take advantage of his experience in
designing a Units of Measurement package, and at the same time to get
the chance to make it work well with SAGE in the early phase of its
development?
The result could be the same to make Quantities work with SAGE, but I
am doubtful if it would take less time to make Quantities work well in
SAGE, rather than adopt this Unum (let's say 5.0 alpha) and possibly
invite the original author to cooperate with us, if he's willing to
and has some spare time.
Regards
Maurizio
William Stein
Well it can't hurt to write to him and ask what he thinks...
There is also the fact that Sage has rings, elements, parents, a
coercion model, etc. which might throw a monkey wrench into everything
(I don't know).
Robert Dodier
> precisely, basic units (as meter, second, etc) are, by definition,
> terminal unums (without references); derived units (as Newton, Joule,
> etc) have a dictionary with, as keys, unums representing basic/derived
> units, and, as values, their exponents; finally, any quantity may be
> derived with the same idea.
important to the unit conversion stuff) that could be simplified
quite a bit by exploiting Sage's capabilities instead of trying
to bolt on an existing package.
If you had a list of equations of derived units in terms of basic
units, you could immediately compute a conversion factor
for two derived units. So the question is how to get such a list.
Unit conversions are conveniently expressed by equations
like foo = bar^m * baz^n. Any such equation defines a derived
unit; basic units or other derived units might appear on the right.
To get conversions to base units, just solve all the equations
for all the derived units. (It's convenient to take logarithms
so the equations are linear.) Then you have every derived unit
expressed in terms of basic units only. When new conversions
are defined, just append the new equations and solve it again.
Symbolic operations (representing equations, solving
equations, log and exp, substitution or evaluation) make that
construction very simple. The whole business with building
a hash table or a graph or whatever is just a workaround for
the lack of symbolic operations.
best
Robert Dodier
Maurizio
so how would be the best way to do this with symbolics in SAGE? I
think the recent switch to pynac requires the community some time to
learn how to use it.
Nonetheless, I sent an email to the author of Unum, so he could at
least point out some suggestions, if not directly help to, write some
code taking advantage of SAGE capabilities, which he may really
benefit.
Thanks for the comment
Regards
Maurizio
Robert Bradshaw
options, Unum sounds like the best fit to me too.
On Jun 15, 2009, at 3:27 AM, William Stein wrote:
> There is also the fact that Sage has rings, elements, parents, a
> coercion model, etc. which might throw a monkey wrench into everything
> (I don't know).
I'm hoping it's able to store the "numeric" part as a black box, and
just multiplies it by constants to convert. Of course, I'm not sure
if everything would quickly be reduced to 53-bit floating point
results precision...
sage: var('x,y')
(x, y)
sage: (x * unum.units.MILE) / (y * unum.units.S)
x/y [mile/s]
sage: (x+90) * unum.units.MIN + (x+pi) * unum.units.H
pi + 1.01666666666667*x + 1.50000000000000 [h]
sage: R.<t> = QQ[[]]
sage: foo = (1/(t+1)) * unum.units.KG; foo
1.0 - 1.0*t + 1.0*t^2 - 1.0*t^3 + 1.0*t^4 - 1.0*t^5 + 1.0*t^6 -
1.0*t^7 + 1.0*t^8 - 1.0*t^9 + 1.0*t^10 - 1.0*t^11 + 1.0*t^12 -
1.0*t^13 + 1.0*t^14 - 1.0*t^15 + 1.0*t^16 - 1.0*t^17 + 1.0*t^18 -
1.0*t^19 + O(t^20) [kg]
sage: getattr(foo, 'as')(unum.units.TON)
0.001 - 0.001*t + 0.001*t^2 - 0.001*t^3 + 0.001*t^4 - 0.001*t^5 +
0.001*t^6 - 0.001*t^7 + 0.001*t^8 - 0.001*t^9 + 0.001*t^10 -
0.001*t^11 + 0.001*t^12 - 0.001*t^13 + 0.001*t^14 - 0.001*t^15 +
0.001*t^16 - 0.001*t^17 + 0.001*t^18 - 0.001*t^19 + O(t^20) [t]
Not bad.
- Robert
Maurizio
wrote:
> options, Unum sounds like the best fit to me too.
>
valuable to somebody.
> On Jun 15, 2009, at 3:27 AM, William Stein wrote:
>
> > There is also the fact that Sage has rings, elements, parents, a
> > coercion model, etc. which might throw a monkey wrench into everything
> > (I don't know).
>
> I'm hoping it's able to store the "numeric" part as a black box, and
> just multiplies it by constants to convert. Of course, I'm not sure
> if everything would quickly be reduced to 53-bit floating point
> results precision...
>
petrush
unit support for SAGE would be highly appreciated for a large audience
dealing with all kind of engineering/physics/etc calculations. It is
not sure that this group is following the development in SAGE today,
since it's known mainly as a mathematics tool and much of these
calculations are done in industry.
As far as I know, today the only low-entry-level tool that does this
is mathcad, which is commercial.
So, your efforts in this area will be highly appreciated, by me and
others... :)
Maurizio
people involved in the development of SAGE, focused on these topics.
Thank you for your comment
Regards
Maurizio
Robert Bradshaw
> I totally agree, but unfortunately it seems there are not so many
> people involved in the development of SAGE, focused on these topics.
This was true of many things that are now in Sage when they started
out. Rather than existing Sage developers focusing on new topics,
usually what happens is people who are interested in these topics
gets involved with the development of Sage (and the community is very
helpful with this), though we do try to be helpful when we can.
You seem like just such a person. :)
- Robert
William Stein
Also, David Ackerman, who is a University of Washington undergraduate,
is going to be doing a Sage development project in August (funded by
the National Science Foundation), and he told me that he's very
interested in doing his project on units.
William