Johann Cohen-Tanugi wrote:
> On 10/20/2010 11:10 PM, Robert Kern wrote:
>
>> On Wed, Oct 20, 2010 at 15:58, Johann Cohen-Tanugi
>> wrote:
>>
>>
>>> On 10/20/2010 10:35 PM, Nathaniel Smith wrote:
>>>
>>>
>>
>>
IMPORTANT USAGE NOTE: never do this :-)
On Wed, Oct 20, 2010 at 1:32 AM, Lutz Maibaum wrote:
> On Oct 19, 2010, at 6:09 PM, Dewald Pieterse wrote:
> > for xiter in range(xindex):
> > for yiter in range(yindex):
> > if edges[xiter,yiter,:] == [255,0,0]:
> > groenpixelarea = groenpixelarea + 1
> >
It turns out that when comparing dtypes, the subarray is currently ignored.
This means you can get things like this:
>>> import numpy as np
>>> np.dtype(('f4',(6))) == np.dtype(('f4',(2,3)))
True
>>> np.dtype(([('a','i4')],2)) == np.dtype(([('b','u2'),('c','i2')],2))
True
which pretty clearly sh
On Wed, Oct 20, 2010 at 16:49, Zachary Pincus wrote:
> But why not have the user just pass in the relevant optObject from the
> pyOpt namespace (or some restricted namespace that just has the
> relevant functions exposed)? E.g.
> my_analysis.perform(optimizer=pyOpt.Amoeba)
> rather than
> my_anal
On Thu, Oct 21, 2010 at 12:56 AM, Friedrich Romstedt
wrote:
> 2010/10/20 Darren Dale :
>> On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt
>> wrote:
>>> Due to Darren's config file the .nsi.in file made it with CRLF into the
>>> repo.
>>
>> Uh, no.
>
> You mean I'm wrong?
Yes, the file has a
> Hi Robert,
> so in a big data analysis framework, that is essentially written in C
> ++,
> exposed to python with SWIG, plus dedicated python modules, the user
> performs an analysis choosing some given modules by name,as in :
> myOpt="foo"
> my_analyse.perform(use_optimizer=myOpt)
>
> The attri
On 10/20/2010 11:10 PM, Robert Kern wrote:
> On Wed, Oct 20, 2010 at 15:58, Johann Cohen-Tanugi
> wrote:
>
>> On 10/20/2010 10:35 PM, Nathaniel Smith wrote:
>>
>
>>> IMPORTANT USAGE NOTE: never do this :-)
>>>
>>>
>> What would you recommand? I do encounter situations where
On Wed, Oct 20, 2010 at 1:58 PM, Johann Cohen-Tanugi
wrote:
> On 10/20/2010 10:35 PM, Nathaniel Smith wrote:
>> The better way to do this is:
>>
>> import inspect
>> def call_this(fname, x):
>> caller_frame = inspect.currentframe().f_back
>> f = caller_frame.f_locals.get(fname, caller_frame.f_
On Wed, Oct 20, 2010 at 15:58, Johann Cohen-Tanugi wrote:
> On 10/20/2010 10:35 PM, Nathaniel Smith wrote:
>> IMPORTANT USAGE NOTE: never do this :-)
>>
> What would you recommand? I do encounter situations where I need
> instantiation based on the name of the thing to instantiate, typically
> pa
Wed, 20 Oct 2010 19:21:15 +0200, Nils Wagner wrote:
> test_duplicate_field_names_assign
> (test_regression.TestRegression) ...
Works for me. This is exactly the crash that the test tests, so perhaps
you have an incomplete rebuild. I'd try "rm -rf build" and rebuild.
--
Pauli Virtanen
_
On 10/20/2010 10:35 PM, Nathaniel Smith wrote:
> On Wed, Oct 20, 2010 at 6:51 AM, Johann Cohen-Tanugi
> wrote:
>
>> If you really need to pass the function name :
>> In [3]: def my_func(x):
>> ...: return 2*x
>>
>> In [4]: def caller(fname,x):
>> ...: return eval("%s(%f)"%(f
On Wed, Oct 20, 2010 at 6:51 AM, Johann Cohen-Tanugi
wrote:
> If you really need to pass the function name :
> In [3]: def my_func(x):
> ...: return 2*x
>
> In [4]: def caller(fname,x):
> ...: return eval("%s(%f)"%(fname,x))
>
> In [5]: caller("my_func",2)
> Out[5]: 4.0
The better w
On Wed, 2010-10-20 at 13:18 -0400, Alan G Isaac wrote:
> On 10/20/2010 9:42 AM, Thomas Kirk Gamble wrote:
> > I'm trying to write an implementation of the amoeba function from
> > numerical recipes and need to be able to pass a function name and
> > parameter list to be called from within the amoeb
.nsi.in has '$\n\r' Is this now LFCR or CRLF?
doall.py and py3tool.py have '$\n' precisely. I'm on Mac. \n is the
at least vim-default on Mac.
So yes, confirming that it's already in the repo.
What about the svg eols?
Do we need my branch now, or do we want to leave it alone? When
others ch
On Wed, Oct 20, 2010 at 11:56 AM, Friedrich Romstedt
wrote:
> 2010/10/20 Darren Dale :
>> On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt
>> wrote:
>>> Due to Darren's config file the .nsi.in file made it with CRLF into the
>>> repo.
>>
>> Uh, no.
>
> You mean I'm wrong?
Due to my config fi
On Mon, Oct 18, 2010 at 5:18 PM, Fernando Perez wrote:
> On Mon, Oct 18, 2010 at 11:21 AM, M Trumpis wrote:
>> Just a heads up that I'm going to do a quick pitch for datarray this
>> Wed. at the NYC Python Meetup thing.
>>
>> If any collaborator is attending, please introduce yourself!
>>
>
> Wel
test_duplicate_field_names_assign
(test_regression.TestRegression) ...
FF
Program received signal SIGSEGV, Segmentation fault.
0x77b3077a in ?? () from
/usr/lib64/libpython2.6.so.1.0
(gdb) bt
#0 0x77b3077a in ?? () from
/usr/lib64/libpython2.6.so.1.0
#1 0x0
On 10/20/2010 9:42 AM, Thomas Kirk Gamble wrote:
> I'm trying to write an implementation of the amoeba function from
> numerical recipes and need to be able to pass a function name and
> parameter list to be called from within the amoeba function.
1. Have you checked whether this might already be
==
Announcing Numexpr 1.4.1
==
Numexpr is a fast numerical expression evaluator for NumPy. With it,
expressions that operate on arrays (like "3*a+4*b") are accelerated
and use less memory than doing the same calculation in Python.
What's new
=
On Wed, Oct 20, 2010 at 9:56 AM, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:
> 2010/10/20 Darren Dale :
> > On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt
> > wrote:
> >> Due to Darren's config file the .nsi.in file made it with CRLF into the
> repo.
> >
> > Uh, no.
>
> You mean
On Wed, 2010-10-20 at 09:46 -0400, Zachary Pincus wrote:
> > I'm trying to write an implementation of the amoeba function from
> > numerical recipes and need to be able to pass a function name and
> > parameter list to be called from within the amoeba function. Simply
> > passing the name as a str
2010/10/20 Darren Dale :
> On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt
> wrote:
>> Due to Darren's config file the .nsi.in file made it with CRLF into the repo.
>
> Uh, no.
You mean I'm wrong? Wait, I'll check, but ...Hmm, how do I check the
line endings? `file` told it for the .nsi.in
There were two problems. First, numpy ignored my export
ATLAS=/usr/local/atlas. setup.py printed out the directories it was
searching and it just searched the defaults then said it couldn't find
ATLAS.
I 'fixed' that problem by adding symlinks in the default directories.
Now I get error messages l
On Wed, Oct 20, 2010 at 9:46 AM, Zachary Pincus wrote:
>> I'm trying to write an implementation of the amoeba function from
>> numerical recipes and need to be able to pass a function name and
>> parameter list to be called from within the amoeba function. Simply
>> passing the name as a string d
If you really need to pass the function name :
In [3]: def my_func(x):
...: return 2*x
In [4]: def caller(fname,x):
...: return eval("%s(%f)"%(fname,x))
In [5]: caller("my_func",2)
Out[5]: 4.0
On 10/20/2010 03:46 PM, Zachary Pincus wrote:
>> I'm trying to write an implementation
> I'm trying to write an implementation of the amoeba function from
> numerical recipes and need to be able to pass a function name and
> parameter list to be called from within the amoeba function. Simply
> passing the name as a string doesn't work since python doesn't know it
> is a function and
I'm trying to write an implementation of the amoeba function from
numerical recipes and need to be able to pass a function name and
parameter list to be called from within the amoeba function. Simply
passing the name as a string doesn't work since python doesn't know it
is a function and throws a
On Wed, Oct 20, 2010 at 09:13:24AM -0400, Ian Goodfellow wrote:
>--with-netlib-lapack is indeed no longer valid.
>INSTALL.txt includes a warning that INSTALL.txt is out of date, you should
>refer to doc/atlas_install.pdf instead.
Ah, I read too quickly and missed that. Thanks.
>Th
--with-netlib-lapack is indeed no longer valid.
INSTALL.txt includes a warning that INSTALL.txt is out of date, you should
refer to doc/atlas_install.pdf instead.
The new option is --with-netlib-lapack-tarfile
I successfully built 3.9.25 with this option a while ago, but haven't been
able to get nu
On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt
wrote:
> Due to Darren's config file the .nsi.in file made it with CRLF into the repo.
Uh, no.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-
2010/10/20 Charles R Harris :
> [...] I think we do need a
> .gitconfig file [...]
.gitattributes
> so why don't you go ahead and make one and
> deal with the nsi.in file in the process.
http://github.com/friedrichromstedt/numpy/tree/friedrich-gitattributes-nsis
> The .svg files can have their
Hi,
> It already has a ticket :)
>
> http://projects.scipy.org/numpy/ticket/1637
Oops - sorry - thanks for point that out.
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-dis
Wed, 20 Oct 2010 17:46:06 +0900, David Cournapeau wrote:
[clip]
> This should have been fixed when I implemented the hashing protocol for
> dtypes. This is a bug in the hashing protocol implementation, most
> likely caused by "=" and "<" being considered different by the hashing
> function. I will
On Wed, Oct 20, 2010 at 11:59:24AM +0300, Pearu Peterson wrote:
> I haven't build atlas libraries for awhile and may be something
> is changed in atlas.. That said, I would try instructions from
> http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063cceee2cc6313c
That was m
On 10/20/2010 11:48 AM, Gael Varoquaux wrote:
> On Wed, Oct 20, 2010 at 04:41:38PM +0900, David wrote:
>>> - ldd /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: does it
>>> load the libraries you think are you loading ?
>
> For the dynamic libraries, it seems so. I am using static l
On Wed, Oct 20, 2010 at 04:41:38PM +0900, David wrote:
> > - ldd /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: does it
> > load the libraries you think are you loading ?
For the dynamic libraries, it seems so. I am using static libraries for
atlas/blas (.a)
> > - nm atlas_libr
On Wed, Oct 20, 2010 at 09:43:12AM +0200, Gael Varoquaux wrote:
> On Wed, Oct 20, 2010 at 09:38:25AM +0200, Gael Varoquaux wrote:
> > Hum, this page is mentionning a '--with-netlib-lapack' swith the the
> > configre that is not in the INSTALL.txt of my atlas version.
> OK, that's no longer valid.
On Wed, Oct 20, 2010 at 5:08 PM, Matthew Brett wrote:
> Hi,
>
> I have just run into this oddness:
>
> In [28]: dt1 = np.dtype('f4')
>
> In [29]: dt1.str
> Out[29]: '
> In [30]: dt2 = dt1.newbyteorder('<')
>
> In [31]: dt2.str
> Out[31]: '
> In [32]: dt1 == dt2
> Out[32]: True
>
> In [33]: hash(dt
Hi,
I have just run into this oddness:
In [28]: dt1 = np.dtype('f4')
In [29]: dt1.str
Out[29]: 'http://www.mail-archive.com/numpy-discussion@scipy.org/msg13299.html
My question was - does the team still agree this is a bug? Can anyone
offer a pointer as to how it should be fixed?
Best,
Matth
On Wed, Oct 20, 2010 at 09:38:25AM +0200, Gael Varoquaux wrote:
> Hum, this page is mentionning a '--with-netlib-lapack' swith the the
> configre that is not in the INSTALL.txt of my atlas version.
OK, that's no longer valid.
However, I just realize that atlas now packages the netlib lapack in t
On 10/20/2010 04:39 PM, David wrote:
> On 10/20/2010 04:23 PM, Gael Varoquaux wrote:
>> I am really sorry to be landing on the mailing list with Atlas build
>> issues. I usually manage be myself to build Atlas, but this time I have
>> been fighting for a couple of days with little success.
>>
>> Th
On 10/20/2010 04:23 PM, Gael Varoquaux wrote:
> I am really sorry to be landing on the mailing list with Atlas build
> issues. I usually manage be myself to build Atlas, but this time I have
> been fighting for a couple of days with little success.
>
> The reason I need to build Atlas is that our w
On Wed, Oct 20, 2010 at 10:32:48AM +0300, Pearu Peterson wrote:
> I could not read the stdout
Because I forgot to attach it! I added it
>but perhaps you didn't build atlas with complete lapack.
That's quite possible. The size of liblapack.a seems a bit too small
(1.1M). On the system for which i
On 10/20/2010 10:23 AM, Gael Varoquaux wrote:
> I am really sorry to be landing on the mailing list with Atlas build
> issues. I usually manage be myself to build Atlas, but this time I have
> been fighting for a couple of days with little success.
>
> The reason I need to build Atlas is that our
I am really sorry to be landing on the mailing list with Atlas build
issues. I usually manage be myself to build Atlas, but this time I have
been fighting for a couple of days with little success.
The reason I need to build Atlas is that our work computers are stuck on
Mandriva 2008.0, in which th
45 matches
Mail list logo
