headers
Joe Van Andel | 2 Feb 2000 19:35
Picon

single precision routines in NumPy?

I would like a single precision version of 'interp' in the Numeric
Core.   (I want such a routine since I'm operating on huge single
precision arrays, that I don't want promoted to double precision.)

I've written such a routine, but Paul Dubois and I are discussing the
best way of integrating it into the core.

One solution is to simply add a new function 'interpf' to
arrayfnsmodule.c .  

Another solution is to add a typecode=Float option to interp.

Any opinions on how this single precision version be handled?

--

-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel <at> ucar.edu
Permalink | Reply | 0 comments |
headers
Tom Adelman | 3 Feb 2000 22:57
Picon

newbie: PyArray_Check difficulties

I'm having a problem with PyArray_Check.  If I just call
PyArray_Check(args) I don't have a problem, but if I try to assign the
result to anything, etc., it crashes (due to acces violation).  So, for
example the code at the end of this note doesn't work, yet I know an array
is being passed and I can, for example, calculate its trace correctly if I
type cast it as a PyArrayObject*.

Also, a more general question: is this the recommended way to input numpy
arrays when using swig, or do most people find it easier to use more
elaborate typemaps, or something else?

Finally, I apologize if this is the wrong forum to post this question.
Please let me know.

Thanks, Tom 

Method from C++ class:

PyObject * Test01::trace(PyObject * args)
{
	if (!(PyArray_Check(args))) {  // <- crashes here
		PyErr_SetString(PyExc_ValueError, "must use NumPy array");
		return NULL;
	}
	return NULL;
}

Swig file: (where typemaps are the ones included with most recent swig)

/* TMatrix.i */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Travis Oliphant | 4 Feb 2000 21:49
Favicon

Re: Numpy-discussion digest, Vol 1 #7 - 1 msg

> I'm having a problem with PyArray_Check.  If I just call
> PyArray_Check(args) I don't have a problem, but if I try to assign the
> result to anything, etc., it crashes (due to acces violation).  So, for
> example the code at the end of this note doesn't work, yet I know an array
> is being passed and I can, for example, calculate its trace correctly if I
> type cast it as a PyArrayObject*.
> 
> Also, a more general question: is this the recommended way to input numpy
> arrays when using swig, or do most people find it easier to use more
> elaborate typemaps, or something else?

I have some experience with SWIG but it is not my favorite method to use
Numerical Python with C, since you have so little control over how things
get allocated.

Your problem is probably due to the fact that you do not run
import_array() in the module header.  

There is a typemap in SWIG that let's you put commands to run at module
initialization.   Try this in your *.i file.

%init %{
        import_array();
%}

This may help.

Best,

Travis
(Continue reading)

Permalink | Reply | 0 comments |
headers
Travis Oliphant | 8 Feb 2000 01:08
Favicon

An Experiment in code-cleanup.

I wanted to let users of the community know (so they can help if they
want, or offer criticism or comments) that over the next several
months I will be experimenting with a branch of the main Numerical source
tree and endeavoring to "clean-up" the code for Numerical Python.  I have
in mind a few (in my opinion minor) alterations to the current code-base
which necessitates a branch. 

Guido has made some good suggestions for improving the code base, and both
David Ascher and Paul Dubois have expressed concerns over the current
state of the source code and given suggestions as to how to improve it.  
That said, I should emphasize that my work is not authorized,
or endorsed, by any of the people mentioned above.  It is simply my little
experiment.

My intent is not to re-create Numerical Python --- I like most of the
current functionality --- but to merely, clean-up the code, comment it, 
and change the underlying structure just a bit and add some features I
want.  One goal I have is to create something that can go into Python
1.7 at some future point, so this incarnation of Numerical Python may not
be completely C-source compatible with current Numerical Python (but it
will be close).  This means C-extensions that access the underlying
structure of the current arrayobject may need some alterations to use this
experimental branch if it every becomes useful.

I don't know how long this will take me.  I'm not promising anything.  The
purpose of this announcement is just to invite interested parties into the
discussion.   

These are the (somewhat negotiable) directions I will be pursuing.
(Continue reading)

Permalink | Reply | 26 comments |
headers
Paul F. Dubois | 8 Feb 2000 01:22

RE: [Matrix-SIG] An Experiment in code-cleanup.

Travis says that I don't necessarily endorse his goals but in fact I do,
strongly.

If I understand right he intends to make a CVS branch for this experiment
and that is fine with me.

The only goal I didn't quite understand was:

Addition of attributes so that different users can configure aspects of
the math behavior, to their hearts content.

In a world of reusable components the situation is complicated. I would not
like to support a dot-product routine, for example, if the user could turn
off any double precision behind my back. My needs for precision are local to
my algorithm.
Permalink | Reply | 0 comments |
headers
John Travers | 8 Feb 2000 16:52

Re: A proposal for dot product

This message was sent from Geocrawler.com by "John Travers" <j.c.travers <at> durham.ac.uk>
Be sure to reply to that address.

If the above was implemented, I would be very happy indeed. As a maths student, I use NumPy 
a lot. And get infuriated with the current implementation.

John.

Geocrawler.com - The Knowledge Archive
Permalink | Reply | 0 comments |
headers
Konrad Hinsen | 8 Feb 2000 18:12
Picon
Favicon

Re: [Matrix-SIG] An Experiment in code-cleanup.

> 3) Facility for memory-mapped dataspace in arrays.

