Hi,
I'm trying to compile numpy with 64 bits support under
Sparc/Solaris 8. I've already compiled Python 2.5.1 with 64
bits. I've set up my environnement with :
export CC=gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1
export CXX=g++ -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1
export LDFLAGS='-mcpu=v9
Langella Raphael wrote:
Hi,
I'm trying to compile numpy with 64 bits support under
Sparc/Solaris 8. I've already compiled Python 2.5.1 with 64
bits. I've set up my environnement with :
export CC=gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1
export CXX=g++ -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1
Hi everyone,
This was reported yesterday as a bug in Debian's numpy package:
len(numpy.arange(0, 0.6, 0.1)) == len(numpy.arange(0, 0.4+0.2, 0.1))
False
The cause is this:
ceil((0.4+0.2)/0.1)
7.0
ceil(0.6/0.1)
6.0
which holds for both numpy's and the standard library's ceil().
Using
this is really annoying.
Matlab handles the ceil weirdness quite well, though.
--
ceil(0.6/0.1)
ans =
6
ceil((0.4+0.2)/0.1)
ans =
7
0:0.1:0.6
ans =
01.000e-001
Might using
min(ceil((stop-start)/step), ceil((stop-start)/step-r))
with r = finfo(double).resolution instead of ceil((stop-start)/step)
perhaps be useful?
Joris
On 14 Sep 2007, at 11:37, Ed Schofield wrote:
Hi everyone,
This was reported yesterday as a bug in Debian's numpy package:
Hi,
I would like to know whether I could request svn write access to
numpy svn. There are several things I would like to work on which are
big enough so that just patch would be difficult, and branches more
appropriate, and my understanding is that svn branches requires write
access. The
I thought this is what the linspace function was
written for in numpy. Why not use that? It works
just like you would want always including the final
point.
--- Joris De Ridder [EMAIL PROTECTED]
wrote:
Might using
min(ceil((stop-start)/step),
ceil((stop-start)/step-r))
with r =
On 14 Sep 2007, at 15:54, Lou Pecora wrote:
I thought this is what the linspace function was
written for in numpy. Why not use that?
AFAIK, linspace() is written to generate N evenly spaced numbers
between start and stop inclusive. Similar but not quite the same as
arange().
It works
David Cournapeau wrote:
Hi,
I would like to know whether I could request svn write access to
numpy svn. There are several things I would like to work on which are
big enough so that just patch would be difficult, and branches more
appropriate, and my understanding is that svn branches
Ed Schofield wrote:
Hi everyone,
This was reported yesterday as a bug in Debian's numpy package:
len(numpy.arange(0, 0.6, 0.1)) == len(numpy.arange(0, 0.4+0.2, 0.1))
False
The cause is this:
ceil((0.4+0.2)/0.1)
7.0
ceil(0.6/0.1)
6.0
which holds for both numpy's and the
Hey Travis (and David),
Since you (Travis) approved, I went ahead and gave David (cdavid) svn
commit access to numpy. If you (David) have any difficulties, feel
free to email me directly and I will take care of it.
Cheers,
--
Jarrod Millman
Computational Infrastructure for Research Labs
10
On 9/14/07, Charles R Harris [EMAIL PROTECTED] wrote:
Since none of the numbers are exactly represented in IEEE floating point,
this sort of oddity is expected. If you look at the exact values, (.4 +
.2)/.1 6 and .6/.1 6 .
Just for my own benefit (and the past time) here are the actual
On Friday 14 September 2007 20:12, Charles R Harris wrote:
Since none of the numbers are exactly represented in IEEE floating
point, this sort of oddity is expected. If you look at the exact
values, (.4 + .2)/.1 6 and .6/.1 6 . That said, I would expect
You hit send too fast! The
Does anyone know if there are routines in scipy to compute these numbers? If
not, I could code some up if there is any interest. As a related question,
are there routines for returning the probabilities (as opposed to random
number generators) for the various distributions?
Chuck
Charles R Harris wrote:
Does anyone know if there are routines in scipy to compute these
numbers?
scipy.misc.comb() will handle the binomial coefficients. A ufunc or an
implementation that would broadcast would be welcome, though. I don't think we
have one for multinomial coefficients.
If
the question is how to reduce user astonishment.
IMHO this is exactly the point. There seems to be two questions here:
1) do we want to reduce user astonishment, and 2) if yes, how could
we do this? Not everyone seems to be convinced of the first question,
replying that in many cases
Sometimes numpy operationrs result in NotImplementedType. It makes it
a little hard to debug because the problem then crops up later when
you try to do an operation with the NotImplementedType. Does anyone
know of a way to get numpy to raise instead of returning not
implemented type?
(Pydb)
On 9/14/07, Joris De Ridder [EMAIL PROTECTED] wrote:
the question is how to reduce user astonishment.
IMHO this is exactly the point. There seems to be two questions here:
1) do we want to reduce user astonishment, and 2) if yes, how could
we do this? Not everyone seems to be convinced of
Tom Denniston wrote:
Sometimes numpy operationrs result in NotImplementedType. It makes it
a little hard to debug because the problem then crops up later when
you try to do an operation with the NotImplementedType. Does anyone
know of a way to get numpy to raise instead of returning not
The hitch is the error is in the bowels of the Scientific Python so I
was trying to get it to throw an exception to see what was going on.
It's while Scientific Python is trying to take a derivate. It's
further aggrevated by the fact that due to some bug in pdb or pydb,
i'm unable to get up the
On 9/14/07, Timothy Hochberg [EMAIL PROTECTED] wrote:
On 9/14/07, Joris De Ridder [EMAIL PROTECTED] wrote:
the question is how to reduce user astonishment.
IMHO this is exactly the point. There seems to be two questions here:
1) do we want to reduce user astonishment, and 2) if
On 9/14/07, Robert Kern [EMAIL PROTECTED] wrote:
Charles R Harris wrote:
In the case of arange it should be possible to determine when the result
is potentially ambiguous and issue a warning. For instance, if the
argument of the ceil function is close to its rounded value.
What's close?
I got another buildbot notification and as far as I can tell it has nothing
to do with my last commit. The stdio output is at
http://buildbot.scipy.org/MacOSX%20x86/builds/49/step-shell/0
And the errors seem to be of this sort:
_configtest.c: In function 'main':
_configtest.c:4: error: 'isnan'
Charles R Harris wrote:
I got another buildbot notification and as far as I can tell it has
nothing to do with my last commit. The stdio output is at
http://buildbot.scipy.org/MacOSX%20x86/builds/49/step-shell/0
http://buildbot.scipy.org/MacOSX%20x86/builds/49/step-shell/0
That's not the
On 9/14/07, lorenzo bolla [EMAIL PROTECTED] wrote:
this is really annoying.
Matlab handles the ceil weirdness quite well, though.
--
ceil(0.6/0.1)
ans =
6
ceil((0.4+0.2)/0.1)
ans =
7
0:0.1:0.6
ans =
Sorry about the hassle. It was working fine before a reboot. I'll try
to fix it this evening.
barry
On 9/14/07, Robert Kern [EMAIL PROTECTED] wrote:
Charles R Harris wrote:
I got another buildbot notification and as far as I can tell it has
nothing to do with my last commit. The stdio
Robert Kern wrote:
Here's the thing: binary floating point is intrinsically surprising to people
who are only accustomed to decimal.
Very good point. Binary arithmetic is NOT less accurate that decimal
arithmetic, it just has different values that it can't represent
exactly. So one is
On 15/09/2007, Christopher Barker [EMAIL PROTECTED] wrote:
Oh, and could someone post an actual example of a use for which FP
arange is required (with fudges to try to accommodate decimal to binary
conversion errors), and linspace won't do?
Well, here's one: evaluating a function we know to
28 matches
Mail list logo
