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

Re: [Numpy-discussion] How fast are small arrays currently?

[David M. C. <co...@ph...>]

On Tue, Jan 20, 2004 at 02:42:03PM -0500, Edward C. Jones wrote:
> Has anyone recently benchmarked the speed of numarray vs. Numeric?

Just what I was doing :-)

Check out http://arbutus.mcmaster.ca/dmc/numpy/ for a graph comparing
the two.

Basically, I get on my machine (a 1.3 GHz Athlon running Linux), for an
array of size N (of Float), the time to do a+a is

Numeric:  3.7940e-6 + 2.2556e-8 * N seconds
numarray: 3.7062e-5 + 5.8497e-9 * N

For sin(a), 
Numeric:  1.7824e-6 + 1.1341e-7 * N
numarray: 2.8994e-5 + 9.8985e-8 * N

So the slowness of numarray vs. Numeric for small arrays is because of
an overhead of 3.7e-5 s for numarray, as opposed to 3.8e-6 s for
Numeric. Otherwise, numarray is 4 times faster for large arrays
for addition (and multiplication, which I've also checked).

The crossover is at arrays of about 2000 elements.

If this overhead could be reduced by a factor of 3 or 4, I'd be much
happier with using numarray for small arrays. But for now, it's not
good enough.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] Status of Numeric

[Francesc A. <fa...@op...>]

A Dimarts 20 Gener 2004 20:11, Chris Barker va escriure:
> > As this has become an important path to
> > success of several projects (both commercial and open) it is absolutely
> > necessary that this issues be addressed.
>
>  From the sammll list above, it looks like what you need is an array
> that is like a Numarray, but faster for samll arrays...Has anyone done
> an analysis of whether it would be harder to optimize Numarray than to
> make the above changes to Numeric, and continue to maintain two
> packages? You probably have, but I though I'd ask anyway...

I agree. An analysis should be done in order to see if it is better to
concentrate in getting numarray better for small arrays or in having several
array implementations. The problem is if numarray cannot be enhanced enough
because of design problems, although I would bet that something can be done
in order to get it close to Numeric performance. And I guess quite a bit
people on this list would be happy to collaborate in some way or another so
as to achieve this goal.

However, as Perry says, in order to do this analysis, an amount of the
needed speed-up should be estimated first.

I personaly feel that it would worth the effort to go and try to optimize
the small arrays case in numarray instead of having to fight against a
jungle of Numeric/numarray/python array implementations. I strongly believe
that numarray has enough advantages over Numeric that would compensate the
effort to further enhance its present limitations rather than maintain
several packages.

Just my 2 cents,

-- 
Francesc Alted

[Numpy-discussion] How fast are small arrays currently?

[Edward C. J. <edc...@er...>]

Has anyone recently benchmarked the speed of numarray vs. Numeric?

Why are numarrays so slow to create?

Re: [Numpy-discussion] Status of Numeric

[Chris B. <Chr...@no...>]

Konrad Hinsen wrote:
>   My view is that any
> package that is upwards-compatible with Numeric (except for bug fixes 
> of course) should be called Numeric and distributed as such. Any 
> package that is intentionally incompatible with Numeric in some 
> important aspect should not be called Numeric.

I absolutely agree with this.

Travis Oliphant wrote:

 > 1) change the coercion model to reflect Numarray's choice and eliminate
 > the savespace crutch.
 > 2) Add indexing capability to Numeric arrays (similar to Numarray's)
 > 3) Improve the interaction between Numeric arrays and scalars.

These all look like backward in-compatable changes, so in that case, I 
vote for Sci-py-array, or whatever.

However, it also looks like these are all moving toward the Numarray 
API. Is this the case? That would be great, as then Numarray would just 
be dropped in if/when it is deemed up to the task. It also leaves the 
door open for some sort of automagic selection of which array to use for 
a given instance.

 > 4) Optimization:

Nothing wrong with that...as long as it's not premature!

> Numarray is making great progress and is quite usable for many 
> purposes.  An idea that was championed by some is that the Numeric code 
> base would stay static and be replaced entirely by Numarray.

