numpy-discussion — Discussion list for all users of Numerical Python

[Numpy-discussion] libnumarray.h and NO_IMPORT_ARRAY

[Philip A. <pa...@eo...>]

We're currently porting several of our boost-wrapped Numeric classes
to numarray.  The routines are spread across several cpp files, and
**libnumarray_API is needed in each file.  In Numeric, we invoke
import_array() in the module file, to initialize **PyArray_API, and
def NO_IMPORT_ARRAY in the other files; this produces 
extern void **PyArray_API in those files, and everyone's happy.

Currently libnumarray.h doesn't implement this -- is there
another way to compile a multiple file project which
initializes the API just once?

Thanks, Phil Austin

Re: [Numpy-discussion] arange(-10)

[Todd M. <jm...@st...>]

Pearu Peterson wrote:

>
>On Mon, 7 Oct 2002, Todd Miller wrote:
>
>>Pearu Peterson wrote:
>>
>>>On Mon, 7 Oct 2002, Todd Miller wrote:
>>>
>>>>The subject line contains what I consider to be an invalid range
>>>>expression.   Numarray, now and always, reacts badly to it.  Currently,
>>>>numarray tries to allocate a multi-gigabyte array.   In the past, it has
>>>>dumped core.
>>>>
>>>>The question is, what should it do?
>>>>
>>>>1. raise ValueError, "Invalid negative range expression"     (my +1)
>>>>2. zeros((0,), 'l')
>>>>                 (Numeric does this)
>>>>
>>>>Is there a good justification to keep the existing Numeric behavior?
>>>>Any other suggestions?
>>>>
>>>Does Numarray support empty arrays? If yes, I'd vote for Python behavior:
>>>
>>Numarray has no problem with empty arrays so both choices are easy to
>>implement.  It apparently has a different repr (than Numeric) for
>>"nothing" which is:
>>
>>array([])
>>
>
>Hmm, so it means that Numeric.arange is consistent with Python range after
>all.  Then I'd like to change my vote from exception to array([]) (if it
>is not too late).
>
>Rationale: sometimes using
>
>  range(i1) + range(i2) + range(i3)
>
>can save lots of code if the indices i1,i2,i3 can also be negative with
>the meaning that the resulting lists are then empty. If using arange, then
>the above would be equivalent to
>
>  concatenate((arange(i1),arange(i2),arange(i3)))
>
>or
>
>  concatenate(map(arange,[i1,i2,i3]))
>
>for short. Now, if arange would raise an exception if one of i1,i2,i3 is
>negative, then the above would not work without checking i1,i2,i3 first.
>And I find that bad because additional (read: meaningless) code is
>needed.
>
>Pearu
>
>
Hi Pearu,

Well, as fate would have it, your vote was already mis-cast in favor of 
Numeric compatability.  However, you've changed my mind, so I'm changing 
*my* vote.  That leaves the current vote at +2 "raise", +3 "compatible", 
so barring any new votes,  I'll check it in as Numeric compatible 
(returning an empty range) at COB today.

Todd

-- 
Todd Miller 			jm...@st...
STSCI / SSB

Re: [Numpy-discussion] arange(-10)

[Pearu P. <pet...@ma...>]

On Mon, 7 Oct 2002, Todd Miller wrote:

> Pearu Peterson wrote:
>
> >On Mon, 7 Oct 2002, Todd Miller wrote:
> >
> >>The subject line contains what I consider to be an invalid range
> >>expression.   Numarray, now and always, reacts badly to it.  Currently,
> >>numarray tries to allocate a multi-gigabyte array.   In the past, it has
> >>dumped core.
> >>
> >>The question is, what should it do?
> >>
> >>1. raise ValueError, "Invalid negative range expression"     (my +1)
> >>2. zeros((0,), 'l')
> >>                  (Numeric does this)
> >>
> >>Is there a good justification to keep the existing Numeric behavior?
> >> Any other suggestions?
> >>
> >
> >Does Numarray support empty arrays? If yes, I'd vote for Python behavior:
> >
> Numarray has no problem with empty arrays so both choices are easy to
> implement.  It apparently has a different repr (than Numeric) for
> "nothing" which is:
>
> array([])

