SAGE possible improvement

[Maurizio]

Hello,
I'm forwarding this to sage-devel as well, maybe being the most
appropriate group to address this issue.

I'm a happy user of SAGE, and I won't stop thanking all you guys for
this wonderful job! Although, I also try to encourage you in getting
something better (from my point of view).

It seems there has been some serious thinking about including a UNITS
of MEASUREMENTS managing package in SAGE:
http://groups.google.com/group/sage-devel/browse_frm/thread/8791448b7...

From this, a SAGE trac ticket has been opened (#3852):
http://trac.sagemath.org/sage_trac/ticket/3852

This is supposed to be a MAJOR priority ticket, and I think this is a
very appropriate description!
The ticket has a very good (although a bit old now) description of the
different packages available to deal with units in Python. One of the
options, was the units package included in Enthought. This had the
issue of being under refactoring at that time.

The actual situation seems to be that the Enthought package has not
been changed (https://svn.enthought.com/enthought/ticket/1524) because
of some priority issues in that community (very understandable!), but
another interesting package was born from this Enthought discussion:
the "quantities" package:
http://packages.python.org/quantities/
http://dale.chess.cornell.edu/chess-wiki/Quantities

As I can see, this has already been mentioned in a comment to our trac
ticket, but with no response.

Honestly, I am not able to understand whether this is good enough to
be included in SAGE, neither I am able of understanding how much
refactoring this would need to make this compatible to all the
wonderful symbolic capabilities of SAGE, but nonetheless I think that
getting something working at least in the numeric domain, could be
very useful

With this, I'm not proposing this package over others (for example,
Unum looks very mature, but outdated), I'm just asking if one of you
can spend some minutes to review our trac ticket about units of
measurement (#3852), and to take some other decision about it.

Thank you so much

Maurizio

[Jason Grout]

Maurizio wrote:
> Hello,
> I'm forwarding this to sage-devel as well, maybe being the most
> appropriate group to address this issue.
>
> I'm a happy user of SAGE, and I won't stop thanking all you guys for
> this wonderful job! Although, I also try to encourage you in getting
> something better (from my point of view).
>
> It seems there has been some serious thinking about including a UNITS
> of MEASUREMENTS managing package in SAGE:
> http://groups.google.com/group/sage-devel/browse_frm/thread/8791448b7...
>
> From this, a SAGE trac ticket has been opened (#3852):
> http://trac.sagemath.org/sage_trac/ticket/3852
>
> This is supposed to be a MAJOR priority ticket, and I think this is a
> very appropriate description!

I agree. I should also add that nearly every ticket in trac is marked
as major priority. Indeed, there are lots and lots of things to do on
Sage. That's why we really appreciate your help!

> The ticket has a very good (although a bit old now) description of the
> different packages available to deal with units in Python. One of the
> options, was the units package included in Enthought. This had the
> issue of being under refactoring at that time.
>
> The actual situation seems to be that the Enthought package has not
> been changed (https://svn.enthought.com/enthought/ticket/1524) because
> of some priority issues in that community (very understandable!), but
> another interesting package was born from this Enthought discussion:
> the "quantities" package:
> http://packages.python.org/quantities/
> http://dale.chess.cornell.edu/chess-wiki/Quantities
>

Thanks for tracking this down. I wondered if it would ever get
refactored. What do you think of the Quantities module? I browsed
through the documentation and it looked very interesting. On the plus
side, it's being actively developed now, which I think sets it apart
from any of the other solutions, right?

> As I can see, this has already been mentioned in a comment to our trac
> ticket, but with no response.
>
> Honestly, I am not able to understand whether this is good enough to
> be included in SAGE, neither I am able of understanding how much
> refactoring this would need to make this compatible to all the
> wonderful symbolic capabilities of SAGE, but nonetheless I think that
> getting something working at least in the numeric domain, could be
> very useful
>
> With this, I'm not proposing this package over others (for example,
> Unum looks very mature, but outdated), I'm just asking if one of you
> can spend some minutes to review our trac ticket about units of
> measurement (#3852), and to take some other decision about it.
>

Which package do you prefer? I think at this point, someone needs to
just make a decision with one of the packages and justify it on
sage-devel. Preferably, that person would offer instructions to install
the top one or two (or three?) choices so that people could try them
out. They would probably also give examples of syntax so others could
see (and maybe compare that to the syntax of the other packages).

Installation is easy if you are familiar with the command line. Just do:

$ sage -sh

Then follow whatever instructions the package gives for installation.
That will install the package into Sage's python library.

Thanks,

Jason

[Maurizio]

To be honest, I'd have thought that installing a python package and
let it work with SAGE would have been easier, but one issue could be
that I've been working on this in a Saturday night (after coming back
home) from midnight to 1.30 am!! :)

I summarize the way I got "quantities" (http://pypi.python.org/pypi/
quantities) installed at the end (consider I'm using a VMWare virtual
machine from XP):
1. login as manage
2. sudo su
3. type sage -sh to go into the sage environment
4. unpack and install quantities
5. run SAGE and python and test

The first test failed. I mean, I got it installed and running:
1) unpack the quantities-0.5b2.tar.gz
2) python setup.py install

