date:20090203

Pierre,

Should the following work?

import numpy as np
from StringIO import StringIO

converter = {'date':lambda s: datetime.strptime(s,'%Y-%m-%d %H:%M:%SZ')}
data = np.ndfromtxt(StringIO('2009-02-03 12:00:00Z,72214.0'), delimiter=',',
names=['date','stid'], dtype=None, converters=converter)

Right now, it's giving me the following:

Traceback (most recent call last):
  File check_oban.py, line 15, in module
converters=converter)
  File /home/rmay/.local/lib64/python2.5/site-packages/numpy/lib/io.py, line
993, in ndfromtxt
return genfromtxt(fname, **kwargs)
  File /home/rmay/.local/lib64/python2.5/site-packages/numpy/lib/io.py, line
842, in genfromtxt
locked=True)
  File /home/rmay/.local/lib64/python2.5/site-packages/numpy/lib/_iotools.py,
line 472, in update
self.type = self._getsubdtype(func('0'))
  File check_oban.py, line 9, in lambda
lambda s: datetime.strptime(s,'%Y-%m-%d %H:%M:%SZ').replace(tzinfo=UTC)}
  File /usr/lib64/python2.5/_strptime.py, line 330, in strptime
(data_string, format))
ValueError: time data did not match format:  data=0  fmt=%Y-%m-%d %H:%M:%SZ

Which comes from a part of the code in updating converters where it passes the
string '0' to the converter.  Are the converters expected to handle what amounts
to bad input even though the file itself has no such problems? Specifying the
dtype doesn't appear to help either.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] genloadtxt question

2009-02-03 Thread Pierre GM


On Feb 3, 2009, at 11:24 AM, Ryan May wrote:

 Pierre,

 Should the following work?

 import numpy as np
 from StringIO import StringIO

 converter = {'date':lambda s: datetime.strptime(s,'%Y-%m-%d %H:%M: 
 %SZ')}
 data = np.ndfromtxt(StringIO('2009-02-03 12:00:00Z,72214.0'),  
 delimiter=',',
 names=['date','stid'], dtype=None, converters=converter)

Well, yes, it should work. That's indeed a problem with the  
getsubdtype method of the converter.
The problem is that we need to estimate the datatype of the output of  
the converter. In most cases, trying to convert '0' works properly,  
not in yours however. In r6338, I force the type to object if  
converting '0' does not work. That's a patch till the next corner  
case...

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] genloadtxt question

Pierre GM wrote:
 On Feb 3, 2009, at 11:24 AM, Ryan May wrote:
 
 Pierre,

 Should the following work?

 import numpy as np
 from StringIO import StringIO

 converter = {'date':lambda s: datetime.strptime(s,'%Y-%m-%d %H:%M: 
 %SZ')}
 data = np.ndfromtxt(StringIO('2009-02-03 12:00:00Z,72214.0'),  
 delimiter=',',
 names=['date','stid'], dtype=None, converters=converter)
 
 Well, yes, it should work. That's indeed a problem with the  
 getsubdtype method of the converter.
 The problem is that we need to estimate the datatype of the output of  
 the converter. In most cases, trying to convert '0' works properly,  
 not in yours however. In r6338, I force the type to object if  
 converting '0' does not work. That's a patch till the next corner  
 case...

Thanks for the quick patch!  And yeah, I can't think of any better behavior. 
It's
 actually what I ended up doing in my conversion function, so, if nothing else,
it removes the user from having to write that kind of boilerplate code.

Thanks,

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] N-D array interface page is out of date

2009-02-03 Thread Stéfan van der Walt

2009/2/3 Andrew Straw straw...@astraw.com:
 Can someone with appropriate permissions fix the page or give me the
 appropriate permissions so I can do it? I think even deleting the page
 is better than keeping it as-is.

Who all has editing access to this page?  Is it hosted on scipy.org?

Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] example reading binary Fortran file

2009-02-03 Thread David Froger

Thanks a lot Fransesc and Neil, yours messages really help me.

I'll look at these solutions attentively.

Here is what I write recently, but I begin to understand it's effectively
not portable...

def fread(fileObject,*arrayAttributs):
 Reading in a binary (=unformatted) Fortran file

Let's call 'record' the list of arrays written with one write in the
Fortran file.

Call one fread per write.

Parameter :
* fileObject, eg: fileObject = open(data.bin,'rb')
* arrayAttributs = ( (shape1,dtype1,readorskip1),
(shape2,dtype2,readorskip2) ...)
 * shape: eg: (100,200)
 * dtype: eg: 'f4' (little endian, simple precision), 'f8'
(big endian, double precision)
 * readorskip = [0|1]
  * 1: the array is read and return
  * 0: the size of the array is skipped to read the array
after, the array isn't returned

Exemples (with write ux,uy,p in the Fortran code)
* f = open(uxuyp.bin,'rb')
  nx,ny = 100,200
  p = readFortran( f, ((nx,ny),'f8',0), ((nx,ny),'f8',0),
((nx,ny),'f8',1) )
  f.close

import numpy,os,utils

# compute the recordSize to be read
recordBytes = 8
for (shape,dtype,read) in arrayAttributs:
dtype = numpy.dtype(dtype)
# number of elements to be read in this array
count = 1
for size in shape:
count *= size
# size of the record
recordBytes += count*dtype.itemsize

# the fileSize
fileSize = os.stat(fileObject.name)[6]

# compare recordSize and fileSize
if recordBytes  fileSize:
import logging
logging.error('To much data to be read in %r',fileObject.name)
logging.error('File Size: %r',fileSize)
logging.error('To be read: %r',recordBytes)
NoneList = []
for (shape,dtype,read) in arrayAttributs:
if read: NoneList.append(None)
return NoneList

# skip the four bytes in the beginning of the record
fileObject.seek(4,1)

# read the arrays in record
arrays = []
for (shape,dtype,read) in arrayAttributs:
# number of elements to be read in this array
count=1
for size in shape:
count *= size
if read:
array = numpy.fromfile(fileObject, count=count,
dtype=dtype).reshape(shape, order='F')
arrays.append(array)
else:
dtype = numpy.dtype(dtype)
arrayBytes = count*dtype.itemsize
fileObject.seek(arrayBytes,1)

# skip the four bytes at the end of the record
fileObject.seek(4,1)
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] example reading binary Fortran file

