[Numpy-discussion] (no subject)
Hello,
Over at Python-ideas, there is a thread [0] about the following discrepancy:
numpy.array(float('inf')) // 1
inf
float('inf') // 1
nan
There are reasons for either result, but I believe it would be very
nice if either Python or Numpy changed, so they would give the same
value.
If any of you have reasons to defend Numpy's (or Python's) choice, or
otherwise want to chime in, please post there.
Thanks,
Petr Viktorin
[0] https://mail.python.org/pipermail/python-ideas/2014-September/029365.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] float('inf') // 1 = ?
(Apologies for the lack of subject earlier)
Hello,
Over at Python-ideas, there is a thread [0] about the following discrepancy:
numpy.array(float('inf')) // 1
inf
float('inf') // 1
nan
There are reasons for either result, but I believe it would be very
nice if either Python or Numpy changed, so they would give the same
value.
If any of you have reasons to defend Numpy's (or Python's) choice, or
otherwise want to chime in, please post there.
Thanks,
Petr Viktorin
[0] https://mail.python.org/pipermail/python-ideas/2014-September/029365.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] (no subject)
My vote is that NumPy is correct here. I see no reason why
float('inf') / 1
and
float('inf') // 1
should return different results.
Ben Root
On Thu, Sep 18, 2014 at 12:31 PM, Petr Viktorin encu...@gmail.com wrote:
Hello,
Over at Python-ideas, there is a thread [0] about the following
discrepancy:
numpy.array(float('inf')) // 1
inf
float('inf') // 1
nan
There are reasons for either result, but I believe it would be very
nice if either Python or Numpy changed, so they would give the same
value.
If any of you have reasons to defend Numpy's (or Python's) choice, or
otherwise want to chime in, please post there.
Thanks,
Petr Viktorin
[0]
https://mail.python.org/pipermail/python-ideas/2014-September/029365.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] float('inf') // 1 = ?
Sorry for the lack of subject before.
On Thu, Sep 18, 2014 at 6:48 PM, Benjamin Root ben.r...@ou.edu wrote:
My vote is that NumPy is correct here. I see no reason why
float('inf') / 1
and
float('inf') // 1
should return different results.
I recommend reading the python-ideas thread; there are some arguments
for both sides.
On Thu, Sep 18, 2014 at 12:31 PM, Petr Viktorin encu...@gmail.com wrote:
Hello,
Over at Python-ideas, there is a thread [0] about the following
discrepancy:
numpy.array(float('inf')) // 1
inf
float('inf') // 1
nan
There are reasons for either result, but I believe it would be very
nice if either Python or Numpy changed, so they would give the same
value.
If any of you have reasons to defend Numpy's (or Python's) choice, or
otherwise want to chime in, please post there.
Thanks,
Petr Viktorin
[0]
https://mail.python.org/pipermail/python-ideas/2014-September/029365.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] (no subject)
Well,
First of all, numpy and the python math module have a number of differences
when it comes to handling these kind of special cases -- and I think that:
1) numpy needs to do what makes the most sense for numpy and NOT mirror the
math lib.
2) the use-cases of the math lib and numpy are different, so they maybe
_should_ have different handling of this kind of thing.
3) I'm not sure that the core devs think these kinds of issues are wrong
'enough to break backward compatibility in subtle ways.
But it's a fun topic in any case, and maybe numpy's behavior could be
improved.
My vote is that NumPy is correct here. I see no reason why
float('inf') / 1
and
float('inf') // 1
should return different results.
Well, one argument is that floor division is supposed to return an
integer value, and that inf is NOT an integer value. The integral part of
infinity doesn't exist and thus is Not a Number.
You also get some weird edge cases around the mod operator.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] float('inf') // 1 = ?
On Thu, 2014-09-18 at 18:55 +0200, Petr Viktorin wrote:
Sorry for the lack of subject before.
On Thu, Sep 18, 2014 at 6:48 PM, Benjamin Root ben.r...@ou.edu wrote:
My vote is that NumPy is correct here. I see no reason why
float('inf') / 1
and
float('inf') // 1
Didn't read python ideas I have to admit (at least not enough to see
many arguments). My biggest argument is that numpy does exactly this:
import math
math.floor(float('inf')/1)
Maybe I am naive thinking that floordivide is basically a divide+floor
operation, but arguing for NaN seems half arsed to me on first sight.
Either it is `inf` and the equivalence Benjamin Root noted holds or you
make it an error. NaN is not reasonable for an error return *especially*
not for the standard lib (it *might* be for numpy).
- Sebastian
should return different results.
I recommend reading the python-ideas thread; there are some arguments
for both sides.
On Thu, Sep 18, 2014 at 12:31 PM, Petr Viktorin encu...@gmail.com wrote:
Hello,
Over at Python-ideas, there is a thread [0] about the following
discrepancy:
numpy.array(float('inf')) // 1
inf
float('inf') // 1
nan
There are reasons for either result, but I believe it would be very
nice if either Python or Numpy changed, so they would give the same
value.
If any of you have reasons to defend Numpy's (or Python's) choice, or
otherwise want to chime in, please post there.
Thanks,
Petr Viktorin
[0]
https://mail.python.org/pipermail/python-ideas/2014-September/029365.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] (no subject)
On 09/18/2014 12:01 PM, Chris Barker wrote:
Well,
First of all, numpy and the python math module have a number of
differences when it comes to handling these kind of special cases --
and I think that:
1) numpy needs to do what makes the most sense for numpy and NOT
mirror the math lib.
2) the use-cases of the math lib and numpy are different, so they
maybe _should_ have different handling of this kind of thing.
3) I'm not sure that the core devs think these kinds of issues are
wrong 'enough to break backward compatibility in subtle ways.
But it's a fun topic in any case, and maybe numpy's behavior could be
improved.
My vote is that NumPy is correct here. I see no reason why
float('inf') / 1
and
float('inf') // 1
should return different results.
Well, one argument is that floor division is supposed to return an
integer value, and that inf is NOT an integer value. The integral part
of infinity doesn't exist and thus is Not a Number.
But nan is not an integer value either:
float('inf') // 1
nan
int(float('inf') // 1)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: cannot convert float NaN to integer
Perhaps float('inf') // 1 should raise a ValueError directly since there
is no proper way perform the floor division on infinity.
- Jonathan Helmus
You also get some weird edge cases around the mod operator.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov mailto:chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] (no subject)
On Thu, Sep 18, 2014 at 7:14 PM, Jonathan Helmus jjhel...@gmail.com wrote:
On 09/18/2014 12:01 PM, Chris Barker wrote:
Well,
First of all, numpy and the python math module have a number of differences
when it comes to handling these kind of special cases -- and I think that:
1) numpy needs to do what makes the most sense for numpy and NOT mirror the
math lib.
Sure.
2) the use-cases of the math lib and numpy are different, so they maybe
_should_ have different handling of this kind of thing.
If you have a reason for the difference, I'd like to hear it.
3) I'm not sure that the core devs think these kinds of issues are wrong
'enough to break backward compatibility in subtle ways.
I'd be perfectly fine with it being documented and tested (in CPython)
as either a design mistake or design choice.
But it's a fun topic in any case, and maybe numpy's behavior could be
improved.
My vote is that NumPy is correct here. I see no reason why
float('inf') / 1
and
float('inf') // 1
should return different results.
Well, one argument is that floor division is supposed to return an integer
value, and that inf is NOT an integer value. The integral part of infinity
doesn't exist and thus is Not a Number.
But nan is not an integer value either:
float('inf') // 1
nan
int(float('inf') // 1)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: cannot convert float NaN to integer
Perhaps float('inf') // 1 should raise a ValueError directly since there is
no proper way perform the floor division on infinity.
inf not even a *real* number; a lot of operations don't make
mathematical sense on it. But most are defined anyway, and quite
sanely.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] (no subject)
On Thu, Sep 18, 2014 at 10:44 AM, Petr Viktorin encu...@gmail.com wrote:
2) the use-cases of the math lib and numpy are different, so they maybe
_should_ have different handling of this kind of thing.
If you have a reason for the difference, I'd like to hear it.
For one, numpy does array operations, and you really don't want a
ValueError (or any Exception) raised when perhaps only one value in a huge
array has an issue.
The other is that numpy users are potentially more sophisticated with
regard to numeric computing issues, and in any case, need to prioritize
different things -- like performance over safety.
But nan is not an integer value either:
I meant conceptually.
sure -- it's not any number at all -- a NaN can be arrived at many ways,
all it means something happened for which there was not an appropriate
numerical answer -- even inf or -inf. So, the question is:
is the integer part of inf infinity? or it undefined, and therefor NaN ?
I can't image a use case where it would matter, which is probably why numpy
returns inf.
Perhaps float('inf') // 1 should raise a ValueError directly since there
is
no proper way perform the floor division on infinity.
not in numpy for sure -- but I don't see the point in the math lib either,
let the NaN propagate and deal with later if you need to -- that's what
they are for.
- Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] float('inf') // 1 = ?
On Do, 2014-09-18 at 19:13 +0200, Sebastian Berg wrote:
On Thu, 2014-09-18 at 18:55 +0200, Petr Viktorin wrote:
Sorry for the lack of subject before.
On Thu, Sep 18, 2014 at 6:48 PM, Benjamin Root ben.r...@ou.edu wrote:
My vote is that NumPy is correct here. I see no reason why
float('inf') / 1
and
float('inf') // 1
Didn't read python ideas I have to admit (at least not enough to see
many arguments). My biggest argument is that numpy does exactly this:
import math
math.floor(float('inf')/1)
Maybe I am naive thinking that floordivide is basically a divide+floor
operation, but arguing for NaN seems half arsed to me on first sight.
Either it is `inf` and the equivalence Benjamin Root noted holds or you
make it an error. NaN is not reasonable for an error return *especially*
not for the standard lib (it *might* be for numpy).
Ok, sorry, that was too quick. Since we already have a special value
like Inf, it is OK to not give an error in the standard lib, since
Inf-Inf is also NaN, etc.
However, I read the arguments as Inf is not an integral number, and I
frankly don't understand that at all. Infinity isn't a real number as
well!?
If you represent the result as an IEEE float (integral or not) you can
use Inf as a valid result IMO. Arguably all of the limits:
floor(float) - Inf
float // 1 - Inf
exist for float - Inf and can be represented. Also IEEE seems to define
the floor operation like this and I don't see a reason why to violate
`a//b == floor(a/b)`. As long as the result is represented as an IEEE
floating point, which knows Infinity, I argue that it is correct. If it
is not an IEEE floating point, it is an error in any case.
- Sebastian
- Sebastian
should return different results.
I recommend reading the python-ideas thread; there are some arguments
for both sides.
On Thu, Sep 18, 2014 at 12:31 PM, Petr Viktorin encu...@gmail.com wrote:
Hello,
Over at Python-ideas, there is a thread [0] about the following
discrepancy:
numpy.array(float('inf')) // 1
inf
float('inf') // 1
nan
There are reasons for either result, but I believe it would be very
nice if either Python or Numpy changed, so they would give the same
value.
If any of you have reasons to defend Numpy's (or Python's) choice, or
otherwise want to chime in, please post there.
Thanks,
Petr Viktorin
[0]
https://mail.python.org/pipermail/python-ideas/2014-September/029365.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] (no subject)
On 09/18/2014 12:44 PM, Petr Viktorin wrote:
On Thu, Sep 18, 2014 at 7:14 PM, Jonathan Helmus jjhel...@gmail.com wrote:
On 09/18/2014 12:01 PM, Chris Barker wrote:
Well,
First of all, numpy and the python math module have a number of differences
when it comes to handling these kind of special cases -- and I think that:
1) numpy needs to do what makes the most sense for numpy and NOT mirror the
math lib.
Sure.
2) the use-cases of the math lib and numpy are different, so they maybe
_should_ have different handling of this kind of thing.
If you have a reason for the difference, I'd like to hear it.
3) I'm not sure that the core devs think these kinds of issues are wrong
'enough to break backward compatibility in subtle ways.
I'd be perfectly fine with it being documented and tested (in CPython)
as either a design mistake or design choice.
But it's a fun topic in any case, and maybe numpy's behavior could be
improved.
My vote is that NumPy is correct here. I see no reason why
float('inf') / 1
and
float('inf') // 1
should return different results.
Well, one argument is that floor division is supposed to return an integer
value, and that inf is NOT an integer value. The integral part of infinity
doesn't exist and thus is Not a Number.
But nan is not an integer value either:
float('inf') // 1
nan
int(float('inf') // 1)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: cannot convert float NaN to integer
Perhaps float('inf') // 1 should raise a ValueError directly since there is
no proper way perform the floor division on infinity.
inf not even a *real* number; a lot of operations don't make
mathematical sense on it. But most are defined anyway, and quite
sanely.
But in IEEE-754 inf is a valid floating point number (where-as NaN is
not) and has well defined arithmetic, specifically inf / 1 == inf and
RoundToIntergral(inf) == inf. In the numpy example, the
numpy.array(float('inf')) statement creates an array containing a
float32 or float64 representation of inf. After this I would expect a
floor division to return inf since that is what IEEE-754 arithmetic
specifies.
For me the question is if the floor division should also perform a cast
to an integer type. Since inf cannot be represented in most common
integer formats this should raise an exception. Since // does not
normally perform a cast, for example type(float(5) // 2) == float, the
point is mute.
The real question is if Python floats follows IEEE-754 arithmetic or
not. If they do not what standard are they going to follow?
- Jonathan Helmus
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] (no subject)
On Thu, Sep 18, 2014 at 1:30 PM, Jonathan Helmus jjhel...@gmail.com wrote:
On 09/18/2014 12:44 PM, Petr Viktorin wrote:
On Thu, Sep 18, 2014 at 7:14 PM, Jonathan Helmus jjhel...@gmail.com
wrote:
On 09/18/2014 12:01 PM, Chris Barker wrote:
Well,
First of all, numpy and the python math module have a number of
differences
when it comes to handling these kind of special cases -- and I think
that:
1) numpy needs to do what makes the most sense for numpy and NOT mirror
the
math lib.
Sure.
2) the use-cases of the math lib and numpy are different, so they maybe
_should_ have different handling of this kind of thing.
If you have a reason for the difference, I'd like to hear it.
3) I'm not sure that the core devs think these kinds of issues are
wrong
'enough to break backward compatibility in subtle ways.
I'd be perfectly fine with it being documented and tested (in CPython)
as either a design mistake or design choice.
But it's a fun topic in any case, and maybe numpy's behavior could be
improved.
My vote is that NumPy is correct here. I see no reason why
float('inf') / 1
and
float('inf') // 1
should return different results.
Well, one argument is that floor division is supposed to return an
integer
value, and that inf is NOT an integer value. The integral part of
infinity
doesn't exist and thus is Not a Number.
But nan is not an integer value either:
float('inf') // 1
nan
int(float('inf') // 1)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: cannot convert float NaN to integer
Perhaps float('inf') // 1 should raise a ValueError directly since
there is
no proper way perform the floor division on infinity.
inf not even a *real* number; a lot of operations don't make
mathematical sense on it. But most are defined anyway, and quite
sanely.
But in IEEE-754 inf is a valid floating point number (where-as NaN is
not) and has well defined arithmetic, specifically inf / 1 == inf and
RoundToIntergral(inf) == inf. In the numpy example, the
numpy.array(float('inf')) statement creates an array containing a
float32 or float64 representation of inf. After this I would expect a
floor division to return inf since that is what IEEE-754 arithmetic
specifies.
For me the question is if the floor division should also perform a cast
to an integer type. Since inf cannot be represented in most common
integer formats this should raise an exception. Since // does not
normally perform a cast, for example type(float(5) // 2) == float, the
point is mute.
The real question is if Python floats follows IEEE-754 arithmetic or
not. If they do not what standard are they going to follow?
- Jonathan Helmus
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Agreed. It's definitely best to follow the IEEE conventions. That will be
the most commonly expected behavior, especially in ambiguous cases like
this.
-Ian Henriksen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