The result is not satisfying me:

1) if I run python from that sage -sh shell, I can use quantities in
the same way they show in the tutorial (http://packages.python.org/
quantities/user/tutorial.html). They seem to clearly claim that
quantities is still in an advanced beta development phase, so it's not
fully documented, nor available for production (yet).
I can confirm, the documentation seems missing: example

import quantities as pq
pq.Quantity?

File: /usr/local/sage/local/lib/python2.5/site-packages/
quantities-0.5b2-py2.5.egg/quantities/quantity.py
Type: <type 'type'>
Definition: pq.Quantity( [noargspec] )
Docstring:
x.__init__(...) initializes x; see x.__class__.__doc__ for signature

That's it! Seems poor...

2) The biggest issue is that I can't get it to work within a SAGE
notebook:

from numpy import *
import quantities as pq
res = 10*pq.ohm

Traceback (click to the left for traceback)
...
TypeError: unsupported operand parent(s) for '*': 'Integer Ring' and
'<class 'quantities.unitquantity.UnitQuantity'>'

I'm really not that good with all this stuff, but my understanding is
that, whenever you try to define a new object like an integer or a
float number times a "quantities" unit, it somehow forces the number
to become a numpy array. This seems to fail within a SAGE notebook.

Any idea on how this could be fixed, or otherwise should be not?
I am just talking out of couple of minutes working on it, I admit it.

Anyway, I'll try to get the other packages installed as well, although
I am not sure when. Any other suggestion or comment is very well
accepted!

Final comment: should I have done any other sage command to let it
reload or synchronize the newly installed sage packages, before
running the notebook?

Thank you

Maurizio

Maurizio

[Jason Grout]

It sounds like the problems is the known issue that numpy does not
interact very well with Sage data types. Try this:

from numpy import *
import quantities as pq

res = 10r*pq.ohm

The 10r means to create a python integer, rather than a Sage integer.

It sounds like there could/should be a small change in quantities made
to support Sage datatypes. My guess is that it would take just a few
minutes.

Jason

[Carl Witty]

On Sat, Mar 14, 2009 at 1:21 AM, Jason Grout
<jason...@creativetrax.com> wrote:

>
> Maurizio wrote:
>> With this, I'm not proposing this package over others (for example,
>> Unum looks very mature, but outdated), I'm just asking if one of you
>> can spend some minutes to review our trac ticket about units of
>> measurement (#3852), and to take some other decision about it.
>>
>
> Which package do you prefer? I think at this point, someone needs to
> just make a decision with one of the packages and justify it on
> sage-devel.  Preferably, that person would offer instructions to install
> the top one or two (or three?) choices so that people could try them
> out.  They would probably also give examples of syntax so others could
> see (and maybe compare that to the syntax of the other packages).

By the way, fergusnoble on IRC was working on a units package for Sage
a few days ago. Unfortunately, I don't know his email address, but
Nicolas Thiery does.

Carl

[Maurizio]

Does he keep track of his experiment somewhere on the net? I would
like to have a look at it.

By the way, this effort is certainly good, but one of the biggest
merit of SAGE was (in my modest opinion) the idea to not reinvent the
wheel as long as it's possible. (I hope SAGE is not changing its path,
in reimplementing basics in its own way...)

So, in this case I can see that the "unit of measurements" package
shouldn't be too much of effort to build one from scratch, so trying
to adapt an existing one to work with SAGE couldn't be the best choice
in this case, nonetheless I am wondering if the other opportunities
out there (there are at least three, as you can see in the trac
ticket) have been previously explored to take some advantage! There
are non-trivial issues like compound units management that may have
already been successfully faced.

Regards

Maurizio

[Maurizio]

Thank you Jason, I'll try it as soon as possible.

By the way, have you got any idea about where in the code should I
look at to let it work with SAGE numbers? Something like constructors
or stuff like that?

Thanks

Maurizio

[Maurizio]

