On Mon, 18 May 2009 05:37:09 -0700 (PDT), Cristi Constantin wrote:
> Good day.
> I am working on this algorithm for a few weeks now, so i tried almost
> everything...
> I want to overlap / overwrite 2 matrices, but completely ignore some values
> (in this case ignore 0)
> Let me explain:
>
> a =
fid = open( 'file' , 'w' )
fid.write( 'header\n' )
savetxt( fid , data )
fid.close()
On Sun, 17 May 2009 18:54:33 -0500 Gökhan SEVER wrote:
> Hello,
>
> Is there a way to write a header information to a text file using savetxt
> command besides dumping arrays in the same file?
>
> In little det
On Mon, 27 Apr 2009 17:04:17 -0400, Michael S. Gilbert wrote:
> I had mentioned recently some interest in using fractions in the numpy
> polynomial class. Suprisingly, it actually works for the most part out
> of the box, which is great. However, there are some minor issues. For
I had mentioned recently some interest in using fractions in the numpy
polynomial class. Suprisingly, it actually works for the most part out
of the box, which is great. However, there are some minor issues. For
example:
numpy.poly1d( [ fractions.Fraction(1,2) , fractions.Fraction(1,8) ]
>>
Hello,
I've been working with numpy's poly1d class recently, and it would be
very useful to me if the class worked with fractions instead of
floats (since I'm encountering quantities that often mostly cancel out,
which lead to instabilities in my algorithms; hence it would be
useful to use fractio
On Tue, 10 Mar 2009 17:21:23 +0100, Mark Bakker wrote:
> Hello,
>
> I want to convert an array to a string.
>
> I like array2string, but it puts these annoying square brackets around
> the array, like
>
> [[1 2 3],
> [3 4 5]]
>
> Anyway we can suppress the square brackets and get (this is what
On Tue, 10 Mar 2009 16:05:06 +0100, Mark Bakker wrote:
> Thanks, Mike.
> This seems to be a really easy way.
> One more question.
> It turns out my file also contains a character string of 16 characters.
> I tried
> np.fromfile(fd,np.str,16)
> But that gives an error.
> Can I read a characterstrin
On Mon, 9 Mar 2009 21:45:42 +0100, Mark Bakker wrote:
> Hello -
>
> I tried to figure this out from the list, but haven't succeeded yet.
>
> I have a simple FORTRAN binary file.
> It contains:
> 1 integer
> 1 float
> 1 array with 16 numbers (float)
>
> How do I read these into Python?
I figure
On Mon, 2 Mar 2009 15:37:33 -0500, Gideon Simpson wrote:
> My two questions are:
>
> 1. What is the best way to handle this? Is it just to add a filter
> of the form
>
> u = u * ( np.abs(u) > 2.3 e-308)
>
> 2. What gives? What's the origin of this (perceived) inconsistency
> in flo
On Sun, 1 Mar 2009 14:29:54 -0500, Michael Gilbert wrote:
> i will send the current version to the list tomorrow when i have access
> to the system that it is on.
attached is my current version of loadtxt. like i said, it's slower
for small data sets (because it reads through the whole data file
On Fri, 13 Feb 2009 17:04:48 +0100 Sturla Molden wrote:
> So you have a simulation written in *Python*, and the major bottleneck
> is the MT prng? Forgive me for not believing it.
Yes, running a lot of monte carlo simulations back-to-back. if the
PRNG were twice as fast, my code would be twice a
On Fri, 13 Feb 2009 16:25:37 +0100 Sturla Molden wrote:
> Honestly, I don't care about 2x differences here. How many milliseconds
> do you save?
It's not about saving milliseconds, it's about taking half the time to
run the same simulation. So if my runs currently take 2 hours, they
will take 1
On Fri, 13 Feb 2009 12:54:10 +0100 Sturla Molden wrote:
> If you are that obsessed with speed, consider to use the new SIMD
> version of the Mersenne Twister instead of Jean-Sebastien Roy's
> randomkit.c (used by NumPy). But I think randomkit.c is fast enough for
> most purposes.
>
> http://www
On Thu, 12 Feb 2009 14:32:02 -0600 Robert Kern wrote:
>> You could also think of it the other way (in terms of generating 64-bit
>> ints). Instead of generating two 32-bit rints and concatenating them
>> for a 64-bit int, you can just directly generate the 64-bit int. Since
>> the 64-bit int requir
On Thu, 12 Feb 2009 13:18:26 -0600 Robert Kern wrote:
> > I did some testing with this 64-bit implementation (mt19937-64). I've
> > found that it is actually slower than the 32-bit reference (mt19937ar)
> > on 64-bit systems (2.15s vs 2.25s to generate 1 ints). This is
> > likely because it
On Fri, 6 Feb 2009 18:18:44 -0500 "Michael S. Gilbert" wrote:
> BTW, there is a 64-bit version of the reference mersenne twister
> implementation available [1].
I did some testing with this 64-bit implementation (mt19937-64). I've
found that it is actually slower than
> I'm not going to modify the upstream source and risk introducing bugs.
BTW, there is a 64-bit version of the reference mersenne twister
implementation available [1].
Mike
[1] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/mt19937-64.c
_
> I'm not going to modify the upstream source and risk introducing bugs.
I agree, its not worth risking it to save 2k of memory.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
ly talking about
the difference between 2kB and 4kB, which is fairly insignificant.
Mike
On Fri, 6 Feb 2009 15:25:35 -0600
Robert Kern wrote:
> On Fri, Feb 6, 2009 at 15:24, Michael S. Gilbert
> wrote:
> > In numpy/random/mtrand/randomkit.c on line 159, the initial mersenne
> >
In numpy/random/mtrand/randomkit.c on line 159, the initial mersenne twister
key (populated from /dev/urandom) gets bit-wise and'ed with 0x. I'm
just curious as why this is done. A bit-wise and with all ones should just
give you your original quantity back, right? I don't think there
20 matches
Mail list logo
