Mailman 3 January 2007 - Python-Dev

Re: [Python-Dev] Floor division
by Tim Peters 26 Jan '07

26 Jan '07

[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)) >> >> would do the same, except would be easier to reason about because it's >> trivially guaranteed that 0.0 <= math.fmod(x, 1.0) < 1.0 for any >> finite float x >= 0.0. The same may or may not be true of % (I would >> have to think about that, and craft a proof one way or the other -- if >> it is true, it would have to invoke something special about the >> modulus 1.0, as the inequality doesn't hold for % for some other >> modulus values). And as you note later, x%y == fmod(x, y) whenever x and y have the same sign (well, given the way CPython implements float.__mod__ today), so there's actually an easy proof. > Other modulus values are important: On an importance scale of 1 to 10, 9 or 10 ;-) ? > The attraction of Guido's formula is that he could just as easily have > used 60.0 or 0.001 if minute or millisecond intervals were desired, or > even som user-specified arbitrary dt. Then we're comparing dt-now%dt > to (1.0-int(now/dt))*dt or (math.ceil(now/dt)-now/dt)*dt. time.time() is never negative in Python (see other reply), so the trivial respelling dt-fmod(now, dt) does the same. > Fortunately, for all a,b>0, mathematically math.fmod(a,b) is equal to > a%b, so if the former is exactly representable, so is the latter. Yup. Also when `a` and `b` both less than 0. This /follows/ from that when `a` and `b` have the same sign, the mathematical a/b is >= 0, so truncation is the same as the floor. Therefore the mathematical a - floor(a/b)*b # Python __mod__ and a - truncate(a/b)*b # C fmod are exactly the same whenever a and b have the same sign. > Which is borne out in floatobject.c: float_rem and float_divmod just > pass on the C fmod result if (a < 0) == (b < 0). Yes. In fact, I wrote all that code :-)

1 0

Re: [Python-Dev] Floor division
by Nick Maclaren 26 Jan '07

26 Jan '07

Armin Rigo <arigo(a)tunes.org> 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 them not doing so would also make sense. The difference is that they make no mathematical sense for complex, but the problems with float are caused by floating-point (and do not occur for the mathematical reals). There is an argument for saying that divmod should return a long quotient and a float remainder, which is what C99 has specified for remquo (except that it requires only the last 3 bits of the quotient for reasons that completely baffle me). Linux misimplemented that the last time I looked. Personally, I think that it is bonkers, as it is fiendishly expensive compared to its usefulness - especially with Decimal! But it isn't obviously WRONG. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

2 1

Re: [Python-Dev] Floor division
by Tim Peters 26 Jan '07

26 Jan '07

... [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 least of his worries :-) Even on most Unixish boxes, Python's time.time() is immune to "the year 2038 problem" anyway, since it uses POSIX's gettimeofday() instead of C's time() when it can.

1 0

Floor division
by Raymond Hettinger 26 Jan '07

26 Jan '07

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 and faster: return PyFloat_FromDouble(floor(a/b)); Raymond

9 27

Having trouble committing
by Brett Cannon 26 Jan '07

26 Jan '07

I am trying to commit to the 2.5 branch and I am getting an error: svn: Commit failed (details follow): svn: Can't create directory '/data/repos/projects/db/transactions/53566-1.txn': Permission denied Anyone know what is going on? -Brett

4 4

Re: [Python-Dev] [Python-checkins] buildbot failure in amd64 gentoo 2.5
by "Martin v. Löwis" 24 Jan '07

24 Jan '07

Georg Brandl schrieb: > Do I miss something here, or is the buildbot hit by spammers now? It looks like it is. If that continues, we have to disable the web triggers. Regards, Martin

8 7

Complex constructors [was Re: Floor division]
by Nick Maclaren 24 Jan '07

24 Jan '07