Ok, let me add another long post to this conversation... hopefully you
have enough patience!! This is probably known stuff for some of you,
but I'm sure some others will learn something! I kindly ask you to try
to go through all this post, I think it will be worthwile.

Short and not so important things first: why can't I get method
suggested by Jason to get Python integers in SAGE work from the
notebook? I mean:

import quantities as pq
res = 10r*pq.ohm

works in sage (run from the command line), but not from the notebook!
I get the same error, and I also get

value = 10
type(value)
<type 'sage.rings.integer.Integer'>
value = 10r
type(value)
<type 'sage.rings.integer.Integer'>

But from sage command line I correctly get type(10r) = python integer!
Why is that?

Let's go to the units package discussion. I had a look at this (not so
new) discussion in the enthought mailing list:
https://mail.enthought.com/pipermail/enthought-dev/2007-September/009125.html

Let's consider the "units" package in enthought the equivalent of the
"father" of "quantities", hoping that I understood everything
correctly. Let me cite the author of "quantities":

<Citation>
I've been working on an ndarray subclass which could unify these two
packages. Unit conversion is handled by UDUnits, which is compatible
with the terms of the BSD. I've done some preliminary unittesting and
things look good on both windows and linux. I'm waiting for numpy-1.2
to be released so I can use the incorporated nose-based unit-testing
framework to continue writing unittests.

The package is available at http://dale.chess.cornell.edu/chess-wiki/Quantities
. The package only depends on numpy, and does not require Traits, so I
was thinking it might be better to continue development as a scikit
and decide later where and how to incorporate it into enhought, scipy,
numpy, or none of the above.
</Citation>

In the enthought mailing list, they claim that: "The units package is
very stable, but perhaps lacking in documentation.". Which is pretty
good. Then, another person in that thread states:
"Have you guys look at scientificPython's units ? I use them through
ipython shorthands and they are pretty good. It won't run on your
system
because you don't have the required modules (well, I could make it
run,
but it's not worth it), and it needs to be ran through ipython, with
the
"physcis" profile".
So I discovered this (reference:
http://modular.math.washington.edu/home/jvoight/sage-2.10.2/local/share/doc/ipython-0.8.1/manual.pdf
):
"The module PhysicalQInput allows a simplified form of input for
physical quantities with
units. This file is meant to be used in conjunction with the
PhysicalQInteractive module
(in the same directory) and Physics.PhysicalQuantities from Konrad
Hinsen’s ScientificPython
(http://dirac.cnrs-orleans.fr/ScientificPython/)."
So, it seems that PhysicalQuantities (together with the "physics"
profile of iPython, which could be maybe used in SAGE, if needed??),
is pretty much a standard thing for Python (which seems VERY good!),
so let me investigate why these enthought guys needed something
different (reference: reply in the same previous mailing list):
"enthought.units provides a similar mechanism, if thats the route you
want to go. The reason we don't typically use the package that way is
because unit conversions because if forces explicit unit conversion.
Say
we were to send a probe to mars, and somewhere in our code we used
metric, and other places we used imperial, we would have to know at
what
points the two unit systems required conversion. Otherwise, the probe
burns up in the atmosphere... Some of our apps have data in multiple
unit systems, so having the automatic conversion is a big plus, but
this
may not be true for every app."
I have to admit I totally agree with this guy, so I am basically going
for enthought's approach! But, wait a minute, what if I install
SciMath (the enthought package) I downloaded last night?

Well, the result is not that good, because you basically need a lot of
other enthought stuff to let enthought.units work:

from enthought import units

Traceback (click to the left for traceback)
...

ImportError: No module named util.resource

The problem is that you have to modify "units" from SciMath to let it
work without the enthought util environment. I'm not that into doing
this.

To summarize stuff:
1) the Python standard seems to be iPython + "physics" profile +
Scientific Python
2) the Enthought suite uses two different packages, but it "seems"
that the most used is "units", and one big plus is the ability to mix
together (as they say, I was not able to verify it) different units of
the same physical quantity and let the "decorator" do the translation
job to some preassigned standard for that quantity
3) the Quantities package has been developed as a refactoring and
joining of the two Enthought package, although this units mixing
(claimed as possible in Enthought) seems not natively supported (if I
try to add 10 inches and 10 meters I get an error... I can't even add
meters and centimeters!) which is not good. A good plus about
"quantities" is that it seems actively developed, as I can see from
their active mailing list:
https://lists.launchpad.net/python-quantities-developers/threads.html

