FYI, I uploaded the two files in question to the numpy ticket
http://projects.scipy.org/numpy/ticket/1284
Thanks!
On Wed, Nov 4, 2009 at 3:56 PM, Bruce Southey wrote:
> On Wed, Nov 4, 2009 at 8:06 AM, Reckoner wrote:
>> Here's an example:
>>
>> On winxp 64-bit:
>>
>> Python 2.5.2 (r252:60
Bruce :
The file in question was created as shown in the prior e-mail. Here it is again:
>> cPickle.dump(a,open('from32bitxp.pkl','w'))
Thanks!
On Wed, Nov 4, 2009 at 3:56 PM, Bruce Southey wrote:
> On Wed, Nov 4, 2009 at 8:06 AM, Reckoner wrote:
>> Here's an example:
>>
>> On winxp 64-bit:
On Thu, Nov 5, 2009 at 4:55 AM, Michael Droettboom wrote:
> David Cournapeau wrote:
>> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom wrote:
>>
>>> I'm getting the following from r7603 on Solaris Sparc -- somehow related
>>> to not having a long double version of next after available. I real
On Wed, Nov 4, 2009 at 8:06 AM, Reckoner wrote:
> Here's an example:
>
> On winxp 64-bit:
>
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
> on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
import numpy
import cPickle
>>
gmail.com> writes:
> > Good point. With the return_inverse solution, is unique() guaranteed
> > to give back the same array of unique values in the same (presumably
> > sorted) order? That is, for two arrays A and B which have elements
> > only drawn from a set S, is all(unique(A) == unique(B))
On Wed, Nov 4, 2009 at 3:57 PM, David Warde-Farley wrote:
> Thanks Alan and Robert, I probably should have mentioned that I was
> interested in obtaining the corresponding integer for each value in
> the array d, in which case the dictionary bit works but would require
> a further loop to expand.
Thanks Alan and Robert, I probably should have mentioned that I was
interested in obtaining the corresponding integer for each value in
the array d, in which case the dictionary bit works but would require
a further loop to expand.
On 4-Nov-09, at 3:22 PM, Robert Kern wrote:
> I'd toss in a
On Wed, Nov 4, 2009 at 14:21, Alan G Isaac wrote:
> On 11/4/2009 3:09 PM, David Warde-Farley wrote:
>> I'd like to map every unique element (these could be strings, objects,
>> or already ints) to a unique integer between 0 and len(unique(d)) - 1.
>
> mymap = dict((k,v) for v,k in enumerate(set(a)
On 4-Nov-09, at 3:09 PM, David Warde-Farley wrote:
> But I wonder if there's a better way to do this. Anyone ever run into
> this problem before?
Obviously I find the answer right after I hit "send". unique(d,
return_inverse=True).
Sorry for the noise.
David
__
On 11/4/2009 3:09 PM, David Warde-Farley wrote:
> I'd like to map every unique element (these could be strings, objects,
> or already ints) to a unique integer between 0 and len(unique(d)) - 1.
mymap = dict((k,v) for v,k in enumerate(set(a)))
fwiw,
Alan Isaac
Hi,
Suppose I have an array 'd'
In [75]: d
Out[75]:
array(['parrot', 'parrot', 'dog', 'cat', 'parrot', 'dog', 'parrot',
'cat',
'dog', 'dog', 'dog', 'cat', 'cat', 'dog', 'cat', 'parrot',
'cat',
'cat', 'dog', 'parrot', 'parrot', 'parrot', 'cat', 'dog',
'parrot',
'dog',
David Cournapeau wrote:
> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom wrote:
>
>> I'm getting the following from r7603 on Solaris Sparc -- somehow related
>> to not having a long double version of next after available. I realise
>> not everyone has access to (or is dependent on) this pl
On Wed, Nov 4, 2009 at 12:38 PM, Charles R Harris wrote:
>
>
> On Wed, Nov 4, 2009 at 12:35 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Wed, Nov 4, 2009 at 12:11 PM, David Cournapeau wrote:
>>
>>> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom
>>> wrote:
>>> > I'
On Wed, Nov 4, 2009 at 12:35 PM, Charles R Harris wrote:
>
>
> On Wed, Nov 4, 2009 at 12:11 PM, David Cournapeau wrote:
>
>> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom
>> wrote:
>> > I'm getting the following from r7603 on Solaris Sparc -- somehow related
>> > to not having a long double
On Wed, Nov 4, 2009 at 12:11 PM, David Cournapeau wrote:
> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom
> wrote:
> > I'm getting the following from r7603 on Solaris Sparc -- somehow related
> > to not having a long double version of next after available. I realise
> > not everyone has acce
Pierre GM-2 wrote:
>
> Confirmed, it's a bug all right. Would you mind opening a ticket ?
> I'll try to take care of that in the next few days.
>
Done - http://projects.scipy.org/numpy/ticket/1283
Thanks!
Thomas
--
View this message in context:
http://old.nabble.com/Automatic-string-len
On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom wrote:
> I'm getting the following from r7603 on Solaris Sparc -- somehow related
> to not having a long double version of next after available. I realise
> not everyone has access to (or is dependent on) this platform, so I'm
> willing to help i
On Nov 4, 2009, at 11:35 AM, Thomas Robitaille wrote:
>
>
> Pierre GM-2 wrote:
>>
>> As a workwaround, perhaps you could use np.object instead of np.str
>> while defining your array. You can then get the maximum string length
>> by looping, as David suggested, and then use .astype to transform
2009/11/4 Robin :
> On Wed, Nov 4, 2009 at 2:38 PM, George Nurser wrote:
>> Fortran can accept preprocessor directives, but f2py cannot.
>> You first need to preprocess a .F (or .F90) file to create a .f (or
>> .f90) file which you then pass to f2py
>> The way I preprocess the .F file is to have s
On 2009-11-03 20:18 , Brennan Williams wrote:
> ok I took a closer look at FortranFile and I'm now doing the following.
> Note that the first line in the file I'm reading
> has two double precision reals/floats followed by 8 32 bit integers.
>
>f=FortranFile(fullfilename,endian='<')
>
On Tue, Nov 3, 2009 at 11:43 AM, David Warde-Farley wrote:
> On 2-Nov-09, at 11:35 PM, Thomas Robitaille wrote:
>
> > But if I want to specify the data types:
> >
> > np.rec.fromrecords([(1,'hello'),(2,'world')],dtype=[('a',np.int8),
> > ('b',np.str)])
> >
> > the string field is set to a length o
I'm getting the following from r7603 on Solaris Sparc -- somehow related
to not having a long double version of next after available. I realise
not everyone has access to (or is dependent on) this platform, so I'm
willing to help in whatever way I can, I'm just not sure I understand
the change
thanks to everybody
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Pierre GM-2 wrote:
>
> As a workwaround, perhaps you could use np.object instead of np.str
> while defining your array. You can then get the maximum string length
> by looping, as David suggested, and then use .astype to transform your
> array...
>
I tried this:
np.rec.fromrecords([(1,'
The difference between IDL and numpy is that IDL uses single precision
floats by default while numpy uses doubles. If you try it with
doubles in IDL, you will see that it also returns false.
As David Cournapeau said, you should not expect different floating
point arithmetic operations to gi
Thanks for your reply.
No. I just tried it with the latest Windows XP 32-bit version
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.__version__
'1.3.0'
Same re
On Wed, Nov 4, 2009 at 2:38 PM, George Nurser wrote:
> Fortran can accept preprocessor directives, but f2py cannot.
> You first need to preprocess a .F (or .F90) file to create a .f (or
> .f90) file which you then pass to f2py
> The way I preprocess the .F file is to have statements like
> int int
On Wed, Nov 4, 2009 at 7:06 AM, Reckoner wrote:
> Here's an example:
>
> On winxp 64-bit:
>
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
> (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy
> >>> import cPickle
On Wed, Nov 4, 2009 at 11:52 PM, Jean-Luc Menut wrote:
> Hello all,
>
>
>
> If if define 2 variables a and b by doing the following :
>
> on [5]: a
> Out[5]: array([ 1.7])
>
> In [6]: b=array([0.8])+array([0.9])
>
> In [7]: b
> Out[7]: array([ 1.7])
>
>
> if I test the equality of a and b, instead
Received from Jean-Luc Menut on Wed, Nov 04, 2009 at 09:52:15AM EST:
> Hello all,
>
>
>
> If if define 2 variables a and b by doing the following :
>
> on [5]: a
> Out[5]: array([ 1.7])
>
> In [6]: b=array([0.8])+array([0.9])
>
> In [7]: b
> Out[7]: array([ 1.7])
>
>
> if I test the equalit
Hello all,
If if define 2 variables a and b by doing the following :
on [5]: a
Out[5]: array([ 1.7])
In [6]: b=array([0.8])+array([0.9])
In [7]: b
Out[7]: array([ 1.7])
if I test the equality of a and b, instead to obatin True, I have :
In [8]: a==b
Out[8]: array([False], dtype=bool)
I kno
Fortran can accept preprocessor directives, but f2py cannot.
You first need to preprocess a .F (or .F90) file to create a .f (or
.f90) file which you then pass to f2py
The way I preprocess the .F file is to have statements like
int int*INTSIZE :: i,j,k
So preprocess file.F e.g. in gfortran with
gf
Here's an example:
On winxp 64-bit:
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> import cPickle
>>> a = numpy.eye(10)
>>> cPickle.dump(a,open('from32bitxp.pkl','w')
2009/11/3 Robin :
> On Tue, Nov 3, 2009 at 6:14 PM, Robin wrote:
>> After some more pootling about I figured out a lot of the performance
>> loss comes from using 32 bit integers by default when compiles 64 bit.
>> I asked this question on stackoverflow:
>> http://stackoverflow.com/questions/16688
Hi David,
On 4-Nov-09, at 4:23 AM, David Cournapeau wrote:
> Did you compile them without any optimized as suggested in the
> makefiles ? NOOPT should not contain -O option
Yup, it contained -O0 -fPIC (-O0 I think is in fact more strict than
having no -O option?). Have you seen this problem wi
On Wed, Nov 4, 2009 at 1:37 AM, Ralf Gommers
wrote:
> It would be good if we could also have one more merge of the work in the doc
> editor (close to 300 new/changed docstrings now). I can have it all reviewed
> by the 13th.
That would be great. Thanks for taking care of that.
> Unless you obje
On Mon, Nov 2, 2009 at 9:29 AM, David Cournapeau wrote:
> Hi,
>
> I think it is about time to release 1.4.0. Instead of proposing a
> release date, I am setting a firm date for 1st December, and 16th
> november to freeze the trunk. If someone wants a different date, you
> have to speak now.
>
> T
On Wed, Nov 4, 2009 at 2:55 PM, David Warde-Farley wrote:
> Hi all (mostly David C. since he probably knows all this horrible
> stuff),
>
> I noticed on my new laptop (with an Atom N280 in it) that when I run
> numpy.test() about the 34th test would loop, seemingly forever.
>
> Finding this a litt
38 matches
Mail list logo