Gareth McCaughan <gareth.mccaughan(a)pobox.com> wrote: > > ... The question is whether > it makes sense to define complex(a,b) = a+ib for all a,b > or whether the two-argument form is always in practice going > to be used with real numbers[1]. If it is, which seems pretty > plausible to me, then changing complex() to complain when > passed two complex numbers would (1) notify users sooner > when they have errors in their programs, (2) simplify the > code, and (3) avoid the arguably broken behaviour Tim was > remarking on, where complex(-0.0).real is +0 instead of -0. > > [1] For the avoidance of ambiguity: "real" is not > synonymous with "double-precision floating-point". Precisely. On this matter, does anyone know of an application where making that change would harm anything? I cannot think of a circumstance under which the current behaviour adds any useful function over the one that raises an exception if there are two arguments and either is complex. Yes, of course, SOME people will find it cool to write complex(a,b) when they really mean a+1j*b, but .... Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

compex numbers (was Floor Division)
by Jim Jewett 24 Jan '07

24 Jan '07

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?!: I think it is. python.org/sf/1642844 adds comments to make it less unclear. > >>> complex(complex(1.0, 2.0), complex(10.0, 20.0)) > (-19+12j) > WTF? >>> help(complex) Help on class complex in module __builtin__: class complex(object) | complex(real[, imag]) -> complex number | | Create a complex number from a real part and an optional imaginary part. | This is equivalent to (real + imag*1j) where imag defaults to 0. If "real" and "imag" are themselves complex numbers, then normalizing the result will move the imaginary portion of the "real" vector into the imaginary part and vice versa. Note that changing this (to discard the imaginary parts) would break passing complex numbers to their own constructor. >>> a=complex(1,2) >>> b=complex(a) >>> a==b True -jJ

2 1

compex numbers (was Floor Division)
by Nick Maclaren 23 Jan '07

23 Jan '07

"Jim Jewett" <jimjjewett(a)gmail.com> wrote: > 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?! > : > > I think it is. python.org/sf/1642844 adds comments to make it less unclear. Agreed. > > If "real" and "imag" are themselves complex numbers, then normalizing > the result will move the imaginary portion of the "real" vector into > the imaginary part and vice versa. Not really. What it does is to make complex(a,b) exactly equivalent to a+1j*b. For example: >>> a = 1+2j >>> b = 3+4j >>> complex(a) (1+2j) >>> b*1j (-4+3j) >>> complex(a,b) (-3+5j) > Note that changing this (to discard the imaginary parts) would break > passing complex numbers to their own constructor. Eh? Now, I am baffled. There are several ways of changing it, all of which would turn one bizarre behaviour into another - or would raise an exception. Personally, I would do the following: complex(a) would permit a to be complex. complex(a,b) would raise an exception if either a or b were complex. But chacun a son gout (accents omitted). Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

Floor division
by Nick Maclaren 23 Jan '07

23 Jan '07

"Jim Jewett" <jimjjewett(a)gmail.com> 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 tested your code today doesn't mean it will work tomorrow, or on a different set of values (however similar), or that it will give the same answer every time you do the same operation on the same input, or that the effects will be limited to wrong answers and stray exceptions. Still think that it is reasonable? > > Some people write Python that is intended to be robust and portable; > > it is those people who suffer. > > If your users stick to sensible inputs, then it doesn't matter which > model you used. Sigh. Let's step back a step. Who decides when inputs are sensible? And where is it documented? Answers: God alone knows, and nowhere. One of Python's general principles is that its operations should either do roughly what a reasonable user would expect, or it will raise an exception. It doesn't always get there, but it isn't bad. What you are saying is that is undesirable. The old Fortran and C model of saying that any user error can cause any effect (including nasal demons) is tolerable only if there is agreement on what IS an error, and there is some way for a user to find that out. In the case of C, neither is true. > If not, there is no way to get robust and portable; it is just a > matter of which users you annoy. Well, actually, there is. Though I agree that the techniques have rather been forgotten in the past 30 years. Python implements more of them than most languages. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0