RetroSearch Browse

Mon Mar 29 16:41:58 CEST 2010 · https://mail.python.org/pipermail/python-dev/2010-March/098992.html

On 2010-03-29 01:17 AM, David Cournapeau wrote:
> On Sun, Mar 28, 2010 at 9:28 AM, Robert Kern<robert.kern at gmail.com>  wrote:
>> On 2010-03-27 00:32 , David Cournapeau wrote:
>>>
>>> On Sat, Mar 27, 2010 at 8:16 AM, Raymond Hettinger
>>> <raymond.hettinger at gmail.com>    wrote:
>>>>
>>>> On Mar 26, 2010, at 2:16 PM, Xavier Morel wrote:
>>>>
>>>> How about raising an exception instead of creating nans in the first
>>>> place,
>>>> except maybe within specific contexts (so that the IEEE-754 minded can
>>>> get
>>>> their nans working as they currently do)?
>>>>
>>>> -1
>>>> The numeric community uses NaNs as placeholders in vectorized
>>>> calculations.
>>>
>>> But is this relevant to python itself ? In Numpy, we indeed do use and
>>> support NaN, but we have much more control on what happens compared to
>>> python float objects. We can control whether invalid operations raises
>>> an exception or not, we had isnan/isfinite for a long time, and the
>>> fact that nan != nan has never been a real problem AFAIK.
>>
>> Nonetheless, the closer our float arrays are to Python's float type, the
>> happier I will be.
>
> Me too, but I don't see how to reconcile this with the intent of
> simplifying nan handling because they are not intuitive, which seems
> to be the goal of this discussion.

"Do nothing" is still on the table, I think.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-March/098992.html below:

[Python-Dev] Why is nan != nan?