Hmm, so it means that Numeric.arange is consistent with Python range after
all.  Then I'd like to change my vote from exception to array([]) (if it
is not too late).

Rationale: sometimes using

  range(i1) + range(i2) + range(i3)

can save lots of code if the indices i1,i2,i3 can also be negative with
the meaning that the resulting lists are then empty. If using arange, then
the above would be equivalent to

  concatenate((arange(i1),arange(i2),arange(i3)))

or

  concatenate(map(arange,[i1,i2,i3]))

for short. Now, if arange would raise an exception if one of i1,i2,i3 is
negative, then the above would not work without checking i1,i2,i3 first.
And I find that bad because additional (read: meaningless) code is
needed.

Pearu

Re: [Numpy-discussion] bug fix for exp()

[Travis O. <oli...@ee...>]

> Hi,
>
> I've been lurking for a while, and using Numeric for about 5-6 months. I
> submitted a bug report about two months ago
> (https://sourceforge.net/tracker/index.php?func=detail&aid=594761&group_id=1369&atid=101369)
> regarding incorrect underflow behavior in exp().

My understanding is that this bug went away with a new version of Python.
It came about due to some change in Python and has not gone away.

My advice is to start using scipy (but of course that's my advice because
that's what I do).  Or at least start using scipy_base (which is easier to
install).   SciPy handles NAN's and INFS instead of raising errors and
this particular "bug" is not present because the error is not checked for.

> Another way to look into it would be if I could write some C code, then
> drop into Numeric's code and track what's going on when I call exp() for
> arguments that underflow. Is there a harness out there that I could just
> adapt to my own needs. Surely that's how other developers do it. If not,
> how *do* you fix bugs?

What's going on is that the system library for exp() is raising an
underflow error and rather than ignore it and return 0.0 like a good exp()
function, the error propagates to the top.

It's an annoying bug, I agree.

I've heard that it disappears with a new version of Python (2.2)  but, I'm
not entirely sure because I use scipy_base extensively.

-Travis O.

Re: [Numpy-discussion] int and float ufunc?

[Pearu P. <pe...@ce...>]

On Mon, 7 Oct 2002, Robert Kern wrote:

> On Mon, Oct 07, 2002 at 11:56:48AM -0700, Andrew P. Lentvorski wrote:
> > However, I have *lots* of these
> > functions scattered around the code (inherited from someone else), so I
> > will have to hunt them all down and change all the int(thingtoconvert) to
> > thingtoconvert.astype('l').
> 
> How about defining a function like so:
> 
> def int(object, **kwds):
>     if type(object) is Numeric.ArrayType:
>         return object.astype(Numeric.Integer)
>     else:
>         return __builtins__.int(object, **kwds)
> 
> That should probably take care of all uses of int() in your code.

I would rename this function to `aint' and still change all the int(x) to
aint(x).

When messing with Python built-ins, sooner or later you'll find a bullet
in your leg ...

Pearu

[Numpy-discussion] bug fix for exp()

[Frank G. <fgi...@hm...>]

Hi,

I've been lurking for a while, and using Numeric for about 5-6 months. I 
submitted a bug report about two months ago 
(https://sourceforge.net/tracker/index.php?func=detail&aid=594761&group_id=1369&atid=101369) 
regarding incorrect underflow behavior in exp().

I'd really like to get that fixed, nobody else seems to be working on it, 
and so I checked out the CVS tree. From reading the API section of the 
manual, I can see that unary ufuncs are driven by PyUFunc_FromFuncAndData() 
and that exp already has check_return set to 1, so that it should clean up 
rank-0 arrays, and raise the appropriate Python exception when 'errno' is 
set by a math error.

I'd like to take a closer look into things, and one way of doing that would 
be to use a unit-test suite, but it's not obvious where that is (if at all) 
in the source distribution. Is there one?

Another way to look into it would be if I could write some C code, then 
drop into Numeric's code and track what's going on when I call exp() for 
arguments that underflow. Is there a harness out there that I could just 
adapt to my own needs. Surely that's how other developers do it. If not, 
how *do* you fix bugs?

I've already added some features to JNumeric, and introduced a unit-test 
suite there. I have so few problems using Numeric, I'd really like to nail 
this one involving exp(), since it's holding me back.

Thanks,

-Frank Gibbons

PhD, Computational Biologist,

Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons

Re: [Numpy-discussion] int and float ufunc?

[Robert K. <ke...@ca...>]

On Mon, Oct 07, 2002 at 11:56:48AM -0700, Andrew P. Lentvorski wrote:
> However, I have *lots* of these
> functions scattered around the code (inherited from someone else), so I
> will have to hunt them all down and change all the int(thingtoconvert) to
> thingtoconvert.astype('l').

How about defining a function like so:

def int(object, **kwds):
    if type(object) is Numeric.ArrayType:
        return object.astype(Numeric.Integer)
    else:
        return __builtins__.int(object, **kwds)

That should probably take care of all uses of int() in your code.

-- 
Robert Kern
Ruddock House President
ke...@ca...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

Re: [Numpy-discussion] int and float ufunc?

[Andrew P. L. <bs...@ma...>]

On Mon, 7 Oct 2002, Travis Oliphant wrote:

> The main argument is that int() should return a Python integer type
> representation of your object.  There is no way to unambiguously return a
> Python integer object from a general array unless that array contains only
> one element.

Okay.

> I don't understand what the problem is.  Why does X.astype()  not work for
> you here?

I guess I wasn't clear here.  It does.  However, I have *lots* of these
functions scattered around the code (inherited from someone else), so I
will have to hunt them all down and change all the int(thingtoconvert) to
thingtoconvert.astype('l').

Since there are good arguments for int behaving the way it does, I'll make
the changes required to my code.  No big deal, just lots of tedium.

Thanks for taking the time to explain this,
-a

Re: [Numpy-discussion] arange(-10)

[Todd M. <jm...@st...>]

Travis Oliphant wrote:

>On Mon, 7 Oct 2002, Todd Miller wrote:
>
>>The subject line contains what I consider to be an invalid range
>>expression.   Numarray, now and always, reacts badly to it.  Currently,
>>numarray tries to allocate a multi-gigabyte array.   In the past, it has
>>dumped core.
>>
>>The question is, what should it do?
>>
>>1. raise ValueError, "Invalid negative range expression"     (my +1)
>>
>+1
>
>I didn't realize Numeric behaved badly in this area.
>
>-Travis
>
>
I replied to this earlier,  but I may have forgotten to reply-all, 
because I never saw my response.

Anyway,  I don't think Numeric has a problem with 
arange(<negative_value>), but numarray does.  The vote is currently +3 
"raise", +2 "compatible".  

All votes appreciated
Todd

Re: [Numpy-discussion] arange(-10)

[Travis O. <oli...@ee...>]

On Mon, 7 Oct 2002, Todd Miller wrote:

> The subject line contains what I consider to be an invalid range
> expression.   Numarray, now and always, reacts badly to it.  Currently,
> numarray tries to allocate a multi-gigabyte array.   In the past, it has
> dumped core.
>
> The question is, what should it do?
>
> 1. raise ValueError, "Invalid negative range expression"     (my +1)
+1

I didn't realize Numeric behaved badly in this area.

-Travis

Re: [Numpy-discussion] arange(-10)

[Todd M. <jm...@st...>]

Pearu Peterson wrote:

>On Mon, 7 Oct 2002, Todd Miller wrote:
>
>>The subject line contains what I consider to be an invalid range 
>>expression.   Numarray, now and always, reacts badly to it.  Currently, 
>>numarray tries to allocate a multi-gigabyte array.   In the past, it has 
>>dumped core.
>>
>>The question is, what should it do?
>>
>>1. raise ValueError, "Invalid negative range expression"     (my +1)
>>2. zeros((0,), 'l')                                                     
>>                  (Numeric does this)
>>
>>Is there a good justification to keep the existing Numeric behavior? 
>> Any other suggestions?
>>
>
>Does Numarray support empty arrays? If yes, I'd vote for Python behavior:
>
Numarray has no problem with empty arrays so both choices are easy to 
implement.  It apparently has a different repr (than Numeric) for 
"nothing" which is:

array([])

Currently the tally is +2 exception, +1 Numeric-compatible.  I'll 
probably just implement it at COB today, before I forget.

Thanks for voting
Todd

Re: [Numpy-discussion] int and float ufunc?

[Travis O. <oli...@ee...>]

On Mon, 7 Oct 2002, Andrew P. Lentvorski wrote:

> On Mon, 7 Oct 2002, Travis Oliphant wrote:
>
> > > Could someone explain the reason why int() and float() don't work as
> > > ufuncs?  Is it just that someone needs to write the code, or is there some
> > > subtlety at work that I am missing?
> >
> > What would you have them do?  Their current definition works for returning
> > suitable arrays as integers and floats respectively, just as the Python
> > documentation says these two functions should.
>
> Okay, now I'm really confused ...
>
> >>> import Numeric
> >>> a = Numeric.array([1.5, 2.5, 3.5], Numeric.Float64)
> >>> a
> array([ 1.5,  2.5,  3.5])
> >>> int(a)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: Only rank-0 arrays can be converted to Python scalars.
>

I didn't mean to confuse you.  I said "suitable" arrays.  Returning a
single Python integer from an array doesn't really make sense unless that
array is 0-dimensional (rank-0).  Now, one could argue that an array of
length 1 could also be converted unambiguously, but that discussion has
never taken place.

Python uses the int() function to return a Python integer type whenever it
is explicitly needed.

> I could be persuaded either way.  I was simply wondering what the
> arguments were.
>

The main argument is that int() should return a Python integer type
representation of your object.  There is no way to unambiguously return a
Python integer object from a general array unless that array contains only
one element.  Currently the int() function only converts rank-0 arrays
(which are Numeric scalars with array headers).

> My usage is in converting vectors of data before passing them to the
> screen for display.  The conversion function is a bunch of ufuncs and then
> the resulting vector needs to get converted to int before being passed to
> X.  The same code works for Python floats, scalars, or Numeric arrays with
> the exception of the int function.
>

I don't understand what the problem is.  Why does X.astype()  not work for
you here?  What do you mean "passed to X?"  Is this in C, in Python?  The
int() function was never intended to work on general Numeric arrays.  It
could be made to (and would be a very simple job), but that discussion has
never taken place.

instead of int() why don't you use

asarray(x).astype('l')  for your code


> If the problem was simply a lack of someone to write the code, I thought I
> might do it.  I thought it might be a little faster than me writing array
> versions of all of my conversion functions, although I haven't looked at
> the complexity of the Numeric code.  So, I could be completely wrong about
> that.

If you look in SciPy (www.scipy.org), we have defined a dictionary of cast
functions for each of the types that works the way you apparently wanted
int() to work.

Using this command you would write

scipy.cast[Numeric.Int](<your object>)


I don't know what your functions are, but I doubt array versions would be
that difficult to write.  I guess I just always write array versions of my
functions.  Almost every routine I write starts with
asarray(x)

to convert inputs to array objects

Good luck,

-Travis O.

Re: [Numpy-discussion] int and float ufunc?

[Pearu P. <pe...@ce...>]

On Mon, 7 Oct 2002, Andrew P. Lentvorski wrote:

> On Mon, 7 Oct 2002, Travis Oliphant wrote:
> 
> > What would you have them do?  Their current definition works for returning
> > suitable arrays as integers and floats respectively, just as the Python

    ^^^^^^^^^^^^^^^

> > documentation says these two functions should.
> 
> Okay, now I'm really confused ...
> 
> >>> import Numeric
> >>> a = Numeric.array([1.5, 2.5, 3.5], Numeric.Float64)
> >>> a
> array([ 1.5,  2.5,  3.5])
> >>> int(a)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: Only rank-0 arrays can be converted to Python scalars.

                  ^^^^^^^^^^^^^

> I guess I'm really dense, but how does that result constitute a definition
> that "works"?

See ^^^ above. In this case, suitable arrays are rank-0 arrays. So, the
definition works (see also below).

> > It would be an easy thing to map int() to oldarray.astype(Int) and so
> > forth but is this a good policy.  I submit it is not.
> 
> I could be persuaded either way.  I was simply wondering what the
> arguments were.

According to int.__doc__, int(..) should *always* return a Python
integer. But you are asking for an integer array as a result of 
int(array(..)); and that would be a contradiction with the Python
definition for int(anyobj).

Pearu

Re: [Numpy-discussion] arange(-10)

[Pearu P. <pe...@ce...>]

On Mon, 7 Oct 2002, Todd Miller wrote:

> The subject line contains what I consider to be an invalid range 
> expression.   Numarray, now and always, reacts badly to it.  Currently, 
> numarray tries to allocate a multi-gigabyte array.   In the past, it has 
> dumped core.
> 
> The question is, what should it do?
> 
> 1. raise ValueError, "Invalid negative range expression"     (my +1)
> 2. zeros((0,), 'l')                                                     
>                   (Numeric does this)
> 
> Is there a good justification to keep the existing Numeric behavior? 
>  Any other suggestions?

Does Numarray support empty arrays? If yes, I'd vote for Python behavior:

>>> range(-10)
[]

Otherwise, the case 1.

Hmm, according to Numeric.arange docs, "arange is just like
range() except it returns an array whose type can be specified ...".
But given example shows that there are other (undocumented?) exceptions
when comparing arange and range.

Pearu

[Numpy-discussion] arange(-10)

[Todd M. <jm...@st...>]

The subject line contains what I consider to be an invalid range 
expression.   Numarray, now and always, reacts badly to it.  Currently, 
numarray tries to allocate a multi-gigabyte array.   In the past, it has 
dumped core.

The question is, what should it do?

1. raise ValueError, "Invalid negative range expression"     (my +1)
2. zeros((0,), 'l')                                                     
                  (Numeric does this)

Is there a good justification to keep the existing Numeric behavior? 
 Any other suggestions?

Todd

Re: [Numpy-discussion] int and float ufunc?

[Andrew P. L. <bs...@ma...>]

On Mon, 7 Oct 2002, Travis Oliphant wrote:

> > Could someone explain the reason why int() and float() don't work as
> > ufuncs?  Is it just that someone needs to write the code, or is there some
> > subtlety at work that I am missing?
>
> What would you have them do?  Their current definition works for returning
> suitable arrays as integers and floats respectively, just as the Python
> documentation says these two functions should.

Okay, now I'm really confused ...

>>> import Numeric
>>> a = Numeric.array([1.5, 2.5, 3.5], Numeric.Float64)
>>> a
array([ 1.5,  2.5,  3.5])
>>> int(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: Only rank-0 arrays can be converted to Python scalars.

I guess I'm really dense, but how does that result constitute a definition
that "works"?  Has this behavior changed recently such that I should
update my version of Numeric?  If so, that would be a wonderful solution
to my problem (explained below).

> It would be an easy thing to map int() to oldarray.astype(Int) and so
> forth but is this a good policy.  I submit it is not.

I could be persuaded either way.  I was simply wondering what the
arguments were.

My usage is in converting vectors of data before passing them to the
screen for display.  The conversion function is a bunch of ufuncs and then
the resulting vector needs to get converted to int before being passed to
X.  The same code works for Python floats, scalars, or Numeric arrays with
the exception of the int function.

If the problem was simply a lack of someone to write the code, I thought I
might do it.  I thought it might be a little faster than me writing array
versions of all of my conversion functions, although I haven't looked at
the complexity of the Numeric code.  So, I could be completely wrong about
that.

If the traceback is "designed" behavior, I guess I'll just have to suck it
up and write array versions of my functions.

Thanks,
-a

Re: [Numpy-discussion] int and float ufunc?

[Travis O. <oli...@ee...>]

> Could someone explain the reason why int() and float() don't work as
> ufuncs?  Is it just that someone needs to write the code, or is there some
> subtlety at work that I am missing?

What would you have them do?  Their current definition works for returning
suitable arrays as integers and floats respectively, just as the Python
documentation says these two functions should.

It would be an easy thing to map int() to oldarray.astype(Int) and so
forth but is this a good policy.  I submit it is not.

-Travis O.

[Numpy-discussion] int and float ufunc?

[Andrew P. L. <bs...@ma...>]

Could someone explain the reason why int() and float() don't work as
ufuncs?  Is it just that someone needs to write the code, or is there some
subtlety at work that I am missing?

It took a bit of digging to go find the fact that what I wanted is
newarray = oldarray.astype(MagicNewTypeCode)

Thanks,
-a

Re: [Numpy-discussion] numarray via CVS

[Todd M. <jm...@st...>]

  Nils Wagner wrote:


>Hi,
>
>I tried to install numarray via latest CVS. However 
>python setup.py install failed 
>
>This is the output
>
>Src/_ndarraymodule.c:240: warning: `_ndarray_bytestride_set' defined but
>not use                         d
>Src/_ndarraymodule.c:260: warning: `_ndarray_byteoffset_get' defined but
>not use                         d
>Src/_ndarraymodule.c:266: warning: `_ndarray_byteoffset_set' defined but
>not use                         d
>Src/_ndarraymodule.c:288: warning: `_ndarray_aligned_get' defined but
>not used
>Src/_ndarraymodule.c:294: warning: `_ndarray_aligned_set' defined but
>not used
>Src/_ndarraymodule.c:323: warning: `_ndarray_contiguous_get' defined but
>not use                         d
>Src/_ndarraymodule.c:329: warning: `_ndarray_contiguous_set' defined but
>not use                         d
>error: command 'gcc' failed with exit status 1
>
>
>Any suggestion ?
>
>Nils
>
>Nils
>


I'm in the process of merging some new C basetypes into the head of CVS 
so I guess the HEAD has to be considered unstable for the next few days. 
  I work hard to keep the CVS in working order,  but you've caught me in 
the middle of "something big".   For now, I have this advice:

1.  Use numarray-0.3.6 until numarray-0.4 is released.

2. When upgrading numarray, always remove the old version.

3. If you're intereseted in writing extensions, stick with numarray's 
Numeric compatability API.

Todd

-- 
Todd Miller 			jm...@st...
STSCI / SSB

[Numpy-discussion] numarray via CVS

[Nils W. <nw...@me...>]

Hi,

I tried to install numarray via latest CVS. However 
python setup.py install failed 

This is the output

Src/_ndarraymodule.c:240: warning: `_ndarray_bytestride_set' defined but
not use                         d
Src/_ndarraymodule.c:260: warning: `_ndarray_byteoffset_get' defined but
not use                         d
Src/_ndarraymodule.c:266: warning: `_ndarray_byteoffset_set' defined but
not use                         d
Src/_ndarraymodule.c:288: warning: `_ndarray_aligned_get' defined but
not used
Src/_ndarraymodule.c:294: warning: `_ndarray_aligned_set' defined but
not used
Src/_ndarraymodule.c:323: warning: `_ndarray_contiguous_get' defined but
not use                         d
Src/_ndarraymodule.c:329: warning: `_ndarray_contiguous_set' defined but
not use                         d
error: command 'gcc' failed with exit status 1


Any suggestion ?

Nils

Nils

[Numpy-discussion] calling multiarraymodule.c funcs from c api

[John H. <jdh...@ac...>]

I am new to numpy extension writing, and am trying to call some of the
functions defined in Numeric-21.3/Src/multiarraymodule.c, eg

  extern PyObject *PyArray_Correlate(PyObject *op1, PyObject *op2, int mode) 

in a Numeric extension module that I am writing.  

Are these functions available via the C API, and if so, how should I
go about accessing them?  Or are the only array functions defined in
Include/arrayobject.h available in the C API?

Below is my prototype module.  I am defining a function 'xcorr' that
just does what cross_correlate does, as a test case to see if I can
access the multiarray C API:


/* jdhscipy.c	--  Wed Oct  2 2002
 */

#include "Python.h"
#include "Numeric/arrayobject.h"
#include "stdio.h"


static PyObject *ErrorObject;
extern PyObject *PyArray_Correlate(PyObject*, PyObject*, int);

static char xcorr__doc__[] = "";

static PyObject * xcorr(PyObject *self, PyObject *args) { 
    PyObject *shape, *a0;
    int mode=0;
	
    if (!PyArg_ParseTuple(args, "OO|i", &a0, &shape, &mode)) return NULL;
	
    return PyArray_Correlate(a0, shape, mode);
}




static struct PyMethodDef jdhscipy_methods[] = {
 {"xcorr",     xcorr,          1,      xcorr__doc__},
 {NULL,		NULL}		/* sentinel */
};

/* Initialization function for the module (*must* be called initjdhscipy) */

static char jdhscipy_module_documentation[] = 
"My first scipy extension"
;

DL_EXPORT(void) initjdhscipy(void)
{
	PyObject *m, *d;

	/* Create the module and add the functions */
	m = Py_InitModule4("jdhscipy", jdhscipy_methods,
		jdhscipy_module_documentation,
		(PyObject*)NULL,PYTHON_API_VERSION);

	/* Import the array object */
	import_array();
	
	/* Add some symbolic constants to the module */
	d = PyModule_GetDict(m);
	ErrorObject = PyString_FromString("jdhscipy.error");
	PyDict_SetItemString(d, "error", ErrorObject);

	/* XXXX Add constants here */
	
	/* Check for errors */
	if (PyErr_Occurred())
		Py_FatalError("can't initialize module jdhscipy");
}

[Numpy-discussion] P: tofile & fromfile

[Zaur S. <sz...@fr...>]

I propose to add two function to multiarray module in Numeric:

tofile(array, openedfile)
array = fromfile(opendfile, dimension, typecode = "l")

Now I use these functions in my module.
Here is an implementation from module:

###############################################################################3

#include "Python.h"
#define PY_ARRAY_UNIQUE_SYMBOL PyArray_arrayfile
#include "Numeric/arrayobject.h"

#define MAX_DIMS 40

static PyObject *
PyArray_FromFile(PyObject *self, PyObject *args)
{
    PyObject *f, *dimobj, *temp;
    PyArray_Descr *descr;
    PyArrayObject *ret = NULL;
    int i, n, dim[40], nt;
    char *typecode = "l";
    FILE *fp;
    int type_num, N = 1;
    size_t nread;

    if (!PyArg_ParseTuple(args, "O!O!|s#:fromfile", \
                          &PyFile_Type, &f, &PyTuple_Type, &dimobj, &typecode, &nt))
        return NULL;

    fp = PyFile_AsFile(f);
    if (fp == NULL) {
        PyErr_SetString(PyExc_TypeError, "1st argument must be open file");
        return NULL;
    }
    n = PyTuple_Size(dimobj);
    if (n > MAX_DIMS) {
        PyErr_SetString(PyExc_TypeError, "dimension is too large");
        return NULL;
    }
    if (n > 0) {
        for (i = 0; i < n; i++) {
            temp = PyTuple_GetItem(dimobj, i);
            dim[i] = (int)PyInt_AsLong(temp);
        }
        
        descr = PyArray_DescrFromType(*typecode);
        type_num = descr -> type_num;
        
        ret = (PyArrayObject *)PyArray_FromDims(n, dim, type_num);
        memcpy(ret->data, descr->zero, N*descr->elsize);
        
        N = 1;
        for (i = 0; i < n; i++) N *= dim[i];
        nread = fread((char *)ret->data, descr->elsize, N, fp);
        if (nread < (size_t)N) {
            PyErr_SetString(PyExc_EOFError, "not enough items in file");
            return NULL;
        }
    }

    return (PyObject *)ret;
}

static char PyArray_FromFile_doc [] =
"fromfile(f, dimension, typecode = \'l\')\n\
\n\
Create array from open file f with given dimension and typecode.\n\
Note, that file must be open in binary mode.";


static PyObject *
PyArray_ToFile(PyObject *self, PyObject *args)
{
    PyObject *f;
    PyArrayObject *A;
    int N;
    FILE *fp;
        
    if (!PyArg_ParseTuple(args, "O!O!:tofile", &PyArray_Type, &A, &PyFile_Type, &f))
        return NULL;
    
    fp = PyFile_AsFile(f);
    if (fp == NULL) {
        PyErr_SetString(PyExc_TypeError, "arg must be open file");
        return NULL;
    }
    
    N = PyArray_SIZE(A);
    if (N > 0) {
        if (fwrite(A->data, A->descr->elsize, N, fp) != (size_t)N) {
            PyErr_SetFromErrno(PyExc_IOError);
            clearerr(fp);
            return NULL;
        }
    }
    Py_INCREF(Py_None);
    return Py_None;
}

static char PyArray_ToFile_doc [] =
"tofile(array, f)\n\
\n\
Write array to file open f.\n\
Note, that file must be open in binary mode.";


static PyMethodDef arrayfile_module_methods[] = {
         {"fromfile",  PyArray_FromFile, 1, PyArray_FromFile_doc},
         {"tofile",    PyArray_ToFile,   1, PyArray_ToFile_doc},
         {NULL,                 NULL}  /* sentinel */
};

############################################################################

Zaur Shibzoukhov

[Numpy-discussion] (no subject)

[Leonardo S. <re...@te...>]

confirm 498554

[Numpy-discussion] Casting. Method to the madness?

[Mathew Y. <ma...@co...>]

Hmmm, aparently, I can cast a long array to a double array but not
to a float array.

Check out the following code from arrayobject.c (Numeric 22.0)
[this is a switch on the type being casted from]

case PyArray_LONG:
    /*Shouldn't allow Longs to be cast to Ints, not safe on 64-bit 
machines!*/
    return (totype >= PyArray_INT) && (totype != PyArray_FLOAT);

This makes absolutely no sense to me. Is this a bug?

Mathew

-- 
M47h3w `/34735

[Numpy-discussion] Cast problems .... doo dah, doo dah

[Mathew Y. <ma...@co...>]

The following code produces an error
---------------------------------------
a=array(([1,2,3,4,5],[10,9,8,7,6])).astype(Float32)
cond=array(([0,0,0,0,0],[1,1,1,1,1])
b=array(([0,0,0,0,0],[0,0,0,0,0]))

choose(cond,(a,b))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: Array can not be safely cast to required type
------------------------------

I suppose I might need to cast b to Float32. But, I have a function 
which is passed a and b
as args. Ideally, I would like a function which casts a and b to the 
highest compatible type since
"choose" doesnt do it. How can I do this simply?

Mathew

-- 
M47h3w `/34735