I'd really like to have that...

> 4) Slices become copies with the addition of methods for current strict
> referencing behavior.

This will break a lot of code, and in a way that will be difficult to
debug. In fact, this is the only point you mention which would be
reason enough for me not to use your modified version; going through
all of my code to check what effect this might have sounds like a
nightmare.

I see the point of having a copying version as well, but why not
implement the copying behaviour as methods and leave indexing as it
is?

> 5) Handling of sliceobjects which consist of sequences of indices (so that
> setting and getting elements of arrays using their index is possible). 

Sounds good as well...

> 6) Rank-0 arrays will not be autoconverted to Python scalars, but will
> still behave as Python scalars whenever Python allows general scalar-like
> objects in it's operations.  Methods will allow the
> user-controlled conversion to the Python scalars.  

I suspect that full behaviour-compatibility with scalars is
impossible, but I am willing to be proven wrong. For example, Python
scalars are immutable, arrays aren't. This also means that rank-0
(Continue reading)

Permalink | Reply | 11 comments |
headers
hinsen | 8 Feb 2000 18:13
Picon

Re: [Matrix-SIG] An Experiment in code-cleanup.

> 3) Facility for memory-mapped dataspace in arrays.

I'd really like to have that...

> 4) Slices become copies with the addition of methods for current strict
> referencing behavior.

This will break a lot of code, and in a way that will be difficult to
debug. In fact, this is the only point you mention which would be
reason enough for me not to use your modified version; going through
all of my code to check what effect this might have sounds like a
nightmare.

I see the point of having a copying version as well, but why not
implement the copying behaviour as methods and leave indexing as it
is?

> 5) Handling of sliceobjects which consist of sequences of indices (so that
> setting and getting elements of arrays using their index is possible). 

Sounds good as well...

> 6) Rank-0 arrays will not be autoconverted to Python scalars, but will
> still behave as Python scalars whenever Python allows general scalar-like
> objects in it's operations.  Methods will allow the
> user-controlled conversion to the Python scalars.  

I suspect that full behaviour-compatibility with scalars is
impossible, but I am willing to be proven wrong. For example, Python
scalars are immutable, arrays aren't. This also means that rank-0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Travis Oliphant | 8 Feb 2000 18:38
Favicon

Re: [Matrix-SIG] An Experiment in code-cleanup.

> > 3) Facility for memory-mapped dataspace in arrays.
> 
> I'd really like to have that...

This is pretty easy to add but it does require some changes to the
underlying structure, So you can expect it.
> 
> > 4) Slices become copies with the addition of methods for current strict
> > referencing behavior.
> 
> This will break a lot of code, and in a way that will be difficult to
> debug. In fact, this is the only point you mention which would be
> reason enough for me not to use your modified version; going through
> all of my code to check what effect this might have sounds like a
> nightmare.

I know this will be a sticky point.  I'm not sure what to do exactly, but
the current behavior and implementation makes the semantics for slicing an
array using a sequence problematic since I don't see a way to represent a
reference to a sequence of indices in the underlying structure of an
array. So such slices would have to be copies and not references, which
makes for an inconsistent code.  

> 
> I see the point of having a copying version as well, but why not
> implement the copying behaviour as methods and leave indexing as it
> is?

I want to agree with you, but I think we may need to change the behavior
eventually so when is it going to happen?
(Continue reading)

Permalink | Reply | 10 comments |
headers
Paul F. Dubois | 8 Feb 2000 18:56
Picon

RE: precision isn't just precision

Before we all rattle on too long about precision, I'd like to point out that
selecting a precision actually carries two consequences in the context of
computer languages:

1. Expected: The number of digits of accuracy in the representation of a
floating point number.
2. Unexpected: The range of numbers that can be represented by this type.

Thus, to a scientist it is perfectly logical that if d is a double and f is
a single,

d * f

has only single precision validity.

Unfortunately in a computer if you hold this answer in a single, then it may
fail if the contents of d include numbers outside the single range, even if
f is 1.0.

Thus the rules in C and Fortran that coercion is UP had to do as much with
range as precision.
Permalink | Reply | 0 comments |

Gmane