Message136478
| Author |
belopolsky |
| Recipients |
alex, belopolsky, daniel.urban, mark.dickinson, pitrou, rhettinger |
| Date |
2011年05月21日.20:26:53 |
| SpamBayes Score |
1.5455415e-12 |
| Marked as misclassified |
No |
| Message-id |
<BANLkTik4r-jOvRA+3jpGsW8EJpTN_MasuQ@mail.gmail.com> |
| In-reply-to |
<1306006347.99.0.00190259995193.issue11986@psf.upfronthosting.co.za> |
| Content |
On Sat, May 21, 2011 at 3:32 PM, Mark Dickinson <report@bugs.python.org> wrote:
..
> That might be viable (a math module function might also make sense here), though it feels a bit YAGNI to me.
I have to admit that it would be YAGNI for most of my code because it
uses numpy for numeric calculations. Still, for consistency with
decimal, it may be a good addition.
Going a bit off-topic, I would like to mention the feature that may
actually be quite useful: float.sorting_key() that will return an
integer for each float in such a way that keys are ordered in IEEE 754
total ordering. Note that decimal has compare_total() that can be
used for sorting, but a cmp-style method is less useful than a key
since in py3k sort does not take cmp function anymore. Nice thing
about IEEE 754 is that float.sorting_key() can be implemented very
efficiently because one can simply use float's binary representation
interpreted as an integer for the key.
> If we were going to add such a method, it should follow IEEE 754: nan.max(x) == x.max(n) == x,
> but also nan.min(x) == x.min(nan) == x, for finite x. (See section 5.3.1.)
Agree. Unfortunately, numpy does not do it that way:
nan
>>> maximum(1.0, nan)
nan
I am not sure whether this is an argument for or against
float.max/min: if numpy had properly defined maximum, I would just
recommend to use that. |
|