Re: [Python-Dev] [Python-checkins] buildbot failure in amd64 gentoo 2.5
>> 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. Good grief. If anyone has any bright ideas about simple ways to change that form to make it less vulnerable to the spambots, I'd be happy to incorporate them into Buildbot. sigh, -Brian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
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.__mod__ that's inconsistent. float.__mod__ has the usual floating-point inaccuracies, but then with float that goes with the territory. I've had occasion to use it, and it was a pleasant surprise that it "just worked", so I didn't have to go to the math module and ponder over the difference between modulo or remainder. float modulo is useful, consistent and intuitive; -1 on removing that. - Anders ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] buildbot failure in amd64 gentoo 2.5
On 23/01/2007 10.20, Brian Warner wrote: >>> 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. > > Good grief. If anyone has any bright ideas about simple ways to change that > form to make it less vulnerable to the spambots, I'd be happy to incorporate > them into Buildbot. I'd throw a CAPTCHA in. There are even some written in Python. -- Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
"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 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 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**5 is exactly 10**5 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.0e5"),
pow(10,5), pow(10.0,5), 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: [EMAIL PROTECTED]
Tel.: +44 1223 334761Fax: +44 1223 334679
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
[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 exactly representable as a float too. Those don't create problems for any definition of mod. But even non-tiny exact integers can. > It's only Decimal.__mod__ that's inconsistent. float.__mod__ has the > usual floating-point inaccuracies, but then with float that goes with > the territory. No. Decimal.__mod_ always returns the mathematically exact result. It has this in common with math.fmod() (in fact, math.fmod() and Decimal.__mod__() have the same definition, ignoring IEEE endcases). It's impossible to do so under Python's integer-derived mod definition. Read the whole thread for why -- we can't even guarantee that abs(a%b) < abs(b) for non-zero finite floats under the current mod, and that has in fact been a source of complaints over the years. math.fmod and Decimal.__mod__ do guarantee abs(a%b) < abs(b) for all non-zero finite floats, and moreover guarantee that a%b is an exact integer multiple of `b` away from `a` (although that integer may not be representable as a float) -- again it's impossible for the a - floor(a/b)*b definition to do so for floats. > I've had occasion to use it, and it was a pleasant surprise that it > "just worked", so I didn't have to go to the math module and ponder > over the difference between modulo or remainder. There's no such distinction in Python's math module -- fmod is the only modular reduction function in the math module. The `decimal` module has two such functions (see earlier messages in this thread for examples -- neither matches Python's mod function). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] buildbot failure in amd64 gentoo 2.5
Giovanni Bajo <[EMAIL PROTECTED]> writes: > On 23/01/2007 10.20, Brian Warner wrote: > 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. >> >> Good grief. If anyone has any bright ideas about simple ways to change that >> form to make it less vulnerable to the spambots, I'd be happy to incorporate >> them into Buildbot. > > I'd throw a CAPTCHA in. There are even some written in Python. I'd guess even the simplest thing would work: "Type "Python" into this box: __" Cheers, mwh -- ZAPHOD: Who are you? ROOSTA: A friend. ZAPHOD: Oh yeah? Anyone's friend in particular, or just generally well-disposed to people? -- HHGttG, Episode 7 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
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> explained in this thread (for the 27th time ;-)), that definition Tim> doesn't make good sense for floats Tim> Do note that this discussion is only about Python 3 Since Python 3 is about cleaning things up (at least in part) and Tim is telling us this is going to clean things up in this area, I'm +1 on this. Besides, I've found it's generally best to agree with Tim. ;-) Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] buildbot failure in amd64 gentoo 2.5
Brian> Good grief. If anyone has any bright ideas about simple ways to Brian> change that form to make it less vulnerable to the spambots, I'd Brian> be happy to incorporate them into Buildbot. Require a password? It can be widely known throughout each buildbot community with little danger of being guessed by a spambot. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
[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
>> 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. This is the current complex conjugate implementation:
static PyObject *
complex_conjugate(PyObject *self)
{
Py_complex c;
c = ((PyComplexObject *)self)->cval;
c.imag = -c.imag;
return PyComplex_FromCComplex(c);
}
Complicating that to make a special case of c.imag == 0 is simply
goofy without a /compelling/ reason to do so. As I read the C99
section on "conj", it's also their intent that the sign on the
imaginary part be flipped regardless of value.
> IEEE 754 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?
I'd leave a zero argument alone (for ceiling too), and am quite sure
that's "the right" 754-ish behavior.
>> 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.
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.
It's never been Python's intent to define all behavior here, and
largely because Python isn't a math-library development project. To
the extent that enough people care enough to standardize C's libm
endcase behavior across platforms, Python inherits that too. Not much
of an inheritance so far ;-)
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.
>> 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.
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 ;-)
> 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).
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**5 is exactly 10**5 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 r
Re: [Python-Dev] Floor division
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 in trouble - e.g. -1+1e100==1e100. I don't think -1%1e100 is all that worse. > > It's only Decimal.__mod__ that's inconsistent. float.__mod__ has the > > usual floating-point inaccuracies, but then with float that goes with > > the territory. > > No. Decimal.__mod_ always returns the mathematically exact result. I meant inconsistent with integers. People are familiar with the semantics of % on integers, because they use it all the time. % on float is a natural extension of that and hence unsurprising. % on Decimal is exact and correct, but surprising all the same. regards, Anders ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
[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 mod. But even non-tiny exact integers can. [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. This isn't like floating addition, where rounding errors /must/ occur at times. It's never necessary to suffer rounding errors for a mod function defined with floats in mind. Indeed, that's why the C standards define fmod the way they do, and why IBM's proposed standard for decimal floating arithmetic defines it the same way. Python's definition of mod makes great sense for integers, but doesn't generalize nicely. >>> It's only Decimal.__mod__ that's inconsistent. float.__mod__ has the >>> usual floating-point inaccuracies, but then with float that goes with >>> the territory. >> No. Decimal.__mod_ always returns the mathematically exact result. > I meant inconsistent with integers. While I was responding to your second sentence there, not your first. You can tell because I didn't say anything after your first sentence ;-) No, it's not always true that "with float [inaccuracies] goes with the territory". mod "should be" like absolute value and unary minus this way: always exact. > People are familiar with the semantics of % on integers, because they use > it all the time. I'm not sure how many people are actually familiar with the semantics of integer % when mixing signs, in part because there's no consistency across languages in that area so people with a lot of experience tend to avoid it. I agree integer % is heavily used regardless. > % on float is a natural extension of that and hence unsurprising. It was natural to /want/ to extend it to floats. That didn't work well, and to the contrary it's surprising precisely /because/ the behavior people enjoy with integers can fail when it's applied to floats. Having cases where abs(a%b) >= abs(b) is a crash-the-space-shuttle level of surprise, especially since I know of no other language in which that's possible. It's not possible with ints or longs in Python either -- or with math.fmod applied to floats. > % on Decimal is exact and correct, but surprising all the same. 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 to look up in the docs, a user can read about what they're getting. In fact, I expect the decimal module's "remainder-near" is what most people using mod on floats actually want most of the time: they couldn't care less about the sign of the result, but they do want its absolute value to as small as possible. This is because floating mod's one "natural" mixed-sign use is for argument reduction before feeding the remainder into a series expansion. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] buildbot failure in amd64 gentoo 2.5
Michael Hudson wrote: > Giovanni Bajo <[EMAIL PROTECTED]> writes: > >> On 23/01/2007 10.20, Brian Warner wrote: >> > 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. >>> Good grief. If anyone has any bright ideas about simple ways to change that >>> form to make it less vulnerable to the spambots, I'd be happy to incorporate >>> them into Buildbot. >> I'd throw a CAPTCHA in. There are even some written in Python. > > I'd guess even the simplest thing would work: > > "Type "Python" into this box: __" Allowing a project to define a question & answer should do the trick - essentially a password like Skip suggested, but with a reminder right there on the page: "Type this project's name in lowercase in this box: _" "Type the BDFL's first name in lowercase in this box: " "Type the branch name in this box: " etc. It's easier than a normal CAPTCHA because its OK to assume a lot more knowledge on the part of the intended audience. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
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" <[EMAIL PROTECTED]> wrote: > [TIm 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: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
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 to look up > in the docs, a user can read about what they're getting. While I agree with this, my only slight concern is that under 2.x (int/int)%(int) will work, while it will fail under 3.x, because int/int will return a float. Eh - we can always make 2.6 warn about the floatobject's __mod__ function being called if the -W py3k option is on, that gets us part of the way there. And if we have a "-3" option or the like that also turns on maximum 3.x compat, that will enable true division, producing the warning. Like I said, it's only a slight concern... -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
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 definition to floats, and for reasons > explained in this thread (for the 27th time ;-)), that definition > doesn't make good sense for floats. The IBM spec defines `remainder` > and `remainder-near` for floats, and those do make good sense for > floats. But they're /different/ definitions than Python uses for > integer mod. I knew the definition of IBM, but assumed (inmersed in my ignorance) that "remainder" was the way that standard float worked for __mod__. Now I know that it's not like that, :) > 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 "just" that a user would > have to get at "remainder" in a more long-winded way (analogous to We'll have to deprecate that functionality, with proper warnings (take not I'm not following the thread that discuss the migration path to 3k). And we'll have to add the method "remainder" to decimal objects (right now we have only "remainder_near" in decimal objects, and both "remainder" and "remainder_near" in context). Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Re: Floor division
>> 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 "just" that a user would >> have to get at "remainder" in a more long-winded way (analogous to [Facundo Batista] >We'll have to deprecate that functionality, with proper warnings (take >not I'm not following the thread that discuss the migration path to 3k). > >And we'll have to add the method "remainder" to decimal objects (right >now we have only "remainder_near" in decimal objects, and both >"remainder" and "remainder_near" in context). Whoa. This needs more discussion with respect to the decimal module. I'm not ready to throw-out operator access to the methods provided by the spec. Also, I do not want the Py2.x decimal module releases to be complexified and slowed-down by Py3.0 deprecation warnings. The module is already slow and has ease-of-use issues. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Re: Floor division
...
[Facundo]
>> We'll have to deprecate that functionality, with proper warnings (take
>> not I'm not following the thread that discuss the migration path to 3k).
>>
>> And we'll have to add the method "remainder" to decimal objects (right
>> now we have only "remainder_near" in decimal objects, and both
>> "remainder" and "remainder_near" in context).
[Raymond]
> Whoa. This needs more discussion with respect to the decimal module. I'm
> not ready to throw-out operator access to the methods provided by the spec.
decimal's __floordiv__ and __divmod__ have nothing to do with the
spec. They were Python-specific extensions apparently added to try to
fit in better with Python's entirely different (than either of
decimal's) definition of modular reduction. In that respect they
succeeded by being jarringly perverse: decimal's __floordiv__(a, b)
does not return the floor of a/b, it returns a/b truncated toward 0:
>>> -1 // 10
-1
>>> Decimal(-1) // Decimal(10)
Decimal("-0")
Even you might agree that's an odd thing for a function named "floor
div" to do ;-)
I say that's not useful. The only method here that does have
something to do with the spec is decimal's __mod__, an implementation
of the spec's "remainder" operation. Guido agreed last May to take
away the "%" infix spelling of mod for binary floats, and I can't
think of a reason for why decimal floats should be immune.
> Also, I do not want the Py2.x decimal module releases to be complexified
> and slowed-down by Py3.0 deprecation warnings. The module is already slow
> and has ease-of-use issues.
We're not talking about the usual arithmetic operations here, just
"%". The functionality wouldn't go away, just the infix 1-character
spelling. Note that the implementation of "remainder" is
extraordinarily expensive, just as the implementation of fmod for
binary floats is extraordinarily expensive: it's not just the
precision at work, but also the difference in exponents.
+ - * / don't have the latter factor to contend with (hence
"extraordinarily"). Couple this with that floating mod of any kind is
almost surely rarely used, and worry about the overhead of a method or
function spelling seems a waste of tears.
Irony: I've used decimal's remainder_near in real life, which has no
operator spelling. I haven't used decimal's `remainder` except to
give examples in this thread :-)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Object creation hook
Hello there. I am trying to insert a hook into python enabling a callback for all just-created objects. The intention is to debug and find memory leaks, e.g. by having the hook function insert the object into a WeakKeyDictionary. I have already added a method to "object" to set such a hook, and "object_new" now calls it upon completion, but this is far from covering all places. Initially, I thought object_init were the place, but almost no classes call object.__init__ from their __init__ method. Then there is the separate case of old-style classes. Any suggestions on how to do a global object creation hook in python? Kristján ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
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 clear enough. My surprize was not that a % b was equal to b in this case, and so not strictly smaller than b (because I expect such things when working with floats). My surprize was that Decimals don't even try to be between 0 and b, and sometimes give a result that is far outside the range. This surprized me because I expected floats and Decimals to try to give "approximately equal" results... A bientot, Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
[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 is computed or it doesn't: If it makes a difference, because the first operand may be negative, then the programmer absolutely has to choose the correct function, or the program will have a bug. If the correct function is one whose result cannot be exactly represented, then there's nothing that can be done about that. Whether the function is called using a % infix operator or using math.untrustworthy_intlike_fmod doesn't change the fact that the result is going to be inexact. If it doesn't make a difference, because the first operand is always positive, then both functions provide exactly representable results. So regardless, the current float.__mod__ doesn't create inexact results where exact results are possible. Suppose for example I'm normalising radians to the [0; 2*math.pi] range using radians %= 2*math.pi Changing that to radians = math.fmod(radians, 2*math.pi) would simply be incorrect. I could of course rewrite that to give the correct result with a conditional and a bit more calculation, still using math.fmod, but then the inexactness would reappear. > It was natural to /want/ to extend it to floats. That didn't work > well, and to the contrary it's surprising precisely /because/ the > behavior people enjoy with integers can fail when it's applied to > floats. What makes you say it didn't work well? What user experiences do you base that on? - Anders ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Floor division
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 that it was compiled with, and that is >often NOT what is wanted. If you care (and know) enough to want a specific behavior on dubious output, then you know more about your specfic problem then python ever could. If you can go on to say "and this platform libm is wrong, but the other one over there is right", then you can probably recompile. > 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. If not, there is no way to get robust and portable; it is just a matter of which users you annoy. I could understand "throw an error, and *make* them choose a model if they want to process bad data", but that isn't really any easier to for a user to fix than the current non-model. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Floor division
"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 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: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problem with signals in a single threaded application
Hi,
I'm aware of the problems with signals in a multithreaded application,
but I was using signals in a single-threaded application and noticed
something that seemed wrong. Some signals were apparently being lost,
but when another signal came in the python handler for that "lost"
signal was being called.
The problem seems to be inside the signal module. The global variable
is_tripped is incremented every time a signal arrives. Then, inside
PyErr_CheckSignals() (the pending call that calls all python handlers
for signals that arrived) we can return immediately if is_tripped is
zero. If is_tripped is different than zero, we loop through all
signals calling the registered python handlers and after that we zero
is_tripped. This seems to be ok, but what happens if a signal arrives
after we've returned from its handler (or even after we've checked if
that signal arrived) and before we zero is_tripped? I guess we can
have a situation where is_tripped is zero but some Handlers[i].tripped
are not. In fact, I've inserted some debugging output and could see
that this actually happens and then I've written the following test
program to reproduce the problem.
#!/usr/bin/env python2.5
import sys
import os
import time
import signal
def alarm_handler(*args):
sys.stderr.write('alarmmm!\n')
def sigio_handler(*args):
sys.stderr.write('Entering SIGIO handler\n')
os.kill(os.getpid(), signal.SIGALRM)
sys.stderr.write('Leaving SIGIO handler\n')
signal.signal(signal.SIGIO, sigio_handler)
signal.signal(signal.SIGALRM, alarm_handler)
os.kill(os.getpid(), signal.SIGIO)
ini = time.time()
while True :
if time.time() - ini > 3.0:
sys.stderr.write('Loop!\n')
ini = time.time()
When we run this program, the handler for the SIGALRM isn't called
after we return from the SIGIO handler. We return to our main loop
and print 'Loop!' every 3 seconds aprox. and the SIGALRM handler is
called only when another signal arrives (like when we hit Ctrl-C).
I've read some threads about signals in the archives and I was under
the impression signals should work reliably on single-threaded
applications. Am I right? I've thought about a way to fix this, but I
don't know what is the current plan for signals support in python, so
what can be done?
Best regards,
-- Ulisses
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] compex numbers (was Floor Division)
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] compex numbers (was Floor Division)
"Jim Jewett" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Object creation hook
On 1/23/07, Kristján V. Jónsson <[EMAIL PROTECTED]> wrote: > Hello there. > > I am trying to insert a hook into python enabling a callback for all > just-created objects. The intention is to debug and find memory leaks, e.g. > by having the hook function insert the object into a WeakKeyDictionary. > > I have already added a method to "object" to set such a hook, and > "object_new" now calls it upon completion, but this is far from covering all > places. Initially, I thought object_init were the place, but almost no > classes call object.__init__ from their __init__ method. Then there is the > separate case of old-style classes. > > > > Any suggestions on how to do a global object creation hook in python? When I've used such things in the past, I usually had some idea which classes I was interested in targeting. I used a metaclass for doing the tracking, and either invoked it on individual classes, or used __metaclass__ = X to apply it (something like "class object(object): __metaclass__ = X" would do the try for new-style class that inherit from object directly). -Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
[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 points :-) > My surprize was not that a % b was equal to b in this case, and > so not strictly smaller than b (because I expect such things when > working with floats). That's unnecessarily pessimistic: there's no problem defining modular reduction for floats that's exact. > My surprize was that Decimals don't even try to > be between 0 and b, and sometimes give a result that is far outside the > range. This surprized me because I expected floats and Decimals to try > to give "approximately equal" results... Sure, you do expect that, and sure, they don't. Now what? The `decimal` module is an implementation of IBM's proposed standard for decimal arithmetic: http://www2.hursley.ibm.com/decimal/ It requires two mod-like operations, neither of which behave like Python's "number theoretic" mod. Nobody involved cared to extend the proposed standard by adding a third mod-like operation. 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-theoretic mod is not part of the proposed standard, is a poor basis for a floating-point mod regardess, and it was a mistake to implement decimal % decimal in a way so visibly different from float % float and integer % integer: it confuses the meaning of "%". That's your complaint, right? My preferred "solution" is to remove __mod__, __divmod__, and __floordiv__ from all flavors of floats (both binary and decimal) in P3K. That addresses your concern in that "decimal % decimal" would raise an exception in P3K (it wouldn't be implemented). A user who wanted some form of decimal float modular reduction would need to read the docs, decide which of the two supported such functions they want, and explicitly ask for it. Similarly, a user who wanted some from of binary float modular reduction would need to invoke math.fmod() explicitly -- or, possibly, if someone contributes the code needed to implement C99's additional "remainder" function cross-platform, that too: IBM's spec same-as C -- - remainder fmod (C89 & C99) remainder-near remainder (C99 & IEEE-754) It's not a coincidence that all standards addressing modular reduction for floats converge on essentially those two definitions. I can't be made to feel guilty about this :-) For P2 I don't propose any changes -- and in which case my only response is just "sure - yes - right - decimal's __mod__ in fact does not act like Python's integer __mod__ in mixed-sign cases -- and neither does decimal's __floordiv__ or decimal's __divmod__ act like their integer counterparts in mixed-sign cases". ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Object creation hook
Kristján V. Jónsson wrote: > Hello there. > > I am trying to insert a hook into python enabling a callback for all > just-created objects. The intention is to debug and find memory leaks, > e.g. by having the hook function insert the object into a WeakKeyDictionary. > > I have already added a method to “object” to set such a hook, and > “object_new” now calls it upon completion, but this is far from covering > all places. Initially, I thought object_init were the place, but almost > no classes call object.__init__ from their __init__ method. Then there > is the separate case of old-style classes. > > I suppose there's no requirement on C-defined types to actually call object_new, so you will need to audit them and make sure they do. PyClass_New in classobject.c is another obvious place - the creation of old-style instances doesn't appear to involve object_new. > > Any suggestions on how to do a global object creation hook in python? > Nothing other than the above. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
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, 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 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 should be allowed to be complex too, though, it's hard to imagine. -- g ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Object creation hook
Kristján V. Jónsson schrieb: > I am trying to insert a hook into python enabling a callback for all > just-created objects. The intention is to debug and find memory leaks, > e.g. by having the hook function insert the object into a WeakKeyDictionary. I'd like to point out that this isn't a python-dev question, but more appropriate for comp.lang.python (as it is of the "how do I x with Python?" kind). I would use a debug build, and use sys.getobjects to determine all objects and find leaks. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with signals in a single threaded application
On Tue, Jan 23, 2007, Ulisses Furquim wrote: > > I've read some threads about signals in the archives and I was under > the impression signals should work reliably on single-threaded > applications. Am I right? I've thought about a way to fix this, but I > don't know what is the current plan for signals support in python, so > what can be done? For starters, please post a bug report to SF so that this issue doesn't get lost. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Help a hearing-impaired person: http://rule6.info/hearing.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compex numbers (was Floor Division)
> 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 quite. >>> complex(1,1j) 0j >>> complex(0,1j) (-1+0j) So it moves the imaginary portion of the "imag" argument into the real part of the result with change of sign, on the basis that 1j*1j == -1. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with signals in a single threaded application
Ulisses Furquim schrieb: > I've read some threads about signals in the archives and I was under > the impression signals should work reliably on single-threaded > applications. Am I right? I've thought about a way to fix this, but I > don't know what is the current plan for signals support in python, so > what can be done? I agree it's a bug, and I agree with your proposed analysis. Please try to come up with a patch (e.g. by putting a while(is_tripped) loop around the for loop). Also make sure you include test case. Thanks for contributing, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