> However, Numeric is currently used in a large installed base.  In 
> particular SciPy uses Numeric as its core array.  While no doubt 
> numarray arrays will be supported in the future, the speed of the less 
> bulky Numeric arrays and the typical case that we encounter in SciPy of 
> many, small arrays will make it difficult for people to abandon Numeric 
> entirely with it's comparatively light-weight arrays.

It was said that making Numarray more efficient with small arrays was a 
goal of the project...is it still? I'm still unclear on why Numarrays 
are so much more "heavy"..is it just that no one has taken the time to 
optimize them, or is there really something inherent (and important) in 
the design?

> As this has become an important path to 
> success of several projects (both commercial and open) it is absolutely 
> necessary that this issues be addressed.

 From the sammll list above, it looks like what you need is an array 
that is like a Numarray, but faster for samll arrays...Has anyone done 
an analysis of whether it would be harder to optimize Numarray than to 
make the above changes to Numeric, and continue to maintain two 
packages? You probably have, but I though I'd ask anyway...

> Ultimately I think it will be a wise 
> thing to have two implementations of arrays: one that is fast and 
> lightweight optimized for many relatively small arrays, and another that 
> is optimized for large-scale arrays.

Are these really incompatable goals?

> If most of the community 
> wants to see Numeric go away then we will be forced to  bring the 
> Numeric array under the SciPy code-base and own it there.

I think it's quite the opposite... if most of the community wants to see 
Numeric continue on, it must be maintained (and improved) with little 
change to the API. If we're all going to switch to Numarray, then the 
SciPy project can do whatever it wants with Numeric...

In Summary:

- Anything called "Numeric" should have a compatable API to the current 
version

- I'd much rather have just one N-d array type, preferable one that is 
part of the Python Standard Library...is likely to ever happen?

- I also want fast small arrays.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] numarray 0.8 and MacOSX

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