I can see that in the middle of January they were thinking about their
timeline, since they presented something to the SciPy community
recently, and had some good feedback.
They are currently discussing about being almost ready to present
something to the numpy community, so they seems satisfied with what
they have now:
https://lists.launchpad.net/python-quantities-developers/msg00057.html

Don't you think it would be REALLY useful for us to try to discuss
with them (I'm sure some of you guys, can represent this SAGE
community much better than I do), and to ask them if they are willing
to work with us on making quantities compatible with one of our
symbolic packages? They seem pretty experienced about this package,
seem willing to improve their work, and this is (in my opinion) going
to be a VERY BIG PLUS for SAGE!!

I mean, I don't think anything out there is actually able to manage
symbolics and units at the same time, do you?

I'm very eager to see your comments, hoping that you get my passion
and enthusiasm!

Best regards

Maurizio

[Carl Witty]

On Sun, Mar 15, 2009 at 12:57 PM, Maurizio <maurizio...@gmail.com> wrote:
>
> Ok, let me add another long post to this conversation... hopefully you
> have enough patience!! This is probably known stuff for some of you,
> but I'm sure some others will learn something! I kindly ask you to try
> to go through all this post, I think it will be worthwile.
>
> Short and not so important things first: why can't I get method
> suggested by Jason to get Python integers in SAGE work from the
> notebook? I mean:
>
> import quantities as pq
> res = 10r*pq.ohm
>
> works in sage (run from the command line), but not from the notebook!
> I get the same error, and I also get
>
> value = 10
> type(value)
> <type 'sage.rings.integer.Integer'>
> value = 10r
> type(value)
> <type 'sage.rings.integer.Integer'>
>
> But from sage command line I correctly get type(10r) = python integer!
> Why is that?

This was bug #5356; it's been fixed in Sage 3.4. So you could upgrade
to 3.4, or as a workaround you could use
value = int(10)
instead.

Carl

[Nicolas M. Thiery]

I just ping'ed him.

Best,
Nicolas
--
Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

[fergu...@gmail.com]

Hi,

Thanks for emailing me Nicolas.

I had a quick play with writing a units extension really just to learn
more about SAGE. I've only just started writing this so its still a
way off being ready for prime time but so far you can create
quantities with units, manipulate them like any other number and
convert to different units. There is also a sub-library of common
physical constants with units.

I hadn't heard of the Quantity package until just now but it looks
much more mature than what I have been working on. I took a slightly
different approach in that in my code quantities are always kept in SI
base units so simplification is never necessary but that means that
sometimes it makes assumptions about what units the user would like
the results in e.g.

(10 * meter)**3 / (5 * ft)**2

will give 40 m**3/ft**2 in Quantity as it is unclear whether the user
wants the result in meters or feet and the user must explicitly
simplify the result to the unit they wanted, whereas in my code will
always output in meters and the user can convert it to feet if needed.
This also means you can add dissimilar units of the same
dimensionality and the result will just end up in SI units.

I will clean up my code and make a little demo so people can play with
it when I have a bit more free time on tuesday, if anyone is
interested. I'm still keen to keep developing my implementation but I
can see that porting Quantity to work with SAGE might be a quicker way
to get a mature units system up and running.

Thanks,
Fergus

[Maurizio]

Hi Fergus,

thank you for your comments!
So, do you consider working on a Quantity porting worthwhile? It seems
that you got some good experience by working on it, so you can
probably give some better advice about the structure of that package.

Moreover, I'm wondering how much work would it require to try to allow
symbolic support for SAGE for Quantities or any other units package.

Regarding the output of such expression you wrote, I agree that it
should give a standard unit output for each physical quantity, so by
presetting SI (or imperial, or anything else), it should give just
meters (or feets, or anything else)...

Regards

Maurizio

On 16 Mar, 00:55, "fergusno...@gmail.com" <fergusno...@gmail.com>
wrote:

[Jason Grout]

Maurizio wrote:
> Hi Fergus,
>
> thank you for your comments!
> So, do you consider working on a Quantity porting worthwhile? It seems
> that you got some good experience by working on it, so you can
> probably give some better advice about the structure of that package.
>
> Moreover, I'm wondering how much work would it require to try to allow
> symbolic support for SAGE for Quantities or any other units package.

As far as the Quantities package goes, it seems to be the problems that
we have always seen between numpy and sage types. I'm not quite sure
what is going on. A Quantity is just a subclass of ndarray. Here are a
few lines illustrating the line where the problem occurs. How come, in
the first case, NotImplemented is returned?

sage: import quantities as pq
sage: other_sage=numpy.asarray(10).view(pq.Quantity)
sage: super(pq.Quantity, pq.ohm).__mul__(other_sage)
NotImplemented