2009-02-03 Thread David Froger

the last line was missing :

 return arrays
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Operations on masked items

Ryan May wrote:
 Pierre,
 
 I know you did some preliminary work on helping to make sure that doing
 operations on masked arrays doesn't change the underlying data.  I ran into 
 the
 following today.
 
 import numpy as np
 a = np.ma.array([1,2,3], mask=[False, True, False])
 b = a * 10
 c = 10 * a
 print b.data # Prints [10 2 30] Good!
 print c.data # Prints [10 10 30] Oops.
 
 I tracked it down to __call__ on the _MaskedBinaryOperation class.  If 
 there's a
 mask on the data, you use:
 
   result = np.where(m, da, self.f(da, db, *args, **kwargs))
 
 You can see that if a (and hence da) is a scalar, your masked values end up 
 with
 the value of the scalar.  If this is getting too hairy to handle not touching
 data, I understand.  I just thought I should point out the inconsistency here.

Well, I guess I hit send too soon.  Here's one easy solution (consistent with
what you did for __radd__), change the code for __rmul__ to do:

return multiply(self, other)

instead of:

return multiply(other, self)

That fixes it for me, and I don't see how it would break anything.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] numscons/numpy.distutils bug related to MACOSX_DEPLOYMENT_TARGET

I am trying to use numscons to build a project and have run into a
show stopper.  I am using:

OS X 10.5
The builtin Python 2.5.2

Here is what I see upon running python setup.py scons:

scons: Reading SConscript files ...
DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch: now 10.3
but 10.5 during configure:
  File 
/Users/bgranger/Library/Python/2.5/src/numscons/tests/examples/checkers/SConstruct,
line 2:
GetInitEnvironment(ARGUMENTS).DistutilsSConscript('SConscript')
  File 
/Users/bgranger/Library/Python/2.5/site-packages/numscons-0.9.4-py2.5.egg/numscons/core/numpyenv.py,
line 108:
[this goes on for a while]

This bug is one that I am familiar with.  Here is a sketch:

