On Wed, Feb 24, 2010 at 11:19 AM, Ralf Gommers
wrote:
>
>
> On Wed, Feb 24, 2010 at 9:52 AM, David Cournapeau
> wrote:
>>
>> On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers
>> wrote:
>> >
>> >>
>> > Hi David, did you find time to put those Atlas binaries somewhere?
>>
>> I am putting them into nu
On Tue, Feb 23, 2010 at 9:19 PM, Robert Kern wrote:
> On Tue, Feb 23, 2010 at 22:12, Charles R Harris
> wrote:
> >
> > On Tue, Feb 23, 2010 at 8:54 PM, Robert Kern
> wrote:
> >>
> >> On Tue, Feb 23, 2010 at 21:51, Charles R Harris
> >> wrote:
> >> >
> >> > On Tue, Feb 23, 2010 at 8:31 PM, Robe
On Wed, Feb 10, 2010 at 3:12 PM, David Cournapeau 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 call a.__int
On Tue, Feb 23, 2010 at 22:12, Charles R Harris
wrote:
>
> On Tue, Feb 23, 2010 at 8:54 PM, Robert Kern wrote:
>>
>> On Tue, Feb 23, 2010 at 21:51, Charles R Harris
>> wrote:
>> >
>> > On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern
>> > wrote:
>> >>
>> >> On Tue, Feb 23, 2010 at 21:14, Charles R
On Tue, Feb 23, 2010 at 8:54 PM, Robert Kern wrote:
> On Tue, Feb 23, 2010 at 21:51, Charles R Harris
> wrote:
> >
> > On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern
> wrote:
> >>
> >> On Tue, Feb 23, 2010 at 21:14, Charles R Harris
> >> wrote:
> >> > Hi All,
> >> >
> >> > I've made PyCObject ->
On Tue, Feb 23, 2010 at 21:51, Charles R Harris
wrote:
>
> On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern wrote:
>>
>> On Tue, Feb 23, 2010 at 21:14, Charles R Harris
>> wrote:
>> > Hi All,
>> >
>> > I've made PyCObject -> PyCapsule changes to f2py for python3.1. How can
>> > I
>> > check that f2p
On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern wrote:
> On Tue, Feb 23, 2010 at 21:14, Charles R Harris
> 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/
On Tue, Feb 23, 2010 at 21:14, Charles R Harris
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 believe that the whole w
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
http://mail.scipy.org/mailman/listinfo
On Wed, Feb 24, 2010 at 11:04 AM, David Carmean 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 servers
> gene
On Wed, Feb 24, 2010 at 9:52 AM, David Cournapeau wrote:
> On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers
> 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/v
On Wed, Feb 24, 2010 at 11:05 AM, wrote:
> On Tue, Feb 23, 2010 at 8:52 PM, David Cournapeau wrote:
>> On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers
>> wrote:
>>>
>>> Hi David, did you find time to put those Atlas binaries somewhere?
>>
>> I am putting them into numpy subversion as we spe
On Tue, Feb 23, 2010 at 8:52 PM, David Cournapeau wrote:
> On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers
> 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/vend
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 amo
On Tue, Feb 23, 2010 at 4:47 PM, Robert Kern wrote:
> On Tue, Feb 23, 2010 at 13:18, 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:
>> File
>> "/Volumes/Sys
On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers
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
___
N
On Tue, Feb 23, 2010 at 3:40 PM, Travis Oliphant wrote:
>
> On Feb 23, 2010, at 1:03 AM, Charles R Harris wrote:
>
>
>
> On Mon, Feb 22, 2010 at 2:06 PM, Pauli Virtanen wrote:
>
>> ma, 2010-02-22 kello 14:01 -0700, Charles R Harris kirjoitti:
>> > On Mon, Feb 22, 2010 at 1:58 PM, Robert Kern
>>
On Tue, Feb 23, 2010 at 13:18, 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:
> File
> "/Volumes/System/Users/loredo/Downloads/numpy-1.4.0-OSX/numpy/distutils/ccom
On Feb 23, 2010, at 1:03 AM, Charles R Harris wrote:
On Mon, Feb 22, 2010 at 2:06 PM, Pauli Virtanen wrote:
ma, 2010-02-22 kello 14:01 -0700, Charles R Harris kirjoitti:
> On Mon, Feb 22, 2010 at 1:58 PM, Robert Kern
> wrote:
[clip]
> > Why? PyCObjects don't serialize at all. They would ne
OK, fixed in Wiki. (& "OK to apply" set to "Yes")
DG
On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern wrote:
> On Tue, Feb 23, 2010 at 08:21, Alan G Isaac wrote:
> > This behavior does not match the current documentation.
> >
> np.random.uniform(low=0.5,high=0.5)
> > 0.5
> np.random.un
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
wa
On Tue, Feb 23, 2010 at 1:02 PM, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:
> 2010/2/23 Robert Kern :
> > 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 m
2010/2/23 Robert Kern :
> 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 14:51, Friedrich Romstedt
wrote:
> 2010/2/23 Robert Kern :
>> 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 cost
2010/2/23 Robert Kern :
> 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 those costs are wa
On Tue, Feb 23, 2010 at 14:26, Friedrich Romstedt
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 start is where
> 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:04, Friedrich Romstedt
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 matters]
>
> This mak
On Tue, Feb 23, 2010 at 13:32, Bruce Southey 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 MACOSX_DEPLOYMENT_TARG
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
specificat
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 :)
http://groups.google.com/group/unladen-swallow/browse_thread/thread/80f7ccb68a9dcea3#b01520275219
On Tue, Feb 23, 2010 at 11:25 AM, Robert Kern wrote:
> On Tue, Feb 23, 2010 at 13:05, David Goldsmith
> wrote:
> > On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern
> wrote:
> >>
> >> On Tue, Feb 23, 2010 at 08:21, Alan G Isaac
> 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="-m
On Tue, Feb 23, 2010 at 13:05, David Goldsmith wrote:
> On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern wrote:
>>
>> On Tue, Feb 23, 2010 at 08:21, Alan G Isaac wrote:
>> > This behavior does not match the current documentation.
>> >
>> np.random.uniform(low=0.5,high=0.5)
>> > 0.5
>> np.
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 -bu
On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern wrote:
> On Tue, Feb 23, 2010 at 08:21, Alan G Isaac 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
> >
> >
On Tue, Feb 23, 2010 at 08:21, Alan G Isaac 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 that
On Tue, Feb 23, 2010 at 6:21 AM, Alan G Isaac 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 assume
==
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 ar
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
wrot
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
_
On Mon, 22 Feb 2010 22:18:23 +0900
David Cournapeau wrote:
> On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner
> wrote:
>
>>
>> ar x test.a
>> gfortran -shared *.o -o libtest.so -lg2c
>>
>> to build a shared library. The additional option -lg2c
>>was
>> necessary due to an undefined symbol: s_cmp
42 matches
Mail list logo