That is what causes the error. However, when we convert the numpy array
representing other to a python integer array, we get something that we
can use:

sage: super(pq.Quantity, pq.ohm).__mul__(other_sage.astype(int))
array(10.0)*dimensionless

Without the supers above, these two examples are:

sage: import numpy
sage: numpy.ndarray.__mul__(numpy.array(float(1.0)),other_sage)
NotImplemented
sage: numpy.ndarray.__mul__(numpy.array(float(1.0)),other_sage.astype(int))
array(10.0)*dimensionless

Does anyone know what is going on here? I'm not sure where the source
of numpy.ndarray.__mul__ is.

Thanks,

Jason

[Robert Dodier]

Maurizio wrote:

> Regarding the output of such expression you wrote, I agree that it
> should give a standard unit output for each physical quantity, so by
> presetting SI (or imperial, or anything else), it should give just
> meters (or feets, or anything else)...

I'm pretty sure that would cause more trouble than it's worth.
Whatever the standard, there could well be nonstandard combinations
such as centimeters per day or liters per kilometer, which should
be preserved as such. In the US, which is an important enough
audience to be accomodated in the design of a units package,
mixed-up units from different standards or no standards at all are
very common, and should be preserved as such.
And whatever the system or lack of it, it would be annoying to
change fractional or multiple units (inches, kilometers, etc) to
their base units (feet, meters, etc).

The point is to accomodate the user, who has a better idea about
what they want to accomplish than the package writer.

FWIW

Robert Dodier

[Maurizio]

In fact my idea is a bit different, and I'll explain in a minute:
provided that the system is SI, you should get the result as a
multiplier (bigger than one) of the closest classic unit
representation
ex: meters -> nm - um - mm - m - km - ecc ecc
ex:

x1 = 10cm
x2 = 1m
x1 + x2 = 1.1m

y1 = 1V (Volt)
y2 = 0.5 V
y1 - y2 = 500 mV

z1 = 500 mA [milliAmperes]
k = 3
z1 * k = 1.5 A

Does this looks reasonable? I find this very comfortable!

Regarding imperial system, the same could be done, even though this is
just a bit tougher because of the fractional multipliers, but the
principle can stay the same.

Two optional features could be very important, in my opinion:
1) locking one object unit representation to a certain order of
magnitude and/or metric system

ex:
x1 = 1 cm
x1.lock('cm')
x2 = x1 + 1 m [x2 can inherit the lock property]
x2 = 101 cm
x2.lock('inches')
x2 = 39.76 inches
x2.unlock()
x2 = 1.01 m

PS: locking property could also be specified when instantiating an
object

2) changing the standard metric system (imperial / SI / any other) so
that by default each value is scaled as previously proposed

Any comment?

Thanks

Maurizio

[Robert Bradshaw]

On Mar 14, 2009, at 6:29 PM, Jason Grout wrote:

> It sounds like the problems is the known issue that numpy does not
> interact very well with Sage data types. Try this:
>
> from numpy import *
> import quantities as pq
> res = 10r*pq.ohm
>
> The 10r means to create a python integer, rather than a Sage integer.
>
> It sounds like there could/should be a small change in quantities made
> to support Sage datatypes. My guess is that it would take just a few
> minutes.

+1 It'd be cool if one could do arbitrary Sage types (not just
floating point numbers). For example

sage: var('x')
sage: (x * feet).lock('inches')
12*x

At least rationals would be nice.

- Robert

[Maurizio]

Hi

can anyone give an advice on how to adapt Quantities to let it be
compatible with SAGE? I don't know how SAGE modifies the way to
represent numbers, and why it does not comply with Quantities.

For example, how does SAGE generate an instance of
"sage.rings.integer.Integer"? I hope this can help me. Actually, I
wasn't able to understand how Quantities deals with numbers, because
it basically transform any python int or float multiplied by a
physical unit, into a numpy array (either a single element or a
vector) with unit "dimensionless". I think there would be nothing
wrong with continue using normal sage integers or float as
dimensionless, even though I don't know how could we manage an object
given by the multiplication of an integer and a physical unit: would
this become a "quantity" instance? This would be fast to implement,
because that's the way it is now. Nonetheless, this is not the way I
would like it to do, because it would cause the necessity to add in
quantity the way to deal with all the possible types in SAGE (also
symbolics, in future?).

Is there any chance to do something like putting the physical quantity
like a property of the existing numerical (and in future any other)
class? I'm just wondering if is there any good way to do this, and if
I would be able to try to work on that.