On Tue, 2004-01-20 at 12:44, Francesc Alted wrote:
> Hi,
> 
> I'm trying to compile numarray 0.8 on a MacOSX (Darwin 6.8). The compilation
> process seemed to go well, but an error happens when trying to import
> numarray:
> 
> [falted@ppc-osx2:numarray-0.8]$ python
> Python 2.2 (#1, 10/24/02, 16:10:52)
> [GCC Apple cpp-precomp 6.14] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numarray
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/home/users/f/fa/falted/bin-macosx//lib/python/numarray/__init__.py", 
> line 11, in ?
>     from numarrayall import *
>   File 
> "/home/users/f/fa/falted/bin-macosx//lib/python/numarray/numarrayall.py", 
> line 2, in ?
>     from generic import *
>   File "/home/users/f/fa/falted/bin-macosx//lib/python/numarray/generic.py", 
> line 1030, in ?
>     import numarraycore as _nc
>   File 
> "/home/users/f/fa/falted/bin-macosx//lib/python/numarray/numarraycore.py", 
> line 29, in ?
>     PyINT_TYPES = {
> NameError: name 'bool' is not defined
> 
> I know that there are available ports of numarray 0.8 to Darwin, but, for a
> series of reasons, I prefer to compile it for myself. Anyone can provide a
> hint so as to compile it cleanly?

I tested numarray-0.8 on Darwin,  but I tested it against user installed
versions of Python 2.2.3 and 2.3.2.  Both of these versions define
bool.  On the version of Mac OS-X I've got (10.2?), /usr/bin/python is
2.2.0, and it does not define bool.

So,  I don't think there is a clean compile, at least not for Mac users
who don't also install updated versions of Python.

Todd

> 
> Thanks,
> 
> -- 
> Francesc Alted
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

[Numpy-discussion] numarray 0.8 and MacOSX

[Francesc A. <fa...@op...>]

Hi,

I'm trying to compile numarray 0.8 on a MacOSX (Darwin 6.8). The compilation
process seemed to go well, but an error happens when trying to import
numarray:

[falted@ppc-osx2:numarray-0.8]$ python
Python 2.2 (#1, 10/24/02, 16:10:52)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numarray
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/users/f/fa/falted/bin-macosx//lib/python/numarray/__init__.py", 
line 11, in ?
    from numarrayall import *
  File 
"/home/users/f/fa/falted/bin-macosx//lib/python/numarray/numarrayall.py", 
line 2, in ?
    from generic import *
  File "/home/users/f/fa/falted/bin-macosx//lib/python/numarray/generic.py", 
line 1030, in ?
    import numarraycore as _nc
  File 
"/home/users/f/fa/falted/bin-macosx//lib/python/numarray/numarraycore.py", 
line 29, in ?
    PyINT_TYPES = {
NameError: name 'bool' is not defined

I know that there are available ports of numarray 0.8 to Darwin, but, for a
series of reasons, I prefer to compile it for myself. Anyone can provide a
hint so as to compile it cleanly?

Thanks,

-- 
Francesc Alted

[Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #808 - 2 msgs

[Paul M. <p.m...@sn...>]

> 
> --__--__--
> 
> Message: 1
> Date: Mon, 19 Jan 2004 14:32:51 -0600
> From: Travis Oliphant <oli...@ee...>
> To:  num...@li...,  pyt...@py...
> Subject: [Numpy-discussion] Status of Numeric
> 

> 
> The purpose of this email is to assess the attitude of the community 
> regarding how these changes to Numeric should be accomplished. 
> 
> These are the two options we can see:
> * freeze old Numeric 23.x  and make all changes to Numeric 24.x  still 
> keeping Numeric separate from  SciPy
> * freeze old Numeric 23.x and subsume Numeric into SciPy essentially 
> creating a new SciPy arrayobject that is fast and lightweight.  Anybody 
> wanting this new array object would get it by installing scipy_base.  
> Numeric would never change in the future but the array in scipy_base would.


My preference would be for option #1 -- continue further development of 
Numeric as a separate package with new improvements going into the 24.x 
series.  It's my experience that when projects get subsumed, additional 
requirements tend to creep in, even if they're not actually "required."

--Paul Magwene

Re: [Numpy-discussion] Status of Numeric

[Konrad H. <hi...@cn...>]

On 19.01.2004, at 21:32, Travis Oliphant wrote:

> These are the two options we can see:
> * freeze old Numeric 23.x  and make all changes to Numeric 24.x  still=20
> keeping Numeric separate from  SciPy
> * freeze old Numeric 23.x and subsume Numeric into SciPy essentially=20
> creating a new SciPy arrayobject that is fast and lightweight. =20
> Anybody wanting this new array object would get it by installing=20
> scipy_base.  Numeric would never change in the future but the array in=20
> scipy_base would.

That depends on the exact nature of the changes. My view is that any=20
package that is upwards-compatible with Numeric (except for bug fixes=20
of course) should be called Numeric and distributed as such. Any=20
package that is intentionally incompatible with Numeric in some=20
important aspect should not be called Numeric. There is a lot of code=20
out there that builds on Numeric, and some of it is hardly maintained=20
any more, although there are still users around. Those users expect to=20
be able to upgrade Numeric without breaking their code.

Konrad.

RE: [Numpy-discussion] Status of Numeric

[Perry G. <pe...@st...>]

Travis Oliphant writes:
> 
> Numarray is making great progress and is quite usable for many 
> purposes.  An idea that was championed by some is that the Numeric code 
> base would stay static and be replaced entirely by Numarray.
> 
> However, Numeric is currently used in a large installed base.  In 
> particular SciPy uses Numeric as its core array.  While no doubt 
> numarray arrays will be supported in the future, the speed of the less 
> bulky Numeric arrays and the typical case that we encounter in SciPy of 
> many, small arrays will make it difficult for people to abandon Numeric 
> entirely with it's comparatively light-weight arrays.
> 
I'd like to ask if the numarray option couldn't at least be
considered. In particular with regard to speed, we'd like to know
what the necessary threshold is. For many ufuncs, numarray is
within a factor of 3 or so of Numeric for small arrays. Is this
good enough or not? What would be good enough? It would probably 
be difficult to make it as fast in all cases, but how close does it
have to be? A factor of 2? 1.5? We haven't gotten very much feedback
on specific numbers in this regard.

Are there other aspects of numarray performance that are a problem?
What specifically? We don't have the resources to optimize everything
in case it might affect someone. We need to know that it is particular
problem with users to give it some priority (and know what the
necessary threshold is for acceptable performance). Perhaps the two
(Numeric and numarray) may need to coexist for a while, but we would
like to isolate the issues that make that necessary. That hasn't 
really happened yet.

Travis, do you have any specific nummarray speed issues that have
arisen from your benchmarking or use that we can look at?

Perry Greenfield 

[Numpy-discussion] Status of Numeric

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

Numarray is making great progress and is quite usable for many 
purposes.  An idea that was championed by some is that the Numeric code 
base would stay static and be replaced entirely by Numarray.

However, Numeric is currently used in a large installed base.  In 
particular SciPy uses Numeric as its core array.  While no doubt 
numarray arrays will be supported in the future, the speed of the less 
bulky Numeric arrays and the typical case that we encounter in SciPy of 
many, small arrays will make it difficult for people to abandon Numeric 
entirely with it's comparatively light-weight arrays.

In the development of SciPy we have encountered issues in Numeric that 
we feel need to be fixed.    As this has become an important path to 
success of several projects (both commercial and open) it is absolutely 
necessary that this issues be addressed.

The purpose of this email is to assess the attitude of the community 
regarding how these changes to Numeric should be accomplished. 

These are the two options we can see:
* freeze old Numeric 23.x  and make all changes to Numeric 24.x  still 
keeping Numeric separate from  SciPy
* freeze old Numeric 23.x and subsume Numeric into SciPy essentially 
creating a new SciPy arrayobject that is fast and lightweight.  Anybody 
wanting this new array object would get it by installing scipy_base.  
Numeric would never change in the future but the array in scipy_base would.

It is not an option to wait for numarray to get fast enough as these 
issues need to be addressed now.  Ultimately I think it will be a wise 
thing to have two implementations of arrays: one that is fast and 
lightweight optimized for many relatively small arrays, and another that 
is optimized for large-scale arrays.  Eventually, the use of these two 
underlying implementations should be automatic and invisible to the user.

A few of the particular changes we need to make to the Numeric 
arrayobject are:

1) change the coercion model to reflect Numarray's choice and eliminate 
the savespace crutch.
2) Add indexing capability to Numeric arrays (similar to Numarray's)
3) Improve the interaction between Numeric arrays and scalars.
4) Optimization:

Again, these changes are going to be made to some form of the Numeric 
arrays.  What I am really interested in knowing is the attitude of the 
community towards keeping Numeric around.   If most of the community 
wants to see Numeric go away then we will be forced to  bring the 
Numeric array under the SciPy code-base and own it there.

Your feedback is welcome and appreciated. 

Sincerely,

Travis Oliphant and other SciPy developers

Re: [Numpy-discussion] numarray.records - get/set item

[Sebastian H. <ha...@ms...>]

Hi everybody,
I would like to check if there has been made a decision on this ?
I'm planning to use record arrays to access image data header-information
and having an attribute 'f' like suggested is still my favorite way.

Is anyone besides me using record arrays on memory-mapped buffers ?

Thanks,
Sebastian Haase

----- Original Message ----- 
From: "Sebastian Haase" <ha...@ms...>
To: <num...@li...>
Sent: Thursday, December 04, 2003 4:27 PM
Subject: Fw: [Numpy-discussion] numarray.records - get/set item


> My situation where I got onto this, is having one field named 'mmm'
> ("MinMaxMean") being an 3 element array.
> Now, to assign the values first I tried:
> self.hdrArray = makeHdrArray(self.h)   #this makes the record array
> self.hdr = self.hdrArray[0].field              #this is my shortcut to the
> bound member function
>    # it essentially is a solution (hack) for the getitem part
>    # but regarding setitem I had to learn that "assigning to a function"
is
> illigal in Python - as opposed to C++
> #so to do assignment  I need to do:
> self.hdr('mmm')[0], self.hdr('mmm')[1], self.hdr('mmm')[2] = (mi,ma,av)
>
> now that I'm looking at it,
> self.hdrArray[0].setfield('mmm', (mi,ma,av))
> would probably be better...
>
> How about adding an attribute 'f' which could serve as a "proxy" to allow:
> myRec.f.mmm = (mi,ma,av)
> and maybe even additionally:
> myRec.f['mmm'] = (mi,ma,av)
>
> Regards,
> Sebastian
>
>
>
> ----- Original Message ----- 
> From: "Perry Greenfield" <pe...@st...>
> To: "Sebastian Haase" <ha...@ms...>;
> <num...@li...>
> Sent: Thursday, December 04, 2003 3:08 PM
> Subject: RE: [Numpy-discussion] numarray.records - get/set item
>
>
> > > Hi,
> > > Is it maybe a good idea to add this to the definition of 'class
Record'
> > >
> > > class Record:
> > >     """Class for one single row."""
> > > <snip>
> > >     def __getitem__(self, fieldName):
> > >         return self.array.field(fieldName)[self.row]
> > >     def __setitem__(self, fieldName, value):
> > >         self.array.field(fieldName)[self.row] = value
> > >
> > > I don't know  about the implications if  __delitem __  and so on are
not
> > > defined.
> > > I just think it would look quite nice to say
> > > myRecArr[0]['mmm'] = 'hallo'
> > > as opposed to
> > > myRecArr[0].setfield('mmm',  'hallo')
> > >
> > > Actually I would even like
> > > myRecArr[0].mmm = 'hallo'
> > >
> > > This should be possible by defining __setattr__.
> > > It would obviously only work for fieldnames that do not contain '.' or
'
> '
> > > or ...
> > >
> > > Any comments ?
> > >
> > >
> > We've had many internal discussions about doing this. The latter was
> > considered a problem because of possible name collisions of field
> > names with other attributes or methods. The former is not bothered
> > by this problem, but we decided to be conservative on this and see
> > how strong the need was. We are interested in other opinions.
> >
> > Perry
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Tabs in numarray code

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

On Fri, 2004-01-16 at 11:09, Todd Miller wrote:
> On Fri, 2004-01-16 at 10:47, Edward C. Jones wrote:
> > What are the policies about tab characters in numarray Python and C 
> > code? What are the policies about indentation in numarray Python and C code?
> 
> The policy is "no tabs".
> Indentation in Python and C is 5 spaces per level.

Actually, I meant *4* spaces, and enforcement is somewhat worse than I
thought.

> Enforcement of the policies is obviously currently lacking.
> 
> Todd
> 
> > 
> > The following small program found a bunch of tabs in numarray code:
> > --------
> > #! /usr/local/bin/python
> > 
> > import os
> > 
> > topdir = '/usr/local/src/numarray-0.8/'
> > for dirpath, dirnames, filenames in os.walk(topdir):
> >     for name in filenames:
> >         if name.endswith('.py'):
> >             fullname = os.path.join(dirpath, name)
> >             lines = file(fullname, 'r').read().splitlines()
> >             for i, line in enumerate(lines):
> >                 if '\t' in line:
> >                     print fullname[len(topdir):], i+1, line
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Numpy-discussion mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> -- 
> Todd Miller 			
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21030
> (410) 338 - 4576
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

Re: [Numpy-discussion] Tabs in numarray code

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

On Fri, 2004-01-16 at 10:47, Edward C. Jones wrote:
> What are the policies about tab characters in numarray Python and C 
> code? What are the policies about indentation in numarray Python and C code?

The policy is "no tabs".
Indentation in Python and C is 5 spaces per level.
Enforcement of the policies is obviously currently lacking.

Todd

> 
> The following small program found a bunch of tabs in numarray code:
> --------
> #! /usr/local/bin/python
> 
> import os
> 
> topdir = '/usr/local/src/numarray-0.8/'
> for dirpath, dirnames, filenames in os.walk(topdir):
>     for name in filenames:
>         if name.endswith('.py'):
>             fullname = os.path.join(dirpath, name)
>             lines = file(fullname, 'r').read().splitlines()
>             for i, line in enumerate(lines):
>                 if '\t' in line:
>                     print fullname[len(topdir):], i+1, line
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

[Numpy-discussion] Tabs in numarray code

[Edward C. J. <edc...@er...>]

What are the policies about tab characters in numarray Python and C 
code? What are the policies about indentation in numarray Python and C code?

The following small program found a bunch of tabs in numarray code:
--------
#! /usr/local/bin/python

import os

topdir = '/usr/local/src/numarray-0.8/'
for dirpath, dirnames, filenames in os.walk(topdir):
    for name in filenames:
        if name.endswith('.py'):
            fullname = os.path.join(dirpath, name)
            lines = file(fullname, 'r').read().splitlines()
            for i, line in enumerate(lines):
                if '\t' in line:
                    print fullname[len(topdir):], i+1, line

[Numpy-discussion] Problem with Sourceforge mailing list archives?

[Edward C. J. <edc...@er...>]

The "Numpy-discussion Archives"  at 
"https://lists.sourceforge.net/lists/listinfo/numpy-discussion" are down 
or missing. Is there a problem?

Re: [Numpy-discussion] _clone, copy, view

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

On Thu, 2004-01-15 at 09:30, Colin J. Williams wrote:
> It would help if someone could describe the intended functional 
> differences between _clone, copy and view in numarray.

a.copy() returns a new array object with a copy of a's data. a's
dictionary attributes are currently aliased, not deep copied.  That may
not be the way it should be.  The copy is assumed to be a C_ARRAY,
meaning it is aligned, not byteswapped, and contiguous.  Thus, copy()
is sometimes used as a cleanup operation.

a.view() returns a shallow copy of a.  Most importantly, the shallow
copy aliases the same data as a.  Views are used to look at the same
data buffer in some new way, perhaps with a different shape, or perhaps
as a subset of the original data.  A view has the same special
properties as the original, e.g. if the original is byteswapped, so is
the view.

a._clone() is an implementation detail of the generic take() method. 
The generic take() method is overridden for numerical arrays,  but
utilized for object arrays.  clone()'s purpose is to return a new array
of the same type as 'a' but with a different shape and total number of
elements.  Thus, clone() is useful for creating result arrays for take
based on the input array being taken from.
> 
> Colin W.
> 

-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

[Numpy-discussion] _clone, copy, view

[Colin J. W. <cj...@sy...>]

It would help if someone could describe the intended functional 
differences between _clone, copy and view in numarray.

Colin W.

Re: [Numpy-discussion] numarray setup.py

[<jo...@fh...>]

On Wed, 14 Jan 2004 05:51:06 -0500 Todd Miller wrote:

Todd> On Wed, 2004-01-14 at 02:58, Jochen K=FCpper wrote:
>> Sometime after v0.8 setup.py was changed to include some
>> 'classifiers'. Doesn't work for me (python 2.2.2 on FreeBSD):

Todd> I removed the classifiers for Pythons < 2.3. This is
Todd> (theoretically) fixed in CVS and tested against 2.2.3. Let me
Todd> know if there's still a problem with 2.2.2.

Seems to work now.

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: [Numpy-discussion] numarray setup.py

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

On Wed, 2004-01-14 at 02:58, Jochen Küpper wrote:
> Sometime after v0.8 setup.py was changed to include some
> 'classifiers'. Doesn't work for me (python 2.2.2 on FreeBSD):

I removed the classifiers for Pythons < 2.3.  This is (theoretically)
fixed in CVS and tested against 2.2.3.  Let me
know if there's still a problem with 2.2.2.

Todd

> 
> ,----[python setup.py install --home=~/install/freebsd-x86]
> | Using EXTRA_COMPILE_ARGS = []
> | error in setup script: invalid distribution option 'classifiers'
> `----
> 
> Greetings,
> Jochen
-- 
Todd Miller <jm...@st...>

[Numpy-discussion] numarray setup.py

[<jo...@fh...>]

Sometime after v0.8 setup.py was changed to include some
'classifiers'. Doesn't work for me (python 2.2.2 on FreeBSD):

,----[python setup.py install --home=3D~/install/freebsd-x86]
| Using EXTRA_COMPILE_ARGS =3D []
| error in setup script: invalid distribution option 'classifiers'
`----

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

[Numpy-discussion] Car Raffle Donate to Charity Cadillac Raffle

[<chi...@ya...>]

Car Raffle Donate to Charity Cadillac Raffle
 
  http://www.ChildLiteracy.org/
Current Raffles  
2003 BLACK CADILLAC DEVILLE DTS        $100 per ticket 
Mitsubishi's 2002 Montero Sport LS              $35 per ticket 
Pioneer PDP-4330HD 43" Plasma TV          $20 per ticket
 http://www.ChildLiteracy.org

Re: [Numpy-discussion] License.txt inclussion breaks McMillan's Installer.

[David M. C. <co...@ph...>]

On Fri, Jan 09, 2004 at 08:50:04AM -0500, Todd Miller wrote:
> On Thu, 2004-01-08 at 18:37, Tim Hochberg wrote:
> > 
> > The way LICENSE.txt is included in the __init__ file for numarray breaks 
> > McMillan's installer (and probably py2exe as well, although I haven't 
> > checked that). The offending line is:
> > 
> >     __LICENSE__ = open(_os.path.join(__path__[0],"LICENSE.txt")).read()
> > 
> > 
> > The first problem is that the installer doesn't pick up the dependancy 
> > on LICENSE.txt. That's not a huge deal as it's relatively simple to add 
> > that to the list of dependancy's by hand.
> > 
> > More serious is that the __path__ variable is bogus in an installer 
> > archive so that the reading of the license file fails, even if it's present.
> > 
> > One solution is just include the license text directly instead of 
> > reading it from a separate file. This is simple and the license is short 
> > enough that this shouldn't clutter things too much. It's not like 
> > there's all that much in the __init__ file anyway <0.5 wink>.
> 
> I like this solution the best from the perspective of simplicity and
> fool-proof-ness.  I had considered it before but rejected it as leading
> to duplication of the license.  Now I realize I can just "put a symbolic
> link" in LICENSE.txt and move the actual text of the license to
> __init__.py as you suggest.
> 
> This is fixed in CVS now.
> 
> Todd

I have to admit that I read the problem above and thought, WHAT?
numarray already takes longer to import than Numeric; you mean some of
that time it's reading in a license file I'll never look at?

Compare:

$ time python -c 'import numarray'
real    0m0.230s
user    0m0.230s
sys     0m0.000s
$ time python -c 'import Numeric'
real    0m0.076s
user    0m0.050s
sys     0m0.020s

[final results after running each a couple times to get it in cache]

numarray takes 3 times longer to import than Numeric. I know, it's only
0.154 s difference, but that's noticeable for small scripts.

[Ok, so I just tested the change to reading the license, and I don't
see any change in import times :-)]

