headers
Darren Dale | 1 Aug 15:50
Picon
Gravatar

Re: physical quantities: udunits?

Hi Charles,

On Thursday 31 July 2008 06:56:33 pm you wrote:
> Ok looks like our security update was a bit too strong :) can you try
> again ?

Thanks, I am able to grab the sources now.

I did a search on the web a few days ago to see if udunits can be used on 
Windows. The answer appeared to be no, but I tried installing your unidata 
python package on windows anyway.

There is no windows binary for Numeric and python-2.5, so I tried a first 
order workaround by changing the Numeric include in udunits_wrap.c to:

#include "numpy/arrayobject.h"

This required importing numpy in your setup script and adding 
numpy.get_include() to the list of include_dirs in your extension 
constructor. I also had to modify the path where udunits is installed, in 
both setup.py and udunits.py. (moving udunits.dat into Lib would allow the 
library to be installed using distutils package_data, I think.)

I am happy to say that I was able to build the package with mingw, install it, 
and run the test script. I didn't see any problems (but I didn't really know 
what to look for).

Would you mind posting a link to your udunits2 package?

Based on your nice work here, and the appearance of windows compatibility, it
(Continue reading)

Permalink | Reply | 2 comments |
headers
Charles Doutriaux | 1 Aug 16:28

Re: physical quantities: udunits?

Hi Darren,

Here are some examples:
 >>> a = unidata.udunits(1,'m')
 >>> a.to('cm')
udunits(100.0,"cm")

You can also use:
a.known_units()
or
a.available_units()

Come to think of it I should change it so it only shows units compatible 
with "a"

Anyway, sorry I pointed to the "trunk" version, I forgot it is still 
Numeric based. Or devel version is numpy based.

you can access it at:
svn export 
http://www-pcmdi.llnl.gov/svn/repository/cdat/branches/devel/Packages/unidata
user: guest
psswd: cdatdevel

It is indeed based on udunits (not udunits2). I should upgrade.

You're right we could probably subclass numpy. Do you want to do it?

Honestly I don't think i'll have time in the next month or so.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Darren Dale | 1 Aug 16:53
Picon
Gravatar

Re: physical quantities: udunits?

Hi Charles,

Yes, I think I would like to take a shot at this. I have been meaning to get 
back to the matplotlib documentation effort, but I really need this for work. 
I'll look into it this weekend.

Thanks,
Darren

On Friday 01 August 2008 10:28:29 am Charles Doutriaux wrote:
> Hi Darren,
>
> Here are some examples:
>  >>> a = unidata.udunits(1,'m')
>  >>> a.to('cm')
>
> udunits(100.0,"cm")
>
> You can also use:
> a.known_units()
> or
> a.available_units()
>
> Come to think of it I should change it so it only shows units compatible
> with "a"
>
> Anyway, sorry I pointed to the "trunk" version, I forgot it is still
> Numeric based. Or devel version is numpy based.
>
> you can access it at:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nils Wagner | 2 Aug 11:56
Picon
Favicon

SciPy 0.7 release - pending tickets

Hi all,

Ticket 704 can be closed.
http://scipy.org/scipy/scipy/ticket/704

The following tickets can be easily closed after an update 
of the docstring.

http://scipy.org/scipy/scipy/ticket/677
http://scipy.org/scipy/scipy/ticket/666

The functions read_array and write_array are deprecated.
Is it reasonable to close ticket

http://scipy.org/scipy/scipy/ticket/568

in this context ?

Ticket 626 can be closed. Works for me.
http://scipy.org/scipy/scipy/ticket/626

Nils
Permalink | Reply | 5 comments |
headers
Nils Wagner | 2 Aug 12:08
Picon
Favicon

Re: SciPy 0.7 release - pending tickets

On Sat, 02 Aug 2008 11:56:17 +0200
  "Nils Wagner" <nwagner <at> iam.uni-stuttgart.de> wrote:
