headers
Edward C. Jones | 2 Jan 2003 06:02
Picon

numarray types and PIL modes, revisited

Perry Greenfield wrote:
 > Edward Jones writes:

 > > I write code using both PIL and numarray. PIL uses strings for
 > > modes and numarray uses (optionally) strings as typecodes. This
 > > causes problems.  One fix is to emit a DeprecationWarning when
 > > string typecodes are used.  Two functions are needed:
 > > StringTypeWarningOn and StringTypeWarningOff.  The default
 > > should be to ignore this warning.
 >
 > I'm not sure I understand. Can you give me an example of problem
 > code or usage? It sounds like you are trying to test the types of
 > PIL and numarray objects in a generic sense. But I'd understand
 > better if you could show an example.

That's what I was thinking (incorrectly). But I don't need to directly 
compare PIL modes with numarray types.

My code never tries to deduce whether an array is a numarray or a PIL 
image from just the natype_or_mode. A module name (MODULE.NUMARRY, 
MODULE.PIL) must also be given. I do things this way because I might 
want to include other array/image systems. In an earlier version, I had 
a MODULE.IPL for the Intel Image Processing Library.

The code also implements a policy of forbidding string types.

So now all I can say is:

1. UInt8 == 'X' should not raise an exception. It should return False.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Edward C. Jones | 2 Jan 2003 06:16
Picon

End of Holidays small comments

node35.html:

     >>> print x.type(), x.real.type()
     D d

should be

     >>> print x.type(), x.real.type()
     numarray type: Complex64 numarray type: Float64

------------------------------------------------

Why use both NUM_C_ARRAY and C_ARRAY?

------------------------------------------------

in  _ndarraymodule.c:

         {"_byteoffset",
          (getter)_ndarray_byteoffset_get,
          (setter)_ndarray_byteoffset_set,
          "shortest seperation between elements in bytes"},
         {"_bytestride",
          (getter)_ndarray_bytestride_get,
          (setter)_ndarray_bytestride_set,
          "shortest seperation between elements in bytes"},

One of the comments is wrong. Also "separation".

------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Edward C. Jones | 2 Jan 2003 06:18
Picon

Slicing API?

Both in Numeric and now in numarray I have found a need for API 
functions for slicing. Has anyone thought about this?
Permalink | Reply | 1 comment |
headers
Todd Miller | 2 Jan 2003 15:09

Re: Slicing API?

Edward C. Jones wrote:

> Both in Numeric and now in numarray I have found a need for API 
> functions for slicing. Has anyone thought about this?
>
Speaking for myself and the numarray C-API, the answer is no.   What API 
do you want?   Can you suggest function prototypes?

Todd
Permalink | Reply | 0 comments |
headers
Todd Miller | 2 Jan 2003 21:42

Re: Slicing API?

Edward C. Jones wrote:

> Todd Miller wrote:
>
>> Edward C. Jones wrote:
>>
>>> Both in Numeric and now in numarray I have found a need for API 
>>> functions for slicing. Has anyone thought about this?
>>>
>> Speaking for myself and the numarray C-API, the answer is no.   What 
>> API do you want?   Can you suggest function prototypes? 
>
>
> An API version of  arrout[slices] = arrin[slices]:
>
> static int
> NA_CopySlice(PyArrayObject* arrin, PyArrayObject* arrout,
>     int* startin, int* stepin, int* stopin, int* startout, int* stepout);
>
>
I would suggest something more like the following then:

typedef struct {
    int start, stop, step;
} NumSlice;

static int
NA_CopySlice(PyArrayObject* arrin, int indim, NumSlice *slicein,
    PyArrayObject* arrout,  int outdim, NumSlice *sliceout);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Miller | 3 Jan 2003 18:56

Re: End of Holidays small comments

Wow!   This is great feedback.  Thanks Edward.

Edward C. Jones wrote:

> node35.html:
>
>     >>> print x.type(), x.real.type()
>     D d
>
> should be
>
>     >>> print x.type(), x.real.type()
>     numarray type: Complex64 numarray type: Float64

I taked this over with Perry,  and think it should behave and be 
documented more like:
 >>> print x.type(), x.real.type()
Complex64  Float64

>
> ------------------------------------------------
>
> Why use both NUM_C_ARRAY and C_ARRAY?

In the context of the defining enumeration,  NUM_C_ARRAY looks correct. 
  Anywhere else,  C_ARRAY is about all I can stand.   C_ARRAY is so 
common that I thought a little irregularity would be tolerable.  Chock 
it up to tastelessness.

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Miller | 3 Jan 2003 18:59

Re: numarray types and PIL modes, revisited

Edward C. Jones wrote:

> So now all I can say is:
>
> 1. UInt8 == 'X' should not raise an exception. It should return False.

OK.   I'll change numarray to return False.

>
> 3. There needs to be a function that returns True iff arg is a numarry 
> type (UInt8, "UInt8", "b", ...).
>
> def IsType(rep):
>     from numerictypes import typeDict
>     return isinstance(rep, NumericType) or typeDict.has_key(rep)

Sounds good too.  I'll add this to numerictypes.

>
>
Thanks,
Todd
Permalink | Reply | 0 comments |
headers
Edward C. Jones | 4 Jan 2003 01:37
Picon

Grepping the source

Here is a short program I find useful.

#! /usr/bin/env python

import os, sys, tempfile

"""Greps the numarray source code"""

command = \
"""grep -n "%s" \
   /usr/local/src/numarray-0.4/Include/numarray/arrayobject.h \
    ...
   /usr/local/src/numarray-0.4/Lib/_ufunc.py \
   ...
   /usr/local/src/numarray-0.4/Src/libnumarraymodule.c \
 > %s
"""

if len(sys.argv) != 2:
     raise Exception, 'program requires exactly one argument'

temp = tempfile.mktemp()
try:
     os.system(command % (sys.argv[1], temp))
     f = file(temp, 'r')
     lines = f.read().splitlines()
     f.close()
finally:
     if os.path.exists(temp):
         os.remove(temp)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Magnus Lie Hetland | 4 Jan 2003 01:23

Re: Grepping the source

Edward C. Jones <edcjones <at> erols.com>:
[snip]
>     lines = f.read().splitlines()

You could use f.readlines() here... Or you could just use

  for line in open(...):

later, if you're using Python 2.2+

--

-- 
Magnus Lie Hetland
http://hetland.org
Permalink | Reply | 0 comments |
headers
Perry Greenfield | 7 Jan 2003 01:29

package vs module

Back in December the issue of whether numarray should be a package
or set of modules came up. When I asked about the possibility
of making numarray a package (on the scipy mailing list but I
can't seem to find the thread where it was discussed), I got
only positive comments. The issue needs to be raised here also.

Is there any objection to making numarray package based?
The implications are that 3rd party modules (e.g. FFT)
will be imported as part of the package structure, i.e.,

  import numarray.FFT 

or

  from numarray.FFT import *

instead of 

  import FFT

As usual there are advantages and disadvantages. The advantages
are that we will not have name collisions with existing Numeric
modules (currently we name FFT as FFT2 for this reason). It also
potentially reduces name collision issues in general. Most feel
it is a cleaner way to organize the software (at least based on
the feedback so far).

The main disadvantages I see so far are:

1) One will either have to change import statements in old code
(Continue reading)

Permalink | Reply | 6 comments |

Gmane