I've to admit, I'd like to be better in python programming, and to
have more time to work on it. Until now, with a simple one-line
modification, I has been able to let "quantities" accept the sum of
coherent physical quantities, but I didn't manage to get the
representation I was talking about on the previous post yet,
especially because the "quantities" package is not really intended
that way: the way I would have tried to produce something like that,
is by distinguishing the units (e.g. Volts, Amperes, meters, ecc) from
the multipliers (milli, micro, kilo, ecc) and then try to find a way
to effectively combine them (in the expected way, like using the
multipliers as a prefix to the unit: m+V = mV, centi+meter=cm, ecc).
This seems more logical to me.

Another option, is to try to write this from scratch, trying to derive
the most from others available packages out there (it's not really
that much of lines of code), but I would not prefer to produce ANOTHER
package about that! What do you think?
I would prefer to keep that package, and simply try to apply some
short differential patch to it to get a SAGE compatible version, but
I'm not sure if I'll be able to.

Thank you for your time

Maurizio

[William Stein]

On Thu, Mar 19, 2009 at 3:45 PM, Maurizio <maurizio...@gmail.com> wrote:
>
> Hi
>
> can anyone give an advice on how to adapt Quantities to let it be
> compatible with SAGE? I don't know how SAGE modifies the way to
> represent numbers, and why it does not comply with Quantities.
>
> For example, how does SAGE generate an instance of
> "sage.rings.integer.Integer"? I hope this can help me. Actually, I
> wasn't able to understand how Quantities deals with numbers, because
> it basically transform any python int or float multiplied by a

Does Quantities have any code that looks like this:

if isinstance(foo, (int, long)):
...

or anything remotely like that? If so, you just have to change it to

int_types = (int, long, Integer)
if isistance(foo, int_types):
...

William

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[Maurizio]

Thank you for your help.
I realize now how silly it has been to ask such a general question
here, with you guys just guessing. Even this not being the solution,
this has still been helpful for me to understand something more.

Hopefully, I'll get more into it.

By the way, any other comment about all the other facts?

Thanks

Maurizio

On 19 Mar, 23:48, William Stein <wst...@gmail.com> wrote:

[Carl Witty]

On Thu, Mar 19, 2009 at 3:45 PM, Maurizio <maurizio...@gmail.com> wrote:
> For example, how does SAGE generate an instance of
> "sage.rings.integer.Integer"? I hope this can help me.

Well, I can at least answer this question. When you type at the sage:
prompt, or in the notebook, the input is run through the "preparser";
this transforms the input from Sage's extended Python syntax into
standard Python.

You can see what it does using the preparse function:

sage: preparse('3')
'Integer(3)'
sage: preparse('3.14159')
"RealNumber('3.14159')"

Carl

[Jason Grout]

Maurizio wrote:
> Hi
>
> can anyone give an advice on how to adapt Quantities to let it be
> compatible with SAGE? I don't know how SAGE modifies the way to
> represent numbers, and why it does not comply with Quantities.
>
> For example, how does SAGE generate an instance of
> "sage.rings.integer.Integer"? I hope this can help me. Actually, I
> wasn't able to understand how Quantities deals with numbers, because
> it basically transform any python int or float multiplied by a
> physical unit, into a numpy array (either a single element or a
> vector) with unit "dimensionless". I think there would be nothing
> wrong with continue using normal sage integers or float as
> dimensionless, even though I don't know how could we manage an object
> given by the multiplication of an integer and a physical unit: would
> this become a "quantity" instance? This would be fast to implement,
> because that's the way it is now. Nonetheless, this is not the way I
> would like it to do, because it would cause the necessity to add in
> quantity the way to deal with all the possible types in SAGE (also
> symbolics, in future?).

Not necessarily. As I understand it, quantities are just numpy arrays,
basically. Those numpy arrays should be able to contain and deal with
any type (sage or python or whatever).

I tracked down where the error was in what you posted before. I think
if we could get the following two expressions to return the same thing,
we may be good to go. Does anyone know what is going on here?

sage: import quantities as pq
sage: other_sage=numpy.asarray(10).view(pq.Quantity)

sage: import numpy
sage: numpy.ndarray.__mul__(numpy.array(float(1.0)),other_sage)
NotImplemented
sage: numpy.ndarray.__mul__(numpy.array(float(1.0)),other_sage.astype(int))
array(10.0)*dimensionless

Thanks,

Jason

[Jason Grout]

Maurizio wrote:
> Hi
>
> can anyone give an advice on how to adapt Quantities to let it be
> compatible with SAGE? I don't know how SAGE modifies the way to
> represent numbers, and why it does not comply with Quantities.