If I had any time, I'd look at making it import faster. Some playing
around with the hotshot profiler shows that most of the time is spent in
numarray.ufunc._makeCUFuncDict.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] License.txt inclussion breaks McMillan's Installer.

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

On Thu, 2004-01-08 at 18:37, Tim Hochberg wrote:
> 
> The way LICENSE.txt is included in the __init__ file for numarray breaks 
> McMillan's installer (and probably py2exe as well, although I haven't 
> checked that). The offending line is:
> 
>     __LICENSE__ = open(_os.path.join(__path__[0],"LICENSE.txt")).read()
> 
> 
> The first problem is that the installer doesn't pick up the dependancy 
> on LICENSE.txt. That's not a huge deal as it's relatively simple to add 
> that to the list of dependancy's by hand.
> 
> More serious is that the __path__ variable is bogus in an installer 
> archive so that the reading of the license file fails, even if it's present.
> 
> One solution is just include the license text directly instead of 
> reading it from a separate file. This is simple and the license is short 
> enough that this shouldn't clutter things too much. It's not like 
> there's all that much in the __init__ file anyway <0.5 wink>.

I like this solution the best from the perspective of simplicity and
fool-proof-ness.  I had considered it before but rejected it as leading
to duplication of the license.  Now I realize I can just "put a symbolic
link" in LICENSE.txt and move the actual text of the license to
__init__.py as you suggest.

