Mailman 3 January 2007 - Python-Dev

Floor division
by Jim Jewett Jan. 24, 2007

Jan. 24, 2007

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 input, you get the same answer as you got from some other tool, so you can automate some of your regression testing. >... Python doesn't support any libm >behaviour other than the one … [View More]

1 0

Re: [Python-Dev] Floor division
by Anders J. Munch Jan. 23, 2007

Jan. 23, 2007

[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 exactly correct result in that > case: -1. Except that the function that computes -1 is a different function. Either it makes a difference which function … [View More]

1 0

Fwd: Re: Floor division
by python＠rcn.com Jan. 23, 2007

Jan. 23, 2007

>> 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 go away for decimal floats in P3K too. And that's about >> syntax, not functionality: the IBM spec's "remainder" and >> "remainder-near" still need to be there, it's … [View More]

2 1

Re: [Python-Dev] Floor division
by Anders J. Munch Jan. 23, 2007

Jan. 23, 2007

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 of mod. But even non-tiny exact integers can. I did read the whole thread, and I saw your -1%1e100 example. Mixing floating-point numbers of very different magnitude can get you … [View More]

3 2

Re: [Python-Dev] Floor division
by Nick Maclaren Jan. 23, 2007

Jan. 23, 2007

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 with some pretty weird ones. My objections to some proposals is that they are sacrificing those in favour of some ill-defined objectives. "Tim Peters" <tim.peters(a)gmail.com> wrote: > [TIm … [View More]Peters] > >> That's wrong, if true: it should return something with the opposite > >> sign on the imaginary part, whether or not that equals 0 (+0. and -0. > >> both "equal 0"). > > |[Nick Maclaren] > > Grrk. Why? Seriously. > > Seriously: because there's some reason to do so and no good reason > not to. Hmm. That doesn't fully support the practice, except for IEEE 754(R) numbers. To require a floating-point format to have signed zeroes is a religious matter. But I agree that specifying something different if the numbers are an IEEE 754(R) format makes no sense. > > And, returning to 'floor' - if one is truncating towards -infinity, > > should floor(-0.0) deliver -1.0, 0.0 or -0.0? > > I'd leave a zero argument alone (for ceiling too), and am quite sure > that's "the right" 754-ish behavior. It's not clear, and there was a debate about it! But it is what IEEE 754R ended up specifying. > Couldn't quite parse that, but nearly all of Python's math-module > functions inherit most behavior from the platform libm. This is often > considered to be a feature: the functions called from Python > generally act much like they do when called from C or Fortran on the > same platform, easing cross-language development on a single platform. And making it impossible to write robust, portable code :-( Note that most platforms have several libms and the behaviour even for a single libm can be wildly variable. It can also ENHANCE cross-language problems, where a user needs to use a library that expects a different libm or libm option. > Do note the flip side: to the extent that different platform > religions refuse to standardize libm endcase behavior, Python plays > along with whatever libm gods the platform it's running on worships. > That's of value to some too. Actually, no, it doesn't. Because Python doesn't support any libm behaviour other than the one that it was compiled with, and that is often NOT what is wanted. > So which one would you prefer? As explained, there are 3 plausible > candidates. > > You seem to be having some trouble taking "yes" for an answer here ;-) Actually, there are a lot more candidates, but let that pass. All I am saying is that there should be SOME defined AND SANE behaviour. While I would prefer an exception, I am not dogmatic about it. What I can't stand is completely undefined behaviour, as was introduced into Python by C99. > > What I was trying to point out is that the current behaviour is > > UNDEFINED (and may give total nonsense). That is not > > good. > > Eh -- I can't get excited about it. AFAIK, in 15 years nobody has > complained about passing a 0 modulus to math.fmod (possibly because > most newbies use the Windows distro, and it does raise ValueError > there). Some people write Python that is intended to be robust and portable; it is those people who suffer. > What Guido would rather do, which I agreed with, was to have > x.conjugate() simply return x when x is float/int/long. No change in > value, no change in type, and the obvious implementation would even > make ... Fine. I am happy with that. What I was pointing out that forcible changes of type aren't harmful if you remove the "gotchas" of loss of information with coercions that aren't intended to do so. 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 [View Less]

1 0

Re: [Python-Dev] Floor division
by Nick Maclaren Jan. 23, 2007

Jan. 23, 2007

"Tim Peters" <tim.peters(a)gmail.com> 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 with the opposite > sign on the imaginary part, whether or not that equals 0 (+0. and -0. > both "equal 0"). Grrk. Why? Seriously. IEEE 754 … [View More]signed zeroes are deceptive enough for float, but are a gibbering nightmare for complex; Kahan may be able to handle them, but mere mortals can't. Inter alia, the only sane forms of infinity for complex numbers are a SINGLE one (the compactified model) and to may infinity into NaN (which I prefer, as it leads to less nonsense). And, returning to 'floor' - if one is truncating towards -infinity, should floor(-0.0) deliver -1.0, 0.0 or -0.0? > math.fmod is 15 years old -- whether or not someone likes it has > nothing to do with whether Python should stop trying to use the > current integer-derived meaning of % for floats. Eh? No, it isn't. Because of the indirection to the C library, it is changing specification as we speak! THAT is all I am getting at; not that the answer might not be A math.fmod with defined behaviour. > On occasion we've added additional error checking around functions > inherited from C. But adding code to return a NaN has never been > done. If you want special error checking added to the math.fmod > wrapper, it would be easiest to "sell" by far to request that it raise > ZeroDivisionError (as integer mod does) for a modulus of 0, or > ValueError (Python's historic mapping of libm EDOM, and what Python's > fmod(1, 0) already does on some platforms). The `decimal` module > raises InvalidOperation in this case, but that exception is specific > to the `decimal` module for now. I never said that it should; I said that it is reasonable behaviour on systems that support them. I personally much prefer an exception in this case. What I was trying to point out is that the current behaviour is UNDEFINED (and may give total nonsense). That is not good. > >> For ints and floats, real could just return self, and imag could > >> return a 0 of the same type as self. 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? I'd rather not have to do that when > >> the input is an int or float, what do you think?) > > > I don't see the problem in doing that - WHEN implicit conversion > > to a smaller domain, losing information, raises an exception. > > Take it as a pragmatic fact that it wouldn't. Besides, e.g., the > conjugate of 10**50000 is exactly 10**50000 mathematically. Why raise > an exception just because it can't be represented as a float? The > exact result is easily supplied with a few lines of "obviously > correct" implementation code (incref `self` and return it). Eh? I don't understand. Are you referring to float("1.0e50000"), pow(10,50000), pow(10.0,50000), or a conjugate (and, if so, of what?) float(conjg(1.23)) obviously need not raise an exception, except possibly "Sanity failure" :-) 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 [View Less]