Have you asked the Quantities developers to look at this thread? My
guess is that they would be very interested in having Quantities
integrated in with Sage, as it immediately gives them a far greater user
base and exposure (and bug reports!) than otherwise. Besides, they
would probably be better able to work on this than most other people.

Thanks,

Jason

[Maurizio]

Not yet... I think I was previously asking whether some of you guys
are interested in trying to contact them, if you do think it does
makes sense.

I mean, if this community is interested in having this feature, the
Quantities developers are going to find some good feedback, otherwise,
we could just probably end up losing a good occasion, because things
are not ready yet (although I hope that's not the case)!

Regards

Maurizio

[Jason Grout]

Maurizio wrote:
> Not yet... I think I was previously asking whether some of you guys
> are interested in trying to contact them, if you do think it does
> makes sense.
>
> I mean, if this community is interested in having this feature, the
> Quantities developers are going to find some good feedback, otherwise,
> we could just probably end up losing a good occasion, because things
> are not ready yet (although I hope that's not the case)!
>

I think there are a good number of people now that would like to have
the feature, and as you well know, there are lots and *lots* of future
users that would like to have the functionality.

I'd say it's time to contact them and see if they can help. If there
needs to be changes made to Quantities, then making them now, while it
is still solidifying, would be advantageous.

Jason

[Darren Dale]

On Mar 20, 10:31 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
> Maurizio wrote:
> > Not yet... I think I was previously asking whether some of you guys
> > are interested in trying to contact them, if you do think it does
> > makes sense.
>
> > I mean, if this community is interested in having this feature, the
> > Quantities developers are going to find some good feedback, otherwise,
> > we could just probably end up losing a good occasion, because things
> > are not ready yet (although I hope that's not the case)!
>
> I think there are a good number of people now that would like to have
> the feature, and as you well know, there are lots and *lots* of future
> users that would like to have the functionality.
>
> I'd say it's time to contact them and see if they can help.  If there
> needs to be changes made to Quantities, then making them now, while it
> is still solidifying, would be advantageous.

Hello, I am Darren Dale, the developer of Quantities. Thank you
Maurizio for contacting me. I would like to request that discussions
concerning Quantities on this list also be sent to my gmail account.
My work will keep me very busy for the next 10 weeks, and since it
seems this list gets a fair amount of traffic and I am not yet a sage
user, I would prefer not to follow the list too closely, at least for
now.

Let me explain my background and that of quantities. I am a scientist
at the Cornell High Energy Syncrotron Source (CHESS), and have been a
developer on the matplotlib project for several years. I have been
interested in having a units package for python for a long time. I
have considered all the units packages discussed so far in this
thread, but did not find one that suited my needs. I make heavy use of
numpy arrays for my work, and wanted a numpy subclass that handled
physical quantities. It has taken several iterations but I finally
found an appropriate abstraction for such a package. Quantities is
already in pretty good shape, in large part because it does not try to
do too much. I am currently trying to improve Quantities interaction
with numpy's builtin functions, however, I have run into some
limitations in numpy, mainly in the implementation of ufuncs. If you
are interested, please search the numpy archives for my name. I have
suggested on that list how things could be improved, but the devs are
busy preparing to release numpy-1.3. I will try to engage them again
after 1.3 is out.

I have been spending most of my effort on Quantities recently
improving the unit tests. This uncovered a few bugs in numpy that have
been fixed in time for the 1.3 release. If you run pq.test() with
numpy-1.2, you will encounter errors that have been fixed in 1.3.

I would be willing to consider how quantities can be improved so it
can be used in the sage environment, but it sounds like there are some
existing issues with the interaction of sage types and numpy arrays
which need to be worked out first. Have I understood correctly?

I have been meaning to change addition/subtraction in Quantities to
allow things like m+cm without explicitly rescaling one of the
operands. I will change it so the result has the same units as the
left operand.

I am not interested implementing the feature proposed in post #16 in
this thread. Dealing with physical quantities can be somewhat thorny,
because there are lots of use cases and everybody seems to have their
own ideas about how it should behave. Case in point, the proposal in
post #16 would keep units the way you like them for scalars, but it
would create additional overhead in cases like 1m-0.999999m. In that
case, I guess the proposed behavior would be to yield 1um as the
result, which means quantities would have to a) determine the
appropriate final unit and b) would have to perform additional
arithmetic. Quantities is not really designed to handle item a. I've
tried to keep the package as simple as possible in order to keep the
problem tractable in my limited free time. Item b would be
unacceptable to those concerned about speed. Automatically rescaling
the result becomes more complicated with arrays, since you would then
have to inspect the min, max or mean in order to determine how to
rescale the output, and there are plenty of compound operations sqrt(x
+y**3/(...)...) where the user would only be interested in rescaling
the final result, not the result of each individual step of
arithmetic. There are plenty of examples, like operations involving
constants for quantum mechanics or astrophysics, where the user wants
the result in the units specified by the constants.

I guess the question I have for this list is, what would be required
for quantities to work in sage? I would prefer to try to work out the
numpy issues I alluded to before quantities gets too much exposure, in
case changes in API are required (unlikely).

Darren

[Robert Bradshaw]

On Mar 22, 2009, at 6:49 AM, Darren Dale wrote:

> On Mar 20, 10:31 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
>> Maurizio wrote:
>>> Not yet... I think I was previously asking whether some of you guys
>>> are interested in trying to contact them, if you do think it does
>>> makes sense.
>>
>>> I mean, if this community is interested in having this feature, the
>>> Quantities developers are going to find some good feedback,
>>> otherwise,
>>> we could just probably end up losing a good occasion, because things
>>> are not ready yet (although I hope that's not the case)!
>>
>> I think there are a good number of people now that would like to have
>> the feature, and as you well know, there are lots and *lots* of
>> future
>> users that would like to have the functionality.
>>
>> I'd say it's time to contact them and see if they can help. If there
>> needs to be changes made to Quantities, then making them now,
>> while it
>> is still solidifying, would be advantageous.
>
> Hello, I am Darren Dale, the developer of Quantities. Thank you
> Maurizio for contacting me.

Glad to hear from you.

[...]

> I guess the question I have for this list is, what would be required
> for quantities to work in sage? I would prefer to try to work out the
> numpy issues I alluded to before quantities gets too much exposure, in
> case changes in API are required (unlikely).

Am I correct in understanding that the values in Quantities all need
to be NumPy values? If this is the case, it probably boils down to
NumPy's not handling of non-Python types. This really needs to get
resolved.

- Robert

[Darren Dale]

Quantities values are all instances of Quantity or a subclass thereof, and Quantity itself is a subclass of ndarray. It sounds like the first step would be to work out this compatibility issue between sage objects and ndarray. Has anyone brought it up at numpy-discussion?

[Maurizio]

People,
I'm really glad about having brought this discussion to a reasonably
interesting level.

From now on, I can't give any other comment (I can't deal with code so
specific issues), but I'd like to hear those coming from the
mantainers of SAGE.
As far as I'm concerned, I was trying to get the attention of
Quantities' developers, and I think I accomplished this in a fairly
satisfying way. I can try to give my comments now, but the situation
now seems to be tightly related on whether there is any chance that
anybody works on anything.
So, words are becoming less important than actions in this phase, in
my opinion.
By the way, to me, it doesn't seem that dealing with numpy quantities
should be a big deal (at least for the time being), otherwise how
comes are we using already numpy for numerical stuff at the moment? I
know this could be bad for my final aim (that is, bringing physical
units to a higher degree of functionalities, related to polynomials
and symbolic, and I've seen that other people have interest in this),
because maybe getting this simple feature could calm down this
discussion and let people forget this issue.

To connect to the other discussion we are having in this days, I think
this engineering related features should be enhanced and stressed (and
possibly clearly documented), and I don't think this needs to create
another distribution of SAGE, the current one is very good and I'd
like to have a single version.

I still encourage you guys to at least give your comments

Regards and thanks everybody

Maurizio

On 23 Mar, 21:03, Robert Bradshaw <rober...@math.washington.edu>
wrote:

[Jason Grout]

Not that I'm aware of. As far as I can tell, the root of the problem
boils down to what was explained in
http://groups.google.com/group/sage-devel/msg/f0e3d8d7c5a05afa

Do you know what is going on (why a "NotImplemented" is returned)? Or
more importantly, do you know if that is something that we need to
implement, or something that numpy needs to implement?

If you don't know the answer off the top of your head, I agree that
posting to the numpy list is the best thing.

Thanks,

Jason

[Maurizio]

Hi everybody.

I see this discussion is getting less focus in this moment.

I am fine with this, I see people has a lot of stuff to do. At the
same time, would you please consider updating the open ticket on SAGE:

http://trac.sagemath.org/sage_trac/ticket/3852

I think this would make at least this discussion useful for the
future.

Best regards

Maurizio

> another distribution ofSAGE, the current one is very good and I'd

> > > for quantities to work insage? I would prefer to try to work out the