This is fixed in CVS now.

Todd
> A second solution is to wrap the  above incantation in try, except; 
> however, this doesn't guarantee that the license file is included.
> 
> A third solution is to come up with a different incantation that works 
> for installer. I've looked at this briefly and it looks a little messy. 
> Nevertheless, I'll come up with something that works if this is deemed 
> the preferred solution. Someone else will have to figure out what works 
> with py2exe.
> 
> [ If the above makes no sense to those of you unfamilar with McMillan's 
> installer, I apologize -- ask away and I'll try to clarify]
> 
> Regards
> 
> -tim
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

[Numpy-discussion] License.txt inclussion breaks McMillan's Installer.

[Tim H. <tim...@ie...>]

The way LICENSE.txt is included in the __init__ file for numarray breaks 
McMillan's installer (and probably py2exe as well, although I haven't 
checked that). The offending line is:

    __LICENSE__ = open(_os.path.join(__path__[0],"LICENSE.txt")).read()


The first problem is that the installer doesn't pick up the dependancy 
on LICENSE.txt. That's not a huge deal as it's relatively simple to add 
that to the list of dependancy's by hand.

More serious is that the __path__ variable is bogus in an installer 
archive so that the reading of the license file fails, even if it's present.

One solution is just include the license text directly instead of 
reading it from a separate file. This is simple and the license is short 
enough that this shouldn't clutter things too much. It's not like 
there's all that much in the __init__ file anyway <0.5 wink>.

