Guido van Rossum [EMAIL PROTECTED] wrote:
(int)float_or_double truncates in C (even in KR C) /provided that/
the true result is representable as an int. Else behavior is
undefined (may return -1, may cause a HW fault, ...).
Actually, I have used Cs that didn't, but haven't seen any in over
Tim Peters [EMAIL PROTECTED] wrote:
It could, but who would have a (sane) use for a possibly 2000-bit quotient?
Well, the 'exact rounding' camp in IEEE 754 seem to think that there
is one :-)
As you can gather, I can't think of one. Floating-point is an inherently
inaccurate representation
[Tim (misattributed to Guido)]
(int)float_or_double truncates in C (even in KR C) /provided that/
the true result is representable as an int. Else behavior is
undefined (may return -1, may cause a HW fault, ...).
[Nick Maclaren]
Actually, I have used Cs that didn't, but haven't seen any in
Tim Peters [EMAIL PROTECTED] wrote:
[Tim (misattributed to Guido)]
Apologies to both!
C90 is unclear about its intent,
But am skeptical of that. I don't have a copy of C90 here, but before
I wrote that I checked Kernighan Ritchie's seminal C book, Harbison
Steele's generally excellent
[Tim Peters]
...
[it would be possible for float.__divmod__ to return the exact
quotient], but who would have a (sane) use for a possibly 2000-bit
quotient?
[Nick Maclaren]
Well, the 'exact rounding' camp in IEEE 754 seem to think that there
is one :-)
As you can gather, I can't think of
Tim Peters [EMAIL PROTECTED] wrote:
OTOH, I am a fan of analyzing FP operations as if the inputs were in
fact exactly what they claim to be, which 754 went a long way toward
popularizing. That largely replaced mountains of idiosyncratic
probabilistic arguments (and where it seemed no two
Nick, I didn't write that; Tim did. If you're going to enter into a
pedantic discussion, at least get your attributions right,
On 1/26/07, Nick Maclaren [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
(int)float_or_double truncates in C (even in KR C) /provided that/
the
Hi Tim,
On Tue, Jan 23, 2007 at 05:14:29PM -0500, Tim Peters wrote:
For some reason `decimal` implemented __mod__ as the proposed
standard's remainder operation. That's the immediate source of your
surprise. IMO `decimal` should not have implemented __mod__ at all,
as Python's
Armin Rigo [EMAIL PROTECTED] wrote:
Thanks for the clarification. Yes, it makes sense that __mod__,
__divmod__ and __floordiv__ on float and decimal would eventually follow
the same path as for complex (where they make even less sense and
already raise a DeprecationWarning).
Yes. Though
The only thing I would miss about this is that I am used to write
certain timing loops that like to sync on whole seconds, by taking
time.time() % 1.0 which nicely gives me the milliseconds in the
current second. E.g.
while True:
do_something_expensive_once_a_second_on_the_second()
now =
[Guido]
The only thing I would miss about this is that I am used to write
certain timing loops that like to sync on whole seconds, by taking
time.time() % 1.0 which nicely gives me the milliseconds in the
current second. E.g.
while True:
On 1/25/07, Tim Peters [EMAIL PROTECTED] wrote:
[Guido]
The only thing I would miss about this is that I am used to write
certain timing loops that like to sync on whole seconds, by taking
time.time() % 1.0 which nicely gives me the milliseconds in the
current second. E.g.
while True:
[Guido]
...
I don't care about the speed, but having to import math (which I
otherwise almost never need) is a distraction, and (perhaps more so) I
can never remember whether it's modf() or fmod() that I want.
fractional part of x == fmod(x, 1.0) == modf(x)[0], so you could use
either. Since
[Armin]
Thanks for the clarification. Yes, it makes sense that __mod__,
__divmod__ and __floordiv__ on float and decimal would eventually follow
the same path as for complex (where they make even less sense and
already raise a DeprecationWarning).
This truly has nothing to do with complex.
...
[Tim]
fractional part of x == fmod(x, 1.0) == modf(x)[0], so you could use
either.
[Anders J. Munch]
Actually, on the off chance that time.time() is negative, he can use
neither. It has to be math.ceil, float.__mod__ or divmod.
If time.time() is negative, I expect this would be the
[Armin Rigo]
Thanks for the clarification. Yes, it makes sense that __mod__,
__divmod__ and __floordiv__ on float and decimal would eventually follow
the same path as for complex (where they make even less sense and
already raise a DeprecationWarning).
[Nick Maclaren]
Yes. Though them not
[Tim Peters]
...
Maybe we could introduce % as a unary prefix operator, where
%x means the fractional part of x ;-)
[Anders J. Munch]
What'ya talking about? Obviously it should be a suffix operator ;-)
Na -- that would be confusing ;-)
...
time.sleep(1.0 - math.fmod(now, 1.0))
On 1/24/07, Gareth McCaughan [EMAIL PROTECTED] wrote:
complex(complex(1.0, 2.0), complex(10.0, 20.0))
(-19+12j)
WTF? In any case, that's also what's destroying the sign of the
imaginary part in complex(1.0, -0.0).
It seems pretty clear what it thinks it's doing -- namely,
defining
On Wednesday 24 January 2007 08:39, Alexey Borzenkov wrote:
[me, about complex():]
It seems pretty clear what it thinks it's doing -- namely,
defining complex(a,b) = a + ib even when a,b are complex.
And half of why it does that is clear: you want complex(a)=a
when a is complex. Why b
On 1/24/07, Gareth McCaughan [EMAIL PROTECTED] wrote:
[Alexey:]
I think that's the right thing to do, because that is mathematically
correct. j is just an imaginary number with a property that j*j = -1. So
(a+bj) + (c+dj)j = (a-d) + (b+c)j.
Yes, thanks, I know what j is, and I know how to
On Wednesday 24 January 2007 10:20, Alexey Borzenkov wrote:
I think that's the right thing to do, because that is mathematically
correct. j is just an imaginary number with a property that j*j = -1.
So
(a+bj) + (c+dj)j = (a-d) + (b+c)j.
Yes, thanks, I know what j is, and I know
Tim Peters wrote:
Do note that this discussion is only about Python 3. Under the view
that it was a (minor, but real) design error to /try/ extending
Python's integer mod definition to floats, if __mod__, and __divmod__
and __floordiv__ go away for binary floats in P3K they should
certainly
Tim Peters [EMAIL PROTECTED] wrote:
I guess the conjugate() function could also just return self (although I see
that conjugate() for a complex with a zero imaginary part returns
something whose imaginary part is -0; is that intentional?
That's wrong, if true: it should return something
[Anders J. Munch]
What design error? float.__mod__ works perfectly.
-1 % 50
49
-1.0 % 50.0
49.0
Please read the whole thread. Maybe you did, but you said nothing
here that indicated you had. The issues aren't about tiny integers
that happen to be in float format, where the result is
Tim For example, floor division isn't mentioned at all in IBM's
Tim proposed decimal standard, or in PEP 327, or in the Python Library
Tim Reference section on `decimal`. It's an artifact of trying to
Tim extend Python's integer mod definition to floats, and for reasons
Tim
[Guido]
I guess the conjugate() function could also just return self (although I see
that conjugate() for a complex with a zero imaginary part returns
something whose imaginary part is -0; is that intentional?
[TIm Peters]
That's wrong, if true: it should return something with the opposite
Tim Peters wrote:
Please read the whole thread. Maybe you did, but you said nothing
here that indicated you had. The issues aren't about tiny integers
that happen to be in float format, where the result is exactly
representable as a float too. Those don't create problems for any
definition
[Tim Peters]
Please read the whole thread. Maybe you did, but you said nothing
here that indicated you had. The issues aren't about tiny integers
that happen to be in float format, where the result is exactly
representable as a float too. Those don't create problems for any
definition of
A generic comment. Many of my postings seem to be being misunderstood.
I hold no brief for ANY particular floating-point religion, sect or
heresy, except insofar as it affects robustness and portability (i.e.
software engineering). I can work with and teach almost any model,
and have done so
On Tuesday 23 January 2007 22:27, Tim Peters wrote:
Which is why I don't want binary or decimal floats to support
infix % as a spelling in P3K. I don't believe floating mod is
heavily used, and if so there's scant need for a one-character
spelling -- and if there's a method or function name
Tim Peters wrote:
Which Spec? For example, floor division isn't mentioned at all in
IBM's proposed decimal standard, or in PEP 327, or in the Python
Oops, you're right. My fault, sorry.
Library Reference section on `decimal`. It's an artifact of trying to
extend Python's integer mod
Hi Tim,
On Sun, Jan 21, 2007 at 09:08:18PM -0500, Tim Peters wrote:
BTW - isn't that case in contradiction with the general Python rule that
if b 0, then a % b should return a number between 0 included and b
excluded?
Sure.
You're not addressing my point, though, so I was probably not
[Tim Peters]
[Anders J. Munch]
I did read the whole thread, and I saw your -1%1e100 example. Mixing
floating-point numbers of very different magnitude can get you in
trouble - e.g. -1+1e100==1e100. I don't think -1%1e100 is all that
worse.
Except that it's very easy to return an
Nick Maclaren wrote:
... I can work with and teach almost any model,
and have done so with some pretty weird ones.
I think python's model is Whatever your other tools use. Ask them.
And I think that is a reasonable choice.
For sensible input, the various models all work the same.
For dubious
Jim Jewett [EMAIL PROTECTED] wrote:
... I can work with and teach almost any model,
and have done so with some pretty weird ones.
I think python's model is Whatever your other tools use. Ask them.
And I think that is a reasonable choice.
Answer: It's undefined. Just because you have
[Armin]
BTW - isn't that case in contradiction with the general Python rule that
if b 0, then a % b should return a number between 0 included and b
excluded?
[Tim]
Sure.
[Armin]
You're not addressing my point, though, so I was probably not clear
enough.
Sure is the answer to all possible
On Tuesday 23 January 2007 07:01, Tim Peters wrote:
complex_new() ends with:
cr.real -= ci.imag;
cr.imag += ci.real;
and I have no idea what that thinks it's doing. Surely this isn't
intended?!:
complex(complex(1.0, 2.0), complex(10.0, 20.0))
(-19+12j)
WTF? In any case,
On 1/21/07, Tim Peters [EMAIL PROTECTED] wrote:
[Tim]
It's just a fact that different definitions of mod are most useful
most often depending on data type. Python's is good for integers and
often sucks for floats. The C99 and `decimal` definition(s) is/are
good for floats and often
Guido van Rossum [EMAIL PROTECTED] wrote:
That really sucks, especially since the whole point of making int
division return a float was to make the integers embedded in the
floats... I think the best solution would be to remove the definition
of % (and then also for divmod()) for
Guido van Rossum wrote:
The ints aren't really embedded in Decimal, so we don't have to do
that there (but we could).
-0.
If we can't achieve it without disturbing the rest of Python, I'll try
as much as possible to keep what the Spec proposes.
Regards,
--
. Facundo
.
Blog:
[Guido]
...
So you are proposing that Decimal also rip out the % and // operators
and __divmod__? WFM, but I don't know what Decimal users say (I'm not
one).
Yes: it's just as much a floating type as HW binary floats, and all
the same issues come up. For example, decimal floats are just as
[Guido]
That really sucks, especially since the whole point of making int
division return a float was to make the integers embedded in the
floats... I think the best solution would be to remove the definition
of % (and then also for divmod()) for floats altogether, deferring to
math.fmod()
[Guido]
The ints aren't really embedded in Decimal, so we don't have to do
that there (but we could).
[Facundo Batista]
-0.
If we can't achieve it without disturbing the rest of Python, I'll try
as much as possible to keep what the Spec proposes.
Which Spec? For example, floor division
[Tim Peters]
...
decimal.Decimal(-1) % decimal.Decimal(1e100)
Decimal(-1)
[Armin Rigo]
BTW - isn't that case in contradiction with the general Python rule that
if b 0, then a % b should return a number between 0 included and b
excluded?
Sure.
We try hard to do that for ints, longs and
On 1/21/07, Tim Peters [EMAIL PROTECTED] wrote:
It's just a fact that different definitions of mod are most useful
most often depending on data type. Python's is good for integers and
often sucks for floats. The C99 and `decimal` definition(s) is/are
good for floats and often suck(s) for
...
[Tim]
It's just a fact that different definitions of mod are most useful
most often depending on data type. Python's is good for integers and
often sucks for floats. The C99 and `decimal` definition(s) is/are
good for floats and often suck(s) for integers. Trying to pretend
that
Hi Tim,
On Fri, Jan 19, 2007 at 08:33:23PM -0500, Tim Peters wrote:
decimal.Decimal(-1) % decimal.Decimal(1e100)
Decimal(-1)
BTW - isn't that case in contradiction with the general Python rule that
if b 0, then a % b should return a number between 0 included and b
excluded? We try hard to
I bumped into an oddity today:
6.0 // 0.001 != math.floor(6.0 / 0.001)
In looking at Objects/floatobject.c, I was surprised to find that
float_floor_division() is implemented in terms of float_divmod(). Does anyone
know why it takes such a circuitous path? I had expected something
Probably because I tend not to know what I'm doing when numerics are
concerned. :-(
On 1/19/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
I bumped into an oddity today:
6.0 // 0.001 != math.floor(6.0 / 0.001)
In looking at Objects/floatobject.c, I was surprised to find that
[Raymond Hettinger]
I bumped into an oddity today:
6.0 // 0.001 != math.floor(6.0 / 0.001)
In looking at Objects/floatobject.c, I was surprised to find that
float_floor_division() is implemented in terms of float_divmod(). Does anyone
know why it takes such a circuitous path? I had
50 matches
Mail list logo
