On Mon, 22 Feb 2010 22:18:23 +0900
David Cournapeau courn...@gmail.com wrote:
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner
nwag...@iam.uni-stuttgart.de wrote:
ar x test.a
gfortran -shared *.o -o libtest.so -lg2c
to build a shared library. The additional option -lg2c
was
necessary due
This behavior does not match the current documentation.
np.random.uniform(low=0.5,high=0.5)
0.5
np.random.uniform(low=0.5,high=0.4)
0.48796883601707464
I assume this behavior is intentional and it is
the documentation that is in error (for the case
when high=low)?
fwiw,
Alan Isaac
hello,
first of all, as i'm new here, i would like to greet everyone in the list and
thank the developers of numpy/scipy. i'm transitioning my work from matlab to
python and this software is very helpfull indeed.
the reason i'm writing is that i got to a stumbling block last week. i tried
==
SciPy 2010 Call for Papers
==
SciPy 2010, the 9th Python in Science Conference, will be held from
June 28th - July 3rd, 2010 in Austin, Texas.
At this conference, novel applications and breakthroughs made in the
pursuit of science using Python
On Tue, Feb 23, 2010 at 6:21 AM, Alan G Isaac ais...@american.edu wrote:
This behavior does not match the current documentation.
np.random.uniform(low=0.5,high=0.5)
0.5
np.random.uniform(low=0.5,high=0.4)
0.48796883601707464
I assume this behavior is intentional and it is
Why do you
On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote:
This behavior does not match the current documentation.
np.random.uniform(low=0.5,high=0.5)
0.5
np.random.uniform(low=0.5,high=0.4)
0.48796883601707464
I assume this behavior is intentional and it is
the documentation
On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote:
This behavior does not match the current documentation.
np.random.uniform(low=0.5,high=0.5)
0.5
np.random.uniform(low=0.5,high=0.4)
Hi-
I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will
not install; it appears something has changed within distutils that
breaks it:
$ export MACOSX_DEPLOYMENT_TARGET=10.6
$ export CFLAGS=-arch x86_64
$ export FFLAGS=-m64
$ export LDFLAGS=-Wall -undefined dynamic_lookup -bundle
On Tue, Feb 23, 2010 at 13:05, David Goldsmith d.l.goldsm...@gmail.com wrote:
On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote:
This behavior does not match the current documentation.
On 02/23/2010 01:18 PM, Tom Loredo wrote:
Hi-
I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will
not install; it appears something has changed within distutils that
breaks it:
$ export MACOSX_DEPLOYMENT_TARGET=10.6
$ export CFLAGS=-arch x86_64
$ export FFLAGS=-m64
$
On Tue, Feb 23, 2010 at 11:25 AM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Feb 23, 2010 at 13:05, David Goldsmith d.l.goldsm...@gmail.com
wrote:
On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com
wrote:
On Tue, Feb 23, 2010 at 08:21, Alan G Isaac
Hi all,
After getting the answers above on the maillist I palyed a bit more
with building numpy.
However without success.
Nevertheless I've found the way to install it using unladen-swallow itself :)
Why not rewriting the definition of uniform() to:
def uniform(start, stop, low = None, high = None):
if low is not None:
start = low
if high is not None:
stop = high
[and here what matters]
This makes no trouble when a user uses either non-keyword or keyword
On Tue, Feb 23, 2010 at 13:32, Bruce Southey bsout...@gmail.com wrote:
On 02/23/2010 01:18 PM, Tom Loredo wrote:
Hi-
I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will
not install; it appears something has changed within distutils that
breaks it:
$ export
On Tue, Feb 23, 2010 at 14:04, Friedrich Romstedt
friedrichromst...@gmail.com wrote:
Why not rewriting the definition of uniform() to:
def uniform(start, stop, low = None, high = None):
if low is not None:
start = low
if high is not None:
stop = high
[and here what
Except for someone calling uniform(low, high, size).
Ah, sorry, I didn't know about that. In that case, everything I wrote
is superfluous and I apologise for a non-helping comment.
But, one could incorporate SIZE simply in the calling convention.
In any case, why
would you make this change?
On Tue, Feb 23, 2010 at 14:26, Friedrich Romstedt
friedrichromst...@gmail.com wrote:
In any case, why
would you make this change? It doesn't seem to solve any problem or
clear up any semantics. start and stop imply a stop start
relationship, too, albeit not as strongly.
Hmm, I thought that
2010/2/23 Robert Kern robert.k...@gmail.com:
It helps a little, I agree, but not as much as simply changing the
names to something neutral like (a, b) as in the standard library. The
necessity for a backwards compatibility hack imposes additional costs
to making any such change. I don't think
On Tue, Feb 23, 2010 at 14:51, Friedrich Romstedt
friedrichromst...@gmail.com wrote:
2010/2/23 Robert Kern robert.k...@gmail.com:
It helps a little, I agree, but not as much as simply changing the
names to something neutral like (a, b) as in the standard library. The
necessity for a backwards
2010/2/23 Robert Kern robert.k...@gmail.com:
No worries! I'm not trying to discourage you from posting half-baked
thoughts. They're often correct!
Thank you :-) *smiling and laughing* !
Friedrich
P.S.: But my reply obviously does no longer belong to the mailing list ...
On Tue, Feb 23, 2010 at 1:02 PM, Friedrich Romstedt
friedrichromst...@gmail.com wrote:
2010/2/23 Robert Kern robert.k...@gmail.com:
No worries! I'm not trying to discourage you from posting half-baked
thoughts. They're often correct!
Thank you :-) *smiling and laughing* !
Friedrich
Incidentally, I noted the following in the discussion, but since those don't
get as much viewership (and since I'm about to edit the docstring anyway):
presently, the Example in uniform's docstring generates a plot using
matplotlib.pyplot - is generating a plot really consistent w/ the spirit of
OK, fixed in Wiki. ( OK to apply set to Yes)
DG
On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote:
This behavior does not match the current documentation.
np.random.uniform(low=0.5,high=0.5)
On Feb 23, 2010, at 1:03 AM, Charles R Harris wrote:
On Mon, Feb 22, 2010 at 2:06 PM, Pauli Virtanen p...@iki.fi wrote:
ma, 2010-02-22 kello 14:01 -0700, Charles R Harris kirjoitti:
On Mon, Feb 22, 2010 at 1:58 PM, Robert Kern robert.k...@gmail.com
wrote:
[clip]
Why? PyCObjects don't
On Tue, Feb 23, 2010 at 13:18, Tom Loredo lor...@astro.cornell.edu wrote:
Hi-
I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will
not install; it appears something has changed within distutils that
breaks it:
File
On Tue, Feb 23, 2010 at 3:40 PM, Travis Oliphant oliph...@enthought.comwrote:
On Feb 23, 2010, at 1:03 AM, Charles R Harris wrote:
On Mon, Feb 22, 2010 at 2:06 PM, Pauli Virtanen p...@iki.fi wrote:
ma, 2010-02-22 kello 14:01 -0700, Charles R Harris kirjoitti:
On Mon, Feb 22, 2010 at
On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
Hi David, did you find time to put those Atlas binaries somewhere?
I am putting them into numpy subversion as we speak (in vendor:
http://svn.scipy.org/svn/numpy/vendor).
cheers,
David
On Tue, Feb 23, 2010 at 4:47 PM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Feb 23, 2010 at 13:18, Tom Loredo lor...@astro.cornell.edu wrote:
Hi-
I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will
not install; it appears something has changed within distutils that
Does anyone use/build this stuff on RHEL 5.3+ (x64)? :) Seems not so much.
I'd like to use numpy (and PyTables) for a few tasks where it would be much
more efficient to have much of the processing performed on the servers
generating
the data (about 400 systems) than backhauling the huge
On Tue, Feb 23, 2010 at 8:52 PM, David Cournapeau courn...@gmail.com wrote:
On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
Hi David, did you find time to put those Atlas binaries somewhere?
I am putting them into numpy subversion as we speak (in vendor:
On Wed, Feb 24, 2010 at 11:05 AM, josef.p...@gmail.com wrote:
On Tue, Feb 23, 2010 at 8:52 PM, David Cournapeau courn...@gmail.com wrote:
On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
Hi David, did you find time to put those Atlas binaries somewhere?
I
On Wed, Feb 24, 2010 at 9:52 AM, David Cournapeau courn...@gmail.comwrote:
On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
Hi David, did you find time to put those Atlas binaries somewhere?
I am putting them into numpy subversion as we speak (in vendor:
On Wed, Feb 24, 2010 at 11:04 AM, David Carmean d...@halibut.com wrote:
Does anyone use/build this stuff on RHEL 5.3+ (x64)? :) Seems not so much.
I'd like to use numpy (and PyTables) for a few tasks where it would be much
more efficient to have much of the processing performed on the
Hi All,
I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I
check that f2py still works as advertised before making a commit?
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On Tue, Feb 23, 2010 at 21:14, Charles R Harris
charlesr.har...@gmail.com wrote:
Hi All,
I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I
check that f2py still works as advertised before making a commit?
numpy/f2py/tests/run_all.py
--
Robert Kern
I have come to
On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Feb 23, 2010 at 21:14, Charles R Harris
charlesr.har...@gmail.com wrote:
Hi All,
I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I
check that f2py still works as advertised before
On Tue, Feb 23, 2010 at 21:51, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Feb 23, 2010 at 21:14, Charles R Harris
charlesr.har...@gmail.com wrote:
Hi All,
I've made PyCObject - PyCapsule changes to
On Tue, Feb 23, 2010 at 22:12, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Feb 23, 2010 at 8:54 PM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Feb 23, 2010 at 21:51, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern
On Wed, Feb 10, 2010 at 3:12 PM, David Cournapeau courn...@gmail.com wrote:
Hi,
I am a bit puzzled by the protocol for long(a) where a is a scalar
array. For example, for a = np.float128(1), I was expecting long(a) to
call a.__long__, but it does not look like it is the case. int(a) does
not
On Tue, Feb 23, 2010 at 9:19 PM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Feb 23, 2010 at 22:12, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Feb 23, 2010 at 8:54 PM, Robert Kern robert.k...@gmail.com
wrote:
On Tue, Feb 23, 2010 at 21:51, Charles R Harris
On Wed, Feb 24, 2010 at 11:19 AM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Wed, Feb 24, 2010 at 9:52 AM, David Cournapeau courn...@gmail.com
wrote:
On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
Hi David, did you find time to put those
41 matches
Mail list logo