* numpy.distutils sets MACOSX_DEPLOYMENT_TARGET=10.3 if
MACOSX_DEPLOYMENT_TARGET is not set in the environment.

* But, the built-in Python on OS X 10.5 has
MACOSX_DEPLOYMENT_TARGET=10.5.  When Python is built, it saves this
info in a file.

* When called distutils checks to make sure that the current value of
MACOSX_DEPLOYMENT_TARGET matches the one that was used to build
Python.

Hence the mismatch.  I am pretty sure that the offending code is in:

numpy.distutils.fcompiler.gnu.get_flags_linker_so

I think I know how to fix this and will get started on it, but I
wanted to see if anyone else had any experience with this or knew
another way around this.

Cheers,

Brian
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numscons/numpy.distutils bug related to MACOSX_DEPLOYMENT_TARGET

On Tue, Feb 3, 2009 at 18:12, Brian Granger ellisonbg@gmail.com wrote:
I am trying to use numscons to build a project and have run into a
show stopper. I am using:

OS X 10.5
The builtin Python 2.5.2

Here is what I see upon running python setup.py scons:

scons: Reading SConscript files ...
DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch: now 10.3
but 10.5 during configure:
File
/Users/bgranger/Library/Python/2.5/src/numscons/tests/examples/checkers/SConstruct,
line 2:
GetInitEnvironment(ARGUMENTS).DistutilsSConscript('SConscript')
File
/Users/bgranger/Library/Python/2.5/site-packages/numscons-0.9.4-py2.5.egg/numscons/core/numpyenv.py,
line 108:
[this goes on for a while]

This bug is one that I am familiar with. Here is a sketch:

* numpy.distutils sets MACOSX_DEPLOYMENT_TARGET=10.3 if
MACOSX_DEPLOYMENT_TARGET is not set in the environment.

* But, the built-in Python on OS X 10.5 has
MACOSX_DEPLOYMENT_TARGET=10.5. When Python is built, it saves this
info in a file.

* When called distutils checks to make sure that the current value of
MACOSX_DEPLOYMENT_TARGET matches the one that was used to build
Python.

Hence the mismatch. I am pretty sure that the offending code is in:

numpy.distutils.fcompiler.gnu.get_flags_linker_so

I think I know how to fix this and will get started on it, but I
wanted to see if anyone else had any experience with this or knew
another way around this.

Well, the workaround is to set MACOSX_DEPLOYMENT_TARGET=10.5 in your
environment.

--
Robert Kern

I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth.
-- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numscons/numpy.distutils bug related to MACOSX_DEPLOYMENT_TARGET

On Tue, Feb 3, 2009 at 18:20, Brian Granger ellisonbg@gmail.com wrote:
 Robert,

 Thanks.

 Yes, I just saw that this will work.  When I fixed this in Cython a
 while back this workaround wouldn't work.  Would you still consider
 this a bug?  The logic to fix it is fairly simply.

What is the fix you are thinking of?

-- 
Robert Kern

I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth.
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Operations on masked items

2009-02-03 Thread Pierre GM


On Feb 3, 2009, at 4:00 PM, Ryan May wrote:

 Well, I guess I hit send too soon.  Here's one easy solution  
 (consistent with
 what you did for __radd__), change the code for __rmul__ to do:

   return multiply(self, other)

 instead of:

   return multiply(other, self)

 That fixes it for me, and I don't see how it would break anything.

Good call, but once again: Thou shalt not put trust in ye masked  
values [1].

  a = np.ma.array([1,2,3],mask=[0,1,0])
  b = np.ma.array([10, 20, 30], mask=[0,1,0])
  (a*b).data
array([10,  2, 90])
  (b*a).data
array([10, 20, 90])

So yes, __mul__ is not commutative when you deal w/ masked arrays (at  
least, when you try to access the data under a mask). Nothing I can  
do. Remember that preventing the underlying data to be modified is  
NEVER guaranteed...

[1] Epistle of Paul (Dubois).
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Operations on masked items

Pierre,

I know you did some preliminary work on helping to make sure that doing
operations on masked arrays doesn't change the underlying data.  I ran into the
following today.

