Re: [Python-Dev] Floor division

2007-01-26 Thread Guido van Rossum
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 K&R C) /provide

Re: [Python-Dev] Floor division

2007-01-26 Thread Nick Maclaren
"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

Re: [Python-Dev] Floor division

2007-01-26 Thread Tim Peters
[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'

Re: [Python-Dev] Floor division

2007-01-26 Thread Nick Maclaren
"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 genera

Re: [Python-Dev] Floor division

2007-01-26 Thread Tim Peters
[Tim (misattributed to Guido)] >> "(int)float_or_double" truncates in C (even in K&R 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

Re: [Python-Dev] Floor division

2007-01-26 Thread Nick Maclaren
"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 representati

Re: [Python-Dev] Floor division

2007-01-26 Thread Nick Maclaren
"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > > "(int)float_or_double" truncates in C (even in K&R 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

Re: [Python-Dev] Floor division

2007-01-25 Thread Tim Peters
[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,

Re: [Python-Dev] Floor division

2007-01-25 Thread Tim Peters
[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 t

Re: [Python-Dev] Floor division

2007-01-25 Thread Tim Peters
... [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 th

Re: [Python-Dev] Floor division

2007-01-25 Thread Tim Peters
[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

Re: [Python-Dev] Floor division

2007-01-25 Thread Tim Peters
[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. Si

Re: [Python-Dev] Floor division

2007-01-25 Thread Guido van Rossum
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. > > >

Re: [Python-Dev] Floor division

2007-01-25 Thread Tim Peters
[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: > do_something_expensive_once_a_second_on_the_s

Re: [Python-Dev] Floor division

2007-01-25 Thread Guido van Rossum
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 = time.

Re: [Python-Dev] Floor division

2007-01-25 Thread Nick Maclaren
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. Tho

Re: [Python-Dev] Floor division

2007-01-25 Thread Armin Rigo
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 number-t

Re: [Python-Dev] Floor division

2007-01-24 Thread Gareth McCaughan
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 wha

Re: [Python-Dev] Floor division

2007-01-24 Thread Alexey Borzenkov
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

Re: [Python-Dev] Floor division

2007-01-24 Thread Gareth McCaughan
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. Wh

Re: [Python-Dev] Floor division

2007-01-24 Thread Alexey Borzenkov
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, def

Re: [Python-Dev] Floor division

2007-01-23 Thread Gareth McCaughan
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?

Re: [Python-Dev] Floor division

2007-01-23 Thread Tim Peters
[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

[Python-Dev] Floor division

2007-01-23 Thread Nick Maclaren
"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

[Python-Dev] Floor division

2007-01-23 Thread Jim Jewett
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 dubio

Re: [Python-Dev] Floor division

2007-01-23 Thread Anders J. Munch
[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 retu

Re: [Python-Dev] Floor division

2007-01-23 Thread Armin Rigo
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

Re: [Python-Dev] Floor division

2007-01-23 Thread Facundo Batista
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

Re: [Python-Dev] Floor division

2007-01-23 Thread Anthony Baxter
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 n

Re: [Python-Dev] Floor division

2007-01-23 Thread Nick Maclaren
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 w

Re: [Python-Dev] Floor division

2007-01-23 Thread Tim Peters
[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 >> defini

Re: [Python-Dev] Floor division

2007-01-23 Thread Anders J. Munch
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 > defini

Re: [Python-Dev] Floor division

2007-01-23 Thread Tim Peters
[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

Re: [Python-Dev] Floor division

2007-01-23 Thread skip
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 Ti

Re: [Python-Dev] Floor division

2007-01-23 Thread Tim Peters
[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

Re: [Python-Dev] Floor division

2007-01-23 Thread Nick Maclaren
"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 retu

Re: [Python-Dev] Floor division

2007-01-23 Thread Anders J. Munch
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 > certai

Re: [Python-Dev] Floor division

2007-01-22 Thread Tim Peters
[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 di

Re: [Python-Dev] Floor division

2007-01-22 Thread Tim Peters
[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.

Re: [Python-Dev] Floor division

2007-01-22 Thread Tim Peters
[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

Re: [Python-Dev] Floor division

2007-01-22 Thread Facundo Batista
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: http://www.t

Re: [Python-Dev] Floor division

2007-01-22 Thread Nick Maclaren
"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())

Re: [Python-Dev] Floor division

2007-01-22 Thread Guido van Rossum
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

Re: [Python-Dev] Floor division

2007-01-21 Thread Tim Peters
... [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 >> t

Re: [Python-Dev] Floor division

2007-01-21 Thread Guido van Rossum
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) fo

Re: [Python-Dev] Floor division

2007-01-21 Thread Tim Peters
[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

Re: [Python-Dev] Floor division

2007-01-20 Thread Armin Rigo
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

Re: [Python-Dev] Floor division

2007-01-19 Thread Tim Peters
[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

Re: [Python-Dev] Floor division

2007-01-19 Thread Guido van Rossum
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 > floa

[Python-Dev] Floor division

2007-01-19 Thread 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 expected something simpler