2 1

Re: [Python-Dev] Floor division
by Anders J. Munch Jan. 23, 2007

Jan. 23, 2007

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 go away for decimal floats in P3K too. What design error? float.__mod__ works perfectly. >>> -1 % 50 49 >>> -1.0 % 50.0 49.0 >>> It's only Decimal.… [View More]

2 1

Re: [Python-Dev] Eliminating f_tstate
by Delaney, Timothy (Tim) Jan. 23, 2007

Jan. 23, 2007

"Martin v. Löwis" wrote: > For Python 2.5, for compatibility, it probably has to remain > where it is, and only PyTraceBack_Here should stop using it. > As a consequence, a generator .send() makes exceptions > occur in the current thread, not in the thread where the > generator was created. > > What do you think? That's the behaviour I would expect. There is nothing I can find in either the Python docs nor PEP 342 to suggest that interactions with generators happen on … [View More]

1 0

Eliminating f_tstate
by "Martin v. Löwis" Jan. 23, 2007

Jan. 23, 2007

Bug #1579370 reports a crash when accessing the thread state of a terminated thread, when releasing a generator object. In analysing the problem, I found that f_tstate doesn't have much utility: it is used in very few places, and in these places, it might be as good or better to use the *current* thread state (rather than the frame's thread state); in some (most?) of these places, the current thread should be identical to the frame's thread, anyway. So I would like to propose that the … [View More]

3 2

syntax misfeature (exception)
by Neal Becker Jan. 22, 2007

Jan. 22, 2007

I accidentally wrote: try: ... except a,b: rather than: try ... except (a,b): It appears that the 1st example syntax is silently accepted, but doesn't seem to work. Is this true? If so, I'd say it's a wart.

5 6