import numpy as np
a = np.ma.array([1,2,3], mask=[False, True, False])
b = a * 10
c = 10 * a
print b.data # Prints [10 2 30] Good!
print c.data # Prints [10 10 30] Oops.

I tracked it down to __call__ on the _MaskedBinaryOperation class.  If there's a
mask on the data, you use:

result = np.where(m, da, self.f(da, db, *args, **kwargs))

You can see that if a (and hence da) is a scalar, your masked values end up with
the value of the scalar.  If this is getting too hairy to handle not touching
data, I understand.  I just thought I should point out the inconsistency here.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Few minor issues with numscons

David,

I am trying to use numscons to build a project and am running into
some problems:

Two smaller issues and one show stopper.  First, the smaller ones:

* The web presense of numscons is currently very confusing.  There are
a couple of locations with info about it, but the most prominent ones
appear to be quite outdated:

http://projects.scipy.org/scipy/numpy/wiki/NumScons

...refers to...

https://code.launchpad.net/numpy.scons.support

Which is no longer being used and doesn't have any links to the most
recent versions  I had to hunt for a while to find the develoment
repo, which is on github and the most recent release, which is now at
pypi.

It is probably a good idea to update these locations so as not to
confuse new folks (or old folks too).

* The scons/scons-local subdir is not installed when running python
setup.py install.  I had to use python setupegg.py to get this to
install in the right place.

I will send a different email in a second about the show stopper as it
is a bigger topic related to a numpy bug.

Cheers,

Brian
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] reading binary Fortran

2009-02-03 Thread Catherine Moroney

I've noticed a lot of discussion on how to read binary files
written out from Fortran, and nobody seems to have mentioned
how to modify your Fortran code so it writes out a file that
can be read with numpy.fromfile() in a single line.

For example, to write out a NLINE x NSMP array of floats in Fortran
in a line by line fashion, the code below works just fine.

open(iunit,file=flname,form='unformatted',access='direct', 
  recl=nsmp*4,status='replace',action='write')
do iline=1,nline
write(iunit,rec=iline) (data(iline,ismp),ismp=1,nsmp)
end do
close(iunit)

It's more code than simply write(iunit) data, but it has the advantage
of being easily imported into python, matlab and other software packages
that can read flat binary data.  To import a file written out in
this fashion into numpy, a single call to numpy.fromfile(flname)
works with no need to define datatypes or the like.

Apologies if I'm missing some reason why the above doesn't work or
is not preferable to the write(iunit) data.

Catherine


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Operations on masked items

Pierre GM wrote:
 On Feb 3, 2009, at 4:00 PM, Ryan May wrote:
 Well, I guess I hit send too soon.  Here's one easy solution  
 (consistent with
 what you did for __radd__), change the code for __rmul__ to do:

  return multiply(self, other)

 instead of:

  return multiply(other, self)

 That fixes it for me, and I don't see how it would break anything.
 
 Good call, but once again: Thou shalt not put trust in ye masked  
 values [1].
 
   a = np.ma.array([1,2,3],mask=[0,1,0])
   b = np.ma.array([10, 20, 30], mask=[0,1,0])
   (a*b).data
 array([10,  2, 90])
   (b*a).data
 array([10, 20, 90])
 
 So yes, __mul__ is not commutative when you deal w/ masked arrays (at  
 least, when you try to access the data under a mask). Nothing I can  
 do. Remember that preventing the underlying data to be modified is  
 NEVER guaranteed...

Fair enough.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numscons/numpy.distutils bug related to MACOSX_DEPLOYMENT_TARGET

 What is the fix you are thinking of?

This is how Cython currently handles this logic.  This would have to
be modified to include the additional case of a user setting
MACOSX_DEPLOYMENT_TARGET in their environment, but that logic is
already in numpy.distutils.fcompiler.gnu.get_flags_linker_so

This is really just a special case for 1) OS X 10.5 and 2) built-in Python.

# MACOSX_DEPLOYMENT_TARGET can be set to 10.3 in most cases.
# But for the built-in Python 2.5.1 on Leopard, it needs to be set for 10.5.
# This looks like a bug that will be fixed in 2.5.2. If Apple updates their
# Python to 2.5.2, this fix should be OK.
import distutils.sysconfig as sc
python_prefix = sc.get_config_var('prefix')
leopard_python_prefix =
'/System/Library/Frameworks/Python.framework/Versions/2.5'
full_version = %s.%s.%s % sys.version_info[:3]
if python_prefix == leopard_python_prefix and full_version == '2.5.1':
os.environ[MACOSX_DEPLOYMENT_TARGET] = 10.5
else:
os.environ[MACOSX_DEPLOYMENT_TARGET] = 10.3
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numscons/numpy.distutils bug related to MACOSX_DEPLOYMENT_TARGET

On Tue, Feb 3, 2009 at 18:34, Brian Granger ellisonbg@gmail.com wrote:
 What is the fix you are thinking of?

 This is how Cython currently handles this logic.  This would have to
 be modified to include the additional case of a user setting
 MACOSX_DEPLOYMENT_TARGET in their environment, but that logic is
 already in numpy.distutils.fcompiler.gnu.get_flags_linker_so

 This is really just a special case for 1) OS X 10.5 and 2) built-in Python.

 # MACOSX_DEPLOYMENT_TARGET can be set to 10.3 in most cases.
 # But for the built-in Python 2.5.1 on Leopard, it needs to be set for 10.5.
 # This looks like a bug that will be fixed in 2.5.2. If Apple updates their
 # Python to 2.5.2, this fix should be OK.
 import distutils.sysconfig as sc
 python_prefix = sc.get_config_var('prefix')
 leopard_python_prefix =
 '/System/Library/Frameworks/Python.framework/Versions/2.5'
 full_version = %s.%s.%s % sys.version_info[:3]
 if python_prefix == leopard_python_prefix and full_version == '2.5.1':
os.environ[MACOSX_DEPLOYMENT_TARGET] = 10.5
 else:
os.environ[MACOSX_DEPLOYMENT_TARGET] = 10.3

Hmm, that's still going to break for any custom build that decides to
build Python with a specific MACOSX_DEPLOYMENT_TARGET. If you're going
to fix it at all, it should default to the value in the Makefile that
sysconfig is going to check against. The relevant code to copy is in
sysconfig._init_posix().

-- 
Robert Kern

I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth.
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numscons/numpy.distutils bug related to MACOSX_DEPLOYMENT_TARGET

 Hmm, that's still going to break for any custom build that decides to
 build Python with a specific MACOSX_DEPLOYMENT_TARGET. If you're going
 to fix it at all, it should default to the value in the Makefile that
 sysconfig is going to check against. The relevant code to copy is in
 sysconfig._init_posix().

Yes, I agree that sysconfig._init_posix() has the proper logic for
this.  This logic should also be applied to Cython as well probably.

Would you say that the proper fix then is to inspect the Makefile and
set MACOSX_DEPLOYMENT_TARGET to the valued used to build Python
itself.  Or should we still try to set it to 10.3 in some cases (like
the current numpy.distutils does) or look at the environment as well?

Cheers,

Brian
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numscons/numpy.distutils bug related to MACOSX_DEPLOYMENT_TARGET

On Tue, Feb 3, 2009 at 18:53, Brian Granger ellisonbg@gmail.com wrote:
 Hmm, that's still going to break for any custom build that decides to
 build Python with a specific MACOSX_DEPLOYMENT_TARGET. If you're going
 to fix it at all, it should default to the value in the Makefile that
 sysconfig is going to check against. The relevant code to copy is in
 sysconfig._init_posix().

 Yes, I agree that sysconfig._init_posix() has the proper logic for
 this.  This logic should also be applied to Cython as well probably.

 Would you say that the proper fix then is to inspect the Makefile and
 set MACOSX_DEPLOYMENT_TARGET to the valued used to build Python
 itself.  Or should we still try to set it to 10.3 in some cases (like
 the current numpy.distutils does) or look at the environment as well?

1) Trust the environment variable if given and let distutils raise its
error message (why not raise it ourselves? distutils' error message
and explanation is already out in THE GOOGLE.)

2) Otherwise, use the value in the Makefile if it's there.

3) If it's not even in the Makefile for whatever reason, go with 10.3.

-- 
Robert Kern

I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth.
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] array vector elementwise multiplication

2009-02-03 Thread Charles R Harris

On Tue, Feb 3, 2009 at 10:19 AM, Gideon Simpson simp...@math.toronto.eduwrote:

 I have an M x N matrix A and two vectors, an M dimensional vector x
 and an N dimensional vector y.  I would like to be able to do two
 things.

 1.  Multiply, elementwise, every column of A by x

 2.  Multiply, elementwise, every row of A by y.

 What's the quick way to do this in numpy?


In [1]: M = ones((3,3))

In [2]: x = arange(3)

In [3]: M*x
Out[3]:
array([[ 0.,  1.,  2.],
   [ 0.,  1.,  2.],
   [ 0.,  1.,  2.]])

In [4]: x[:,newaxis]*M
Out[4]:
array([[ 0.,  0.,  0.],
   [ 1.,  1.,  1.],
   [ 2.,  2.,  2.]])

 Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Few minor issues with numscons

2009-02-03 Thread David Cournapeau

Hi Brian,

On Wed, Feb 4, 2009 at 9:00 AM, Brian Granger ellisonbg@gmail.com wrote:
 David,

 I am trying to use numscons to build a project and am running into
 some problems:

 Two smaller issues and one show stopper.  First, the smaller ones:

 * The web presense of numscons is currently very confusing.  There are
 a couple of locations with info about it, but the most prominent ones
 appear to be quite outdated:

 http://projects.scipy.org/scipy/numpy/wiki/NumScons

 ...refers to...

 https://code.launchpad.net/numpy.scons.support

 Which is no longer being used and doesn't have any links to the most
 recent versions  I had to hunt for a while to find the develoment
 repo, which is on github and the most recent release, which is now at
 pypi.

The releases are on Pypi for quite some time. I converted the repo to
git and put it on github, but I have not really worked on numscons for
several months now for lack of time ( and because numscons it mostly
done and the main limitations of numscons are not fixable without
fixing some fairly major scons limitations).

Basically, the repo on github is only the convertion from bzr, without
any new features.

 It is probably a good idea to update these locations so as not to
 confuse new folks (or old folks too).

 * The scons/scons-local subdir is not installed when running python
 setup.py install.  I had to use python setupegg.py to get this to
 install in the right place.

That's strange, you are not the first one to mention this bug, but I
never had this problem myself - I myself never use setupegg except
when creating eggs for pypi.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Few minor issues with numscons

 The releases are on Pypi for quite some time. I converted the repo to
 git and put it on github, but I have not really worked on numscons for
 several months now for lack of time ( and because numscons it mostly
 done and the main limitations of numscons are not fixable without
 fixing some fairly major scons limitations).

 Basically, the repo on github is only the convertion from bzr, without
 any new features.

Do you have plans to continue to maintain it though?

One other things I forgot to mention.  I first tried the head of your
git repo and numpy complained that the version of numscons (0.10) was
too *old*.  It wanted the version to be greater than somehting like
0.9.1, and clearly it was, so it looks like there is a bug in the
numscons version parsing in numpy.distutils.

 * The scons/scons-local subdir is not installed when running python
 setup.py install.  I had to use python setupegg.py to get this to
 install in the right place.

 That's strange, you are not the first one to mention this bug, but I
 never had this problem myself - I myself never use setupegg except
 when creating eggs for pypi.

OK, I will have a look at this further to see what the cause is.

Thanks for a great package that solve a really painful set of issues!

Brian

 cheers,

 David
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://projects.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numscons/numpy.distutils bug related to MACOSX_DEPLOYMENT_TARGET

 1) Trust the environment variable if given and let distutils raise its
 error message (why not raise it ourselves? distutils' error message
 and explanation is already out in THE GOOGLE.)

 2) Otherwise, use the value in the Makefile if it's there.

 3) If it's not even in the Makefile for whatever reason, go with 10.3.

Sounds good, do you want to me work up a patch?

Brian

 --
 Robert Kern

 I have come to believe that the whole world is an enigma, a harmless
 enigma that is made terrible by our own mad attempt to interpret it as
 though it had an underlying truth.
  -- Umberto Eco
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://projects.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numscons/numpy.distutils bug related to MACOSX_DEPLOYMENT_TARGET