> Hi all,
> 
> Ticket 704 can be closed.
> http://scipy.org/scipy/scipy/ticket/704
> 
> The following tickets can be easily closed after an 
>update 
> of the docstring.
> 
> http://scipy.org/scipy/scipy/ticket/677
> http://scipy.org/scipy/scipy/ticket/666
>  
> The functions read_array and write_array are deprecated.
> Is it reasonable to close ticket
> 
> http://scipy.org/scipy/scipy/ticket/568
> 
> in this context ?
> 
> Ticket 626 can be closed. Works for me.
> http://scipy.org/scipy/scipy/ticket/626
> 
> Nils
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev <at> scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
(Continue reading)

Permalink | Reply | 1 comment |
headers
Darren Dale | 2 Aug 19:25
Picon
Gravatar

design of a physical quantities package: seeking comments

I have been thinking about how to handle physical quantities by subclassing 
ndarray and building on some of the ideas and code from
Charles Doutriaux python wrappers of udunits and Enthought's units package.

I would like to share my current thinking, and would appreciate some feedback 
at these early stages so I can get the basic design right.

The proposed Quantity object would be an ndarray subclass with an additional 
attribute and property:

* Quantity has a private attribute, a Dimensions container, which contains 
zero or more Dimension objects, each having associated units (a string) and a 
power (a number). The container object would be equipped with the various 
__add__, __sub__, __mul__, etc. Before performing the operations on the 
ndarray values, the operation would be performed with the Dimensions 
containers, either updating self's Dimensions and yielding the conversion 
factors required to scale the other quantity's values to perform the ndarray 
operation, or raising an exception because the two dimensionalities are not 
commensurate for the particular operation. I think this container approach is 
necessary in order to allow scaling of each Dimension's units individually, 
simplifying operations like 11 ft mA / ns * 1 hour = many ft mA.

* Quantity has a public units property, providing a view into the object's 
dimensions and the ability to change from one set of units to another. 
q.units would return the Dimensions instance, whose __repr__ would be 
dynamically constructed from each dimension's units and power attributes. The 
setter would have some limitations by design. For example if q has units of 
kg m / s^2 and you do q.units='ft', then q.units would return kg ft /s^2.

I think the Dimensions container may provide enough abstraction to handle more
(Continue reading)

Permalink | Reply | 12 comments |
headers
Anne Archibald | 2 Aug 22:23
Picon

Re: design of a physical quantities package: seeking comments

2008/8/2 Darren Dale <dsdale24 <at> gmail.com>:
> I have been thinking about how to handle physical quantities by subclassing
> ndarray and building on some of the ideas and code from
> Charles Doutriaux python wrappers of udunits and Enthought's units package.

This sounds like a very handy tool, but you want to be careful to keep
it tractable.

> I would like to share my current thinking, and would appreciate some feedback
> at these early stages so I can get the basic design right.
>
> The proposed Quantity object would be an ndarray subclass with an additional
> attribute and property:
>
> * Quantity has a private attribute, a Dimensions container, which contains
> zero or more Dimension objects, each having associated units (a string) and a
> power (a number). The container object would be equipped with the various
> __add__, __sub__, __mul__, etc. Before performing the operations on the
> ndarray values, the operation would be performed with the Dimensions
> containers, either updating self's Dimensions and yielding the conversion
> factors required to scale the other quantity's values to perform the ndarray
> operation, or raising an exception because the two dimensionalities are not
> commensurate for the particular operation. I think this container approach is
> necessary in order to allow scaling of each Dimension's units individually,
> simplifying operations like 11 ft mA / ns * 1 hour = many ft mA.

I think it's a good idea to try to keep things in the units they are
provided in; this should reduce the occurrences of unexpected
overflows when (for example) cubing a distance in megaparsecs (put
this in centimetres and use single precision and you might overflow).
(Continue reading)

Permalink | Reply | 11 comments |
headers
Jarrod Millman | 2 Aug 22:28
Picon
Favicon
Gravatar

ANN: NumPy 1.1.1

I'm pleased to announce the release of NumPy 1.1.1.