A second solution is to wrap the  above incantation in try, except; 
however, this doesn't guarantee that the license file is included.

A third solution is to come up with a different incantation that works 
for installer. I've looked at this briefly and it looks a little messy. 
Nevertheless, I'll come up with something that works if this is deemed 
the preferred solution. Someone else will have to figure out what works 
with py2exe.

[ If the above makes no sense to those of you unfamilar with McMillan's 
installer, I apologize -- ask away and I'll try to clarify]

Regards

-tim

RE: [Numpy-discussion] Update for IM. a small image processing system

[Nadav H. <na...@vi...>]

I am producing and reading 16 bit tiff files using PIL. These files
however can not be displayed by most image processing programs (gimp
does fine).

  Nadav


-----Original Message-----
From:	Peter Verveer [mailto:ve...@em...]
Sent:	Thu 08-Jan-04 11:41
To:	Sebastian Haase; num...@li...
Cc:=09
Subject:	Re: [Numpy-discussion] Update for IM. a small image processing =
system
Hi Sebastian,

I use the 1.1.4 final version. I do however, have images that are not =
read by=20
PIL ('cannot identify image file'). I think these files are okay, since =
I can=20
read them in a scientific imaging program. So maybe the 16bit support in =
PIL=20
is not complete.

Peter

On Wednesday 07 January 2004 20:43, Sebastian Haase wrote:
> > know a good solution for getting 16bit tiffs into numarray?
>
> Hi Peter,
> When did you try that ?  My info is the PIL released within the last =
few
> month version 1.1.4 which does the job.
> this is from http://effbot.org/zone/pil-changes-114.htm:
>
> (1.1.4a2 released)
>
> + Improved support for 16-bit unsigned integer images (mode "I;16").
>   This includes TIFF reader support, and support for "getextrema"
>   and "point" (from Klamer Shutte).
>
> (Ooops: PIL 1.1.4 final was released on May 10, 2003.   (time flies =
...)



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Numpy-discussion mailing list
Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion