Ok, I hit the send button too fast. Sorry!
Eike.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Christopher Barker wrote:
> Very good point. Binary arithmetic is NOT less accurate that decimal
> arithmetic, it just has different values that it can't represent
> exactly. . . .
Quibble: any number that can be represented exactly in binary can also
be represented in decimal, but not vice ver
On 14 Sep 2007, at 23:51, Robert Kern wrote:
> You can hide some of the surprises, but not all of them.
I guess it's impossible to make a bullet-proof "fix". When arange()
gets a 'stop' value of 0.60009, it cannot possibly know
whether this stop value is supposed to be 0.6, or wh
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
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 surpri
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
>
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.
>
> W
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"? The appropriate tolerance depends on the operation
Joris De Ridder 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 the first question,
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 as
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 co
> 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 lin
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 frac
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 ac
On 14/09/2007, 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 . That said, I would expect something like
> ceil(interval/d
On 9/14/07, Ed Schofield <[EMAIL PROTECTED]> 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
On 14/09/2007, Robert Kern <[EMAIL PROTECTED]> wrote:
> Ed Schofield wrote:
> > Using arange in this way is a fundamentally unreliable thing to do,
> > but is there anything we want to do about this?
>
> Tell people to use linspace(). Yes, it does a slightly different thing; that's
> why it works.
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 bot
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 wor
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 =
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
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
2.0
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().
Usi
23 matches
Mail list logo