NumPy is the fundamental package needed for scientific computing with
Python.  It contains:

 * a powerful N-dimensional array object
 * sophisticated (broadcasting) functions
 * basic linear algebra functions
 * basic Fourier transforms
 * sophisticated random number capabilities
 * tools for integrating Fortran code.

Besides it's obvious scientific uses, NumPy can also be used as an
efficient multi-dimensional container of generic data. Arbitrary
data-types can be defined. This allows NumPy to seamlessly and
speedily integrate with a wide-variety of databases.

Numpy 1.1.1 is a bug fix release featuring major improvements in
Python 2.3.x compatibility and masked arrays. For information,
please see the release notes:
http://sourceforge.net/project/shownotes.php?group_id=1369&release_id=617279

Thank you to everybody who contributed to this release.

Enjoy,

--

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
(Continue reading)

Permalink | Reply | 0 comments |
headers
Darren Dale | 3 Aug 03:39
Picon
Gravatar

Re: design of a physical quantities package: seeking comments

Hi Anne,

On Saturday 02 August 2008 4:23:43 pm Anne Archibald wrote:
> 2008/8/2 Darren Dale <dsdale24 <at> gmail.com>:
> > I have been thinking about how to handle physical quantities by
> > subclassing ndarray and building on some of the ideas and code from
> > Charles Doutriaux python wrappers of udunits and Enthought's units
> > package.
>
> This sounds like a very handy tool, but you want to be careful to keep
> it tractable.

I don't plan on investing a big chunk of time on this. Hopefully I can get 
something together that will be useful and extendable, so if someone wants to 
add new features at a later time, there hopefully will be a simple but 
flexible-enough foundation to do so.

> > I would like to share my current thinking, and would appreciate some
> > feedback at these early stages so I can get the basic design right.
> >
> > The proposed Quantity object would be an ndarray subclass with an
> > additional attribute and property:
> >
> > * Quantity has a private attribute, a Dimensions container, which
> > contains zero or more Dimension objects, each having associated units (a
> > string) and a power (a number). The container object would be equipped
> > with the various __add__, __sub__, __mul__, etc. Before performing the
> > operations on the ndarray values, the operation would be performed with
> > the Dimensions containers, either updating self's Dimensions and yielding
> > the conversion factors required to scale the other quantity's values to
(Continue reading)

Permalink | Reply | 10 comments |
headers
Anne Archibald | 3 Aug 09:46
Picon

Re: design of a physical quantities package: seeking comments

2008/8/2 Darren Dale <dsdale24 <at> gmail.com>:

> On Saturday 02 August 2008 4:23:43 pm Anne Archibald wrote:
>> 2008/8/2 Darren Dale <dsdale24 <at> gmail.com>:
>> I think it's a good idea to try to keep things in the units they are
>> provided in; this should reduce the occurrences of unexpected
>> overflows when (for example) cubing a distance in megaparsecs (put
>> this in centimetres and use single precision and you might overflow).
>> But this does mean you need to decide, when adding (say) a distance in
>> feet to a distance in metres, which unit the result should be in.
>
> Yes, a decision will have to be made as to whether A*B+C will yield a result
> in units of A or C. I am not worried at this point about overflows or loss of
> precision when attempting to convert a quantity that is some integer dtype.

I don't think it's worth worrying about integers. But if you take,
say, 10 megaparsecs, and express it in metres, you get 3e23 m. For the
volume of a cube 10 Mpc on a side, you get about 3e70 - a number too
big to fit in a single-precision float. So the cosmologists will be
forced to use doubles if you internally represent everything using SI
units. For the same reason, you may want to make the conversion rules
very clear. ("Always convert to the left-hand unit" would work.)

>> What about units like pc/cm^3
>> (actually in very common use in radio astronomy)? How do you preserve
>> pc/m^3 without getting abominations like kg m^2 s^2/kg m s^2?
>
> I'm not familiar with the issue here (how do you go from length/length^3 to
> length, and where did the mass and time units come from?). To begin with, I
> plan on attacking this problem the same way one would do dimensional
(Continue reading)

Permalink | Reply | 9 comments |

Gmane