[ python-Bugs-1060644 ] Fix Decimal's .min() and .max() docs
regarding NaNs
SourceForge.net
noreply at sourceforge.net
Fri Nov 12 03:04:57 CET 2004
Bugs item #1060644, was opened at 2004-11-04 22:44
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1060644&group_id=5470
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Facundo Batista (facundobatista)
Assigned to: Facundo Batista (facundobatista)
Summary: Fix Decimal's .min() and .max() docs regarding NaNs
Initial Comment:
Raymond:
I propose to remove them as explicit methods because
the same behaviour can be achieved with the builtin
functions:
>>> Decimal("NaN").max(Decimal(8))
Decimal("8")
>>> max(Decimal("NaN"), Decimal(8))
Decimal("8")
(in the docs you put that .max() should return NaN if
either is a NaN, but it's not showing that behaviour
(and couldn't find any docs where says that it must to)).
I'm assigning this to you to have your opinion, but if
you're ok I can do the cleaning (code and docs).
I'm putting this as priority 6 because it will be more
painless to take them away before 2.4 final.
Regards,
. Facundo
----------------------------------------------------------------------
>Comment By: Facundo Batista (facundobatista)
Date: 2004-11-11 23:04
Message:
Logged In: YES
user_id=752496
Applied the changes to libdecimal.tex (v1.20).
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-11-11 04:59
Message:
Logged In: YES
user_id=80475
Facundo, please fix-up the docs for min() and max() so that
it has correct information about NaNs. I won't be around for
a week, so please take care of it before the release candidate
gets issued.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-11-09 23:16
Message:
Logged In: YES
user_id=80475
How about:
\begin{methoddesc}{max}{other\optional{, context}}
Like \samp{max(self, other)} except that the context
rounding rule
is applied before returning and that \constant{NaN} values are
either signalled or ignored (depending on the context and
whether
they are signaling or quiet).
----------------------------------------------------------------------
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-09 16:36
Message:
Logged In: YES
user_id=752496
The docs says:
Like "max(...)" but returns NaN if either is a NaN.
Maybe I'm misunderstanding the english here, but it seems to
me that that is plain wrong.
I don't want to bloat the docs neither, but I think that we
should change that sentence at least with something like:
Like "max(...)" but returns NaN if both are NaNs.
. Facundo
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-11-09 00:20
Message:
Logged In: YES
user_id=80475
I think the docs are fine the way the are now. You can put
so much stuff into them that they become incomprehensible.
The decimal docs may already be beyond that point.
----------------------------------------------------------------------
Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-08 09:52
Message:
Logged In: YES
user_id=1038590
I think "Use only this method. . ." would convey the desired
meaning better than "Only use this method. . ." .
The Decimal methods are always safe to use, but the builtin
functions are decidedly unsafe in the presence of NaN. The
wording in the last comment suggests that the Decimal
methods shouldn't be used in the general case (of course, if
that is what you mean to say, then that wording is fine. . .).
----------------------------------------------------------------------
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-05 03:30
Message:
Logged In: YES
user_id=752496
I'll change the docs to say (for both min and max):
Like "max/min(self, other)" but also applies the context
rounding rule before returning. Only use this method (and
not the built-in function max/min()) when dealing with
special values.
. Facundo
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-11-05 02:18
Message:
Logged In: YES
user_id=80475
'nuff said.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-11-05 00:27
Message:
Logged In: YES
user_id=31435
min() and max() are defined operations in the IBM spec, and
have to work the way the spec says they work. Here's a
reference for max:
http://www2.hursley.ibm.com/decimal/daops.html#refmax
Python's builtin min() and max() don't meet those
requirements. In particular, if the result is numeric it must be
rounded according to current context settings (the same as
applying the spec's unary plus).
Note that our docs are wrong if they say max returns NaN if
either input is a NaN. The spec says (for max):
If either operand is a NaN then the general rules apply,
unless one is a quiet NaN and the other is numeric, in
which case the numeric operand is returned.
I note that it says the same for min, so it's an odd sort of
ordering.
The implemented max seems correct:
>>> from decimal import Decimal as d
>>> eight = d("8")
>>> nan = d("NaN")
>>> nan.max(eight)
Decimal("8")
>>> eight.max(nan)
Decimal("8")
>>>
The builtin max() isn't even consistent here, giving a different
result depending on the order in which the operands are
specified:
>>> max(eight, nan)
Decimal("NaN")
>>> max(nan, eight)
Decimal("8")
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1060644&group_id=5470
More information about the Python-bugs-list
mailing list