On Thu, Sep 18, 2014 at 10:35 AM, wrote:
> It's be nice if Python's math module did more than simply wrap the default i
> implementation of the underlying C lib -- it's gotten better over the years
> (Inf and NaN used to be really hard to get), but still not quite what it
> could be.
I think
On Wednesday, September 17, 2014 11:22:42 PM UTC-7, wxjm...@gmail.com wrote:
> >>> 1e300*1e300
>
> inf
>
> >>> exp(1e300)
>
> Traceback (most recent call last):
>
> File "", line 1, in
>
> OverflowError: math range error
FWIW, numpy is a bit more consistent:
In [89]: numpy.exp(1e300)
Out[
On 2014-09-18, Steven D'Aprano wrote:
> Marko Rauhamaa wrote:
>
>> Maybe IEEE had some specific numeric algorithms in mind when it
>> introduced inf and nan. However, I have a feeling an exception would be
>> a sounder response whenever the arithmetics leaves the solid ground.
>
> I'm afraid that
Marko Rauhamaa wrote:
> Maybe IEEE had some specific numeric algorithms in mind when it
> introduced inf and nan. However, I have a feeling an exception would be
> a sounder response whenever the arithmetics leaves the solid ground.
I'm afraid that you're missing the essential point of INF and qu
On Thursday, September 18, 2014 6:12:08 AM UTC+3, Steven D'Aprano wrote:
> cool-RR wrote:
> > Chris, why is this invariant `div*y + mod == x` so important? Maybe it's
> > more important to return a mathematically reasonable result for the the
> > floor-division result than to maintain this invarian
On Wed, Sep 17, 2014 at 3:37 PM, Chris Angelico wrote:
> It's not something I've personally worked with, so I'm trying to
> dredge stuff up from my brain, but I think there's something along the
> lines of "stuff shouldn't be a multiple of everything" and the Prime
> Number Theorem. But that may j
wxjmfa...@gmail.com:
> In short, a lack of consistency.
>
1e300*1e300
> inf
exp(1e300)
> Traceback (most recent call last):
> File "", line 1, in
> OverflowError: math range error
Good point!
Maybe IEEE had some specific numeric algorithms in mind when it
introduced inf and nan. How
On Thu, Sep 18, 2014 at 1:29 PM, Steven D'Aprano
wrote:
> Perhaps you are thinking of the Fundamental Theorem of Arithmetic, which
> states that every positive integer except 1 can be uniquely factorized into
> a product of one or more primes?
>
> http://mathworld.wolfram.com/FundamentalTheoremofA
Chris Angelico wrote:
> On Thu, Sep 18, 2014 at 4:03 AM, Ian Kelly wrote:
>> On Wed, Sep 17, 2014 at 9:10 AM, Chris Angelico wrote:
>>> And while it's
>>> conceivable to define that infinity divided by anything is infinity,
>>> and infinity modulo anything is zero, that raises serious issues of
cool-RR wrote:
> Chris, why is this invariant `div*y + mod == x` so important? Maybe it's
> more important to return a mathematically reasonable result for the the
> floor-division result than to maintain this invariant?
You keep talking about floor(inf) == inf being "mathematically reasonable",
Chris Angelico wrote:
> On Thu, Sep 18, 2014 at 1:34 AM, Ian Kelly wrote:
>> On Wed, Sep 17, 2014 at 9:29 AM, Chris Angelico wrote:
>>> Invariant: div*y + mod == x.
>>>
>>> If mod is NaN, there is no possible value for div that will make the
>>> invariant true, ergo it too has to be NaN.
>>
>>
On 9/17/2014 10:55 AM, cool-RR wrote:
Terry, that doesn't really answer the question "why", it just pushes
it back to the documentation. Is there a real answer why? Why return
NaN when Inf would make mathematical sense?
IEEE float('inf') and float('nan') are engineering, not math constructs.
I
On Thu, Sep 18, 2014 at 4:03 AM, Ian Kelly wrote:
> On Wed, Sep 17, 2014 at 9:10 AM, Chris Angelico wrote:
>> And while it's
>> conceivable to define that infinity divided by anything is infinity,
>> and infinity modulo anything is zero, that raises serious issues of
>> primality and such; I'm no
On Wed, Sep 17, 2014 at 9:10 AM, Chris Angelico wrote:
> And while it's
> conceivable to define that infinity divided by anything is infinity,
> and infinity modulo anything is zero, that raises serious issues of
> primality and such; I'm not sure that that would really help anything.
I missed th
On Thu, Sep 18, 2014 at 2:33 AM, cool-RR wrote:
> On Wednesday, September 17, 2014 6:30:04 PM UTC+3, Chris Angelico wrote:
>> On Thu, Sep 18, 2014 at 1:16 AM, cool-RR wrote:
>> > I didn't ask for the modulo, I agree it should remain NaN. I'm talking
>> > about the floor division.
>>
>> Invariant
On Wednesday, September 17, 2014 6:30:04 PM UTC+3, Chris Angelico wrote:
> On Thu, Sep 18, 2014 at 1:16 AM, cool-RR wrote:
> > I didn't ask for the modulo, I agree it should remain NaN. I'm talking
> > about the floor division.
>
> Invariant: div*y + mod == x.
> If mod is NaN, there is no possib
On Wed, Sep 17, 2014 at 9:40 AM, Chris Angelico wrote:
> On Thu, Sep 18, 2014 at 1:34 AM, Ian Kelly wrote:
>> On Wed, Sep 17, 2014 at 9:29 AM, Chris Angelico wrote:
>>> On Thu, Sep 18, 2014 at 1:16 AM, cool-RR wrote:
I didn't ask for the modulo, I agree it should remain NaN. I'm talking
>
On Wed, Sep 17, 2014 at 9:40 AM, Chris Angelico wrote:
> On Thu, Sep 18, 2014 at 1:34 AM, Ian Kelly wrote:
>> On Wed, Sep 17, 2014 at 9:29 AM, Chris Angelico wrote:
>>> On Thu, Sep 18, 2014 at 1:16 AM, cool-RR wrote:
I didn't ask for the modulo, I agree it should remain NaN. I'm talking
>
On Thu, Sep 18, 2014 at 1:34 AM, Ian Kelly wrote:
> On Wed, Sep 17, 2014 at 9:29 AM, Chris Angelico wrote:
>> On Thu, Sep 18, 2014 at 1:16 AM, cool-RR wrote:
>>> I didn't ask for the modulo, I agree it should remain NaN. I'm talking
>>> about the floor division.
>>>
>>
>> Invariant: div*y + mod
On Tue, Sep 16, 2014 at 7:12 PM, Terry Reedy wrote:
> It does not really matter, however, as infinity cannot be 'floored' as
> required for //
>
math.floor(float('inf'))
> Traceback (most recent call last):
> File "", line 1, in
> math.floor(float('inf'))
> OverflowError: cannot conver
On Wed, Sep 17, 2014 at 9:29 AM, Chris Angelico wrote:
> On Thu, Sep 18, 2014 at 1:16 AM, cool-RR wrote:
>> I didn't ask for the modulo, I agree it should remain NaN. I'm talking about
>> the floor division.
>>
>
> Invariant: div*y + mod == x.
>
> If mod is NaN, there is no possible value for di
On Thu, Sep 18, 2014 at 1:16 AM, cool-RR wrote:
> I didn't ask for the modulo, I agree it should remain NaN. I'm talking about
> the floor division.
>
Invariant: div*y + mod == x.
If mod is NaN, there is no possible value for div that will make the
invariant true, ergo it too has to be NaN.
Ch
On Wednesday, September 17, 2014 6:10:35 PM UTC+3, Chris Angelico wrote:
> On Thu, Sep 18, 2014 at 12:55 AM, cool-RR wrote:
> > Terry, that doesn't really answer the question "why", it just pushes it
> > back to the documentation. Is there a real answer why? Why return NaN when
> > Inf would mak
On Thu, Sep 18, 2014 at 12:55 AM, cool-RR wrote:
> Terry, that doesn't really answer the question "why", it just pushes it back
> to the documentation. Is there a real answer why? Why return NaN when Inf
> would make mathematical sense?
>
To answer that, we have to first look at what it means t
Terry, that doesn't really answer the question "why", it just pushes it back to
the documentation. Is there a real answer why? Why return NaN when Inf would
make mathematical sense?
On Wednesday, September 17, 2014 4:13:38 AM UTC+3, Terry Reedy wrote:
> On 9/16/2014 5:40 PM, cool-RR wrote:
>
>
On 9/16/2014 5:40 PM, cool-RR wrote:
While debugging my code I found that the bug was because I assumed
that something like `divmod(float('inf'), 1)` would be equal to
`(float('inf'), float('nan'))`, while Python returns `(float('nan'),
float('nan'))`. Why does Python make the division result be
While debugging my code I found that the bug was because I assumed that
something like `divmod(float('inf'), 1)` would be equal to `(float('inf'),
float('nan'))`, while Python returns `(float('nan'), float('nan'))`. Why does
Python make the division result be NaN in this case? `float('inf') / 1`
27 matches
Mail list logo
