[Python-Dev] Symmetry arguments for API expansion

[Chris Barker]

On Wed, Mar 21, 2018 at 12:38 PM, Steven D'Aprano <steve at pearwood.info>
wrote:

> In fact, Serhiy's suggestion is not correct when x is not a float:
>

This is a key point -- see some of Tim's posts -- like ot or not, you
probably need to know when you are working with a float and when you aren't
-- and what the implications of that are.

I think the key pint is this:

where does the logic of whether a given object represents an integer
belong? At first glance, it clearly belongs with the type -- floats know
how they are represented, as do fractions and decimals -- they can
determine it in an efficient and clearly defined way.

However, my argument is that while an integer-valued float is clearly
defined in the binary representation, what "is this an integer?" means is
actually use-case dependent, and thus the user should be deciding how to do
it (i.e. with isclose() or int(x) == x or ....

> If the exponent is a computed float, then you

> > really don’t want a different result depending on whether the computed
> > value is exactly an integer or one ULP off.
>
> I don't think you actually mean to say that. I'm pretty sure that we
> *do* want different results if the exponent differs from an integer by
> one ULP.


yes -- poorly worded -- I mean you want the slightly different result, not
a different type and algorithm - i.e continuity if you had a range of
slightly less than an integer to slightly more than an integer.

> The user should check/convert to an integer with a method appropriate to

> > the problem at hand.
>
> Oh, you mean something like x.is_integer()? I agree!
>
> *wink*
>

That's the point -- is_integer may or may not be appropriate, and whether
it is is a function of use-case, not type.

> If it wasn’t too heavyweight, it might be nice to have some sort of flag
> on
> > floats indicating whether they really ARE an integer, rather than happen
> to
> > be:
> >
> > -Created from an integer literal
> > - created from an integer object
> > - result of floor(), ceil() or round()
>
> I don't understand this.
>

poorly worked again -- I shoud not write these on a phone....


> You seem to be saying that none of the following are "really" integer
> valued:
>
> float(10)
> floor(10.1)
> ceil(10.1)
> round(10.1)
>

I meant those are the ones that ARE really integer valued.

turns out that py3 returns an actual int for all of those other than
float() (of course) anyway, so that's pretty much been done -- and no need
for is_integer()

well, it's been fun, but looks like it's sticking around.....


-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180322/246c0c9d/attachment.html>