[Kirill Balunov ]
> ...
> In spite of the fact that the pronouncement has
> already been made, there may still be an opportunity to influence this
> decision.
That's not really how this works. Guido has been doing this for
decades, and when he Pronounces he's done with it :-)
> I do not thi
2018-03-22 19:47 GMT+03:00 Tim Peters :
>
> > Is this functionality so often used and practical to be a method of
> float,
> > int, ..., and not just to be an auxiliary function?
> >
> > p.s.: The same thoughts about `as_integer_ratio` discussion.
>
> I would have added them as functions in the `m
[Kirill Balunov ]
> I apologize that I get into the discussion. Obviously in some situations it
> will be useful to check that a floating-point number is integral, but from
> the examples given it is clear that they are very rare. Why the variant with
> the inclusion of this functionality into the
In the PR which implements is_integer() for int, the numeric tower, and
Decimal I elected not to implement it for Complex or complex. This was
principally because complex instances, even if they have an integral real
value, are not convertible to int and it seems reasonable to me that any
number fo
I apologize that I get into the discussion. Obviously in some situations
it will be useful to check that a floating-point number is integral, but
from the examples given it is clear that they are very rare. Why the
variant with the inclusion of this functionality into the math module was
not consi
[Tim]
>> from trig functions doing argument reduction as if pi were represented
>> with infinite precision,
[Greg Ewing ]
> That sounds like an interesting trick! Can you provide
> pointers to any literature describing how it's done?
>
> Not doubting it's possible, just curious.
As I recall, when
Tim Peters wrote:
from trig functions doing argument reduction as if pi were represented
with infinite precision,
That sounds like an interesting trick! Can you provide
pointers to any literature describing how it's done?
Not doubting it's possible, just curious.
--
Greg
_
OK, we'll keep float.is_integer(), and that's a pronouncement, so that we
can hopefully end this thread soon.
It should also be added to int. After all that's what started this thread,
with the observation that mypy and PEP 484 consider an int valid whenever a
float is expected.
Since PEP 484 and
[Chris Barker ]
> ...
> ... "is it the "right" thing to do in most cases, when deployed by folks
> that haven't thought deeply about floating point.
Gimme a break ;-) Even people who _believe_ they've thought about
floating point still litter the bug tracker with
>>> .1 + .2
0.30004
Ok. I'm wrong on that example.
On Wed, Mar 21, 2018, 9:11 PM Tim Peters wrote:
> [David Mertz ]
> >> For example, this can be true (even without reaching inf):
> >>
> >> >>> x.is_integer()
> >> True
> >> >>> (math.sqrt(x**2)).is_integer()
> >> False
>
> [Mark Dickinson ]
> > If you have a momen
[Devin Jeanpierre ]
> PyPy (5.8):
> x = 1e300
> x.is_integer()
> True
> math.sqrt(x**2).is_integer()
> False
> x**2
> inf
I think you missed that David said "even without reaching inf" (you
did reach inf), and that I said "such that x*x neither overflows nor
underflows". Those
On Wed, Mar 21, 2018 at 11:43 PM, Tim Peters wrote:
> Note: this is a top-posted essay much more about floating-point
> philosophy than about details. Details follow from the philosophy,
> and if philosophies don't match the desired details will never match
> either.
>
but of course :-)
> Fr
> [Mark Dickinson ]
>> If you have a moment to share it, I'd be interested to know what value of
>> `x` you used to achieve this, and what system you were on. This can't happen
>> under IEEE 754 arithmetic.
>
> I expect it might happen under one of the directed rounding modes
> (like "to +infinity
[David Mertz ]
>> For example, this can be true (even without reaching inf):
>>
>> >>> x.is_integer()
>> True
>> >>> (math.sqrt(x**2)).is_integer()
>> False
[Mark Dickinson ]
> If you have a moment to share it, I'd be interested to know what value of
> `x` you used to achieve this, and what syste
Note: this is a top-posted essay much more about floating-point
philosophy than about details. Details follow from the philosophy,
and if philosophies don't match the desired details will never match
either.
Understanding floating point requires accepting that they're a funky
subset of rational
On Wed, Mar 21, 2018 at 8:49 PM, David Mertz wrote:
> For example, this can be true (even without reaching inf):
>
> >>> x.is_integer()
> True
> >>> (math.sqrt(x**2)).is_integer()
> False
>
If you have a moment to share it, I'd be interested to know what value of
`x` you used to achieve this, an
On Wed, Mar 21, 2018 at 3:02 PM, Tim Peters wrote:
> [David Mertz]
> > I've been using and teaching python for close to 20 years and I never
> > noticed that x.is_integer() exists until this thread.
>
> Except it was impossible to notice across most of those years, because
> it didn't exist acros
[David Mertz]
> I've been using and teaching python for close to 20 years and I never
> noticed that x.is_integer() exists until this thread.
Except it was impossible to notice across most of those years, because
it didn't exist across most of those years ;-)
> I would say the "one obvious way"
On Wed, Mar 21, 2018 at 11:14 AM, David Mertz wrote:
> I've been using and teaching python for close to 20 years and I never
> noticed that x.is_integer() exists until this thread. I would say the "one
> obvious way" is less than obvious.
>
> On the other hand, `x == int(x)` is genuinely obvious.
I've been using and teaching python for close to 20 years and I never
noticed that x.is_integer() exists until this thread. I would say the "one
obvious way" is less than obvious.
On the other hand, `x == int(x)` is genuinely obvious... and it immediately
suggests the probably better `math.isclose
I'd prefer to see `float.is_integer` stay. There _are_ occasions when one
wants to check that a floating-point number is integral, and on those
occasions, using `x.is_integer()` is the one obvious way to do it. I don't
think the fact that it can be misused should be grounds for deprecation.
As far
Here's an excerpted (and slightly simplified for consumption here) usage of
float.is_integer() from the top of a function which does some
convolution/filtering in a geophysics application. I've mostly seen it used
in guard clauses in this way to reject either illegal numeric arguments
directly, or
On Wed, Mar 21, 2018 at 3:08 PM, Guido van Rossum wrote:
> I searched 6M LoC of Python code at Dropbox and found only three uses.
> They seem legit. Two are about formatting a number that's given as a float,
> deciding whether to print a float as 42 or 3.14. The third is attempting a
> conversion
I searched 6M LoC of Python code at Dropbox and found only three uses. They
seem legit. Two are about formatting a number that's given as a float,
deciding whether to print a float as 42 or 3.14. The third is attempting a
conversion from float to integer where a non-integer must raise a specific
ex
>
>
> Does anybody know examples of the correct use of float.is_integer() in
> real programs? For now it looks just like a bug magnet. I suggest to
> deprecate it in 3.7 or 3.8 and remove in 3.9 or 3.10.
+1
It really doesn’t appear to be the right solution for any problem.
-CHB
--
Christopher
I searched usages of is_integer() on GitHub and have found that it is
used *only* in silly code like (x/5).is_integer(), (x**0.5).is_integer()
(or even (x**(1/3)).is_integer()) and in loops like:
i = 0
while i < 20:
if i.is_integer():
print(i)
i += 0.1
(x/5).is_i
26 matches
Mail list logo
