Mailman 3 August 2006 - Python-Dev

Re: [Python-Dev] Rounding float to int directly ...
by Nick Maclaren 03 Aug '06

03 Aug '06

Ka-Ping Yee <python-dev(a)zesty.ca> wrote: > > That's my experience as well. In my opinion, the purpose of round() > is most commonly described as "to make an integer". So it should > yield an integer. Grrk. No, that logic is flawed. There are algorithms where the operation of rounding (or truncation) is needed, but where the value may be larger than can be held in an integer, and that is not an error. If the only rounding or truncation primitive converts to an integer, those algorithms are unimplementable. You need at least one primitive that converts a float to an integer, held as a float. Which is independent of whether THIS particular facility should yield an integer or float! 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

segmentation fault in Python 2.5b3 (trunk:51066)
by Ralf Schmitt 03 Aug '06

03 Aug '06

Hi all, I've been trying to port our software to python 2.5. unfortunately I'm getting constantly hit by segfaults. I've boiled it down to the following code: rs@schrotti:~/bug$ cat t.py import array class Indexer(object): maximumForwardSize = property(array.array.fromstring) rs@schrotti:~/bug$ python t.py Segmentation fault rs@schrotti:~/bug$ python Python 2.5b3 (trunk:51066, Aug 3 2006, 13:18:16) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> [18733 refs] [7182 refs] rs@schrotti:~/bug$ gdb python GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) r t.py Starting program: /home/rs/exp/bin/python t.py [Thread debugging using libthread_db enabled] [New Thread -1210304832 (LWP 21660)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210304832 (LWP 21660)] 0x0811b68a in visit_decref (op=0xb7db21d8, data=0x0) at Modules/gcmodule.c:270 270 if (PyObject_IS_GC(op)) { (gdb) bt #0 0x0811b68a in visit_decref (op=0xb7db21d8, data=0x0) at Modules/gcmodule.c:270 #1 0x0814043d in property_traverse (self=0xb7d7b5b4, visit=0x811b654 <visit_decref>, arg=0x0) at Objects/descrobject.c:1235 #2 0x0811b753 in subtract_refs (containers=0x8197d88) at Modules/gcmodule.c:295 #3 0x0811c453 in collect (generation=2) at Modules/gcmodule.c:790 #4 0x0811cf76 in PyGC_Collect () at Modules/gcmodule.c:1264 #5 0x0810d5da in Py_Finalize () at Python/pythonrun.c:377 #6 0x08057556 in Py_Main (argc=2, argv=0xbfb5a6f4) at Modules/main.c:516 #7 0x080565ba in main (argc=2, argv=0xbfb5a6f4) at ./Modules/python.c:23 (gdb)

6 7

Rounding float to int directly (Re: struct module and coercing floats to integers)
by Jim Jewett 03 Aug '06

03 Aug '06

Greg Ewing wrote: > The time isn't the main issue. The main issue > is that almost all the use cases for round() > involve doing an int() on it afterwards. At > least nobody has put forward an argument to > the contrary yet. Or, more accurately, they *should* involve an int afterwards, but often don't, because people expect round(something) to produce an integer. Looking only at the one-argument round() calls not surrounded by int(), I would bet that most are bugs rather than intentional. The proportion is certainly high enough that I can't just trust it. Ron Adam wrote: > I think you are only considering part of the usefulness of round(). In > statistics and science math equations, rounding isn't used to get an > integer, but instead used to give an answer that is meaningful within > the margin of error of the data being used. Yes, but (1) Only for display (or storage). This rounding should explicitly not be done on intermediate values, as it introduces another source of error. (2) You need to pass the precision, so this isn't the one-argument round(). (3) As a side note, even the two-argument round may not be what you want; it isn't uncommon to have accuracy to a number of significant figures, rather than to an absolute "three places past the decimal point". This gets complicated enough that it is reasonable to use math.fround() or some such instead of a builtin. -jJ

1 0

Re: [Python-Dev] Rounding float to int directly ...
by Nick Maclaren 03 Aug '06

03 Aug '06

James Y Knight <foom(a)fuhm.net> wrote: > > I'd be happy to see floats lose their __int__ method entirely, > replaced by an explicit truncate function. Come back Algol - all is forgiven :-) Yes, indeed. I have favoured that view for 35 years - anything that can lose information quietly should be explicit. tanzer(a)swing.co.at (Christian Tanzer) wrote: > Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > > > What's the feeling about this? If, e.g. int() > > were changed in Py3k to round instead of truncate, > > would it cause anyone substantial pain? > > Gratuitous breakage! > > I shudder at the thought of checking hundreds of int-calls to see if > they'd still be correct under such a change. My experience of doing that when compilers sometimes did one and sometimes the other is that such breakages are rarer than the conversions to integer that are broken with both rules! And both are rarer than the code that works with either rule. However, a 5% breakage rate is still enough to be of concern. 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] Rounding float to int directly ...
by Nick Maclaren 03 Aug '06

03 Aug '06

Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > > You should NOT be using binary floats for money > in the first place. Or floating-point at all, actually. But binary floating-point is definitely unsuited for such a use. > Pseudo-rounding to decimal places is not > the right way to do that. The right way is > to compare the difference to a tolerance. Right. Where the tolerance should be a combination of relative and absolute accuracy. 1.0e-300 should usually be 'similar' to 0.0. Simon Burton <simon(a)arrowtheory.com> wrote: > > It's not even clear to me that int(round(x)) is always the > nearest integer to x. There is a sense in which this is either true or overflow occurs. > Is it always true that float(some_int)>=some_int ? (for positive values). > > (ie. I am wondering if truncating the float representation > of an int always gives back the original int). No. Consider 'standard' Python representations on a 64-bit system. There are only 53 bits in the mantissa, but an integer can have up to 63. Very large integers need to be rounded, and can be rounded up or down. Please note that I am not arguing against an int_rounded() function. There is as much reason to want one as an int_truncated() one, but there is no very good reason to to want more than one of the two. int_expanded() [i.e. ceiling] is much less useful. For people interested in historical trivia, the dominance of the truncating form of integer conversion over the rounding form seems to be yet another side-effect of the Fortran / IBM 370 dominance over the Algol / other hardware, despite the fact that most modern languages are rooted in CPL rather than Fortran. I am unaware of any technical grounds to prefer one over the other (i.e. the reasons for wanting each are equally balanced). It all comes down to the simple question "Do we regard a single primitive for int(round()) as important enough to provide?" I abstain :-) 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

3 2

Re: [Python-Dev] Rounding float to int directly ...
by Michael Chermside 03 Aug '06

03 Aug '06

Greg Ewing writes: > [I propose for Py3k that] builtin round() > to return an int, and have something somewhere > else, such as math.fround(), for round-to-float. +1. The need to convert float to int is pervasive. The need to round (binary) floats to integer (or other decimal) floats is _much_ less common. Furthermore, the need for "round to nearest int" is much more common than the need for "integer floor" (although as pointed out, each could be defined in terms of the other except for certain rules for rounding exact halves). And most telling of all, if I were to stop 10 random programmers on the street, most of them not familiar with Python, and ask them to guess what the function named "round" did, I'm guessing the majority would think of float-to-int. It's a nice feature of Python that "it just works". Marc-Andre Lemburg writes: > You often have a need for controlled rounding when doing > financial calculations or [other reason snipped] Hmm. Not in the banks _I_ have worked at! We *never* use binary floating point for money. The decimal class is fairly useful in that regard. Nick Maclaren write: > Decimal doesn't even help people who care about accuracy. Not true! The float class is incapable of maintaining 700 digits of precision, but Decimal handles it just fine. (Why you would WANT more than around 53 bits of precision is a different question, but Decimal handles it.) > People who care about the accuracy of calculations prefer binary, > as it is a more accurate model. Huh? That doesn't even make sense! A model is not inherently accurate or inaccurate, it is only an accurate or inaccurate representation of some "real" system. Neither binary nor decimal is a better representation of either rational or real numbers, the first candidates for "real" system I thought of. Financial accounting rules tend to be based on paper-and-pencil calculations for which decimal is usually a far better representation. If you had said that binary floats squeeze out more digits of precision per bit of storage than decimal floats, or that binary floats are faster because they are supported by specialized hardware, then I'd go along, but they're not a "better model". -- Michael Chermside

4 4

Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)
by Simon Burton 03 Aug '06

03 Aug '06

On Wed, 2 Aug 2006 07:21:02 -0400 "Chermside, Michael" <mchermside(a)ingdirect.com> wrote: > > You wrote: > > (ie. I am wondering if truncating the float representation > > of an int always gives back the original int). > > Yes it does, because all integers that can be expressed as floats > can be expressed EXACTLY as floats. Yes, OK this makes sense. My point is that, regardless of this answer, as a python user I should not be worried by such details. At least: the doc string for round() should be expanded to mention the int(round(x)) use case. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 2 6249 6940 http://arrowtheory.com

1 0

Bad interaction of __index__ and sequence repeat
by Armin Rigo 02 Aug '06

02 Aug '06

Hi, There is an oversight in the design of __index__() that only just surfaced :-( It is responsible for the following behavior, on a 32-bit machine with >= 2GB of RAM: >>> s = 'x' * (2**100) # works! >>> len(s) 2147483647 This is because PySequence_Repeat(v, w) works by applying w.__index__ in order to call v->sq_repeat. However, __index__ is defined to clip the result to fit in a Py_ssize_t. This means that the above problem exists with all sequences, not just strings, given enough RAM to create such sequences with 2147483647 items. For reference, in 2.4 we correctly get an OverflowError. Argh! What should be done about it? A bientot, Armin.

10 26

FW: using globals
by Werkhoven J.P. van (Sjaak) 02 Aug '06

02 Aug '06

> Hi, > > I have got a problem with importing global variables. For instance I have > got two files: > > # t1.py #t2.py > > counter = 1 > > def counter_adder(filenr): def > show_adder(): > global counter import > t1 > counter+= 1 > print("adder is %d" % t1.counter) > if filenr == 1: > show_adder() > else: > import t2 > t2.show_adder() > > def show_adder(): > print("adder is %d" % counter) > > >>counter_adder(1) > adder is 2 > >>counter_adder(2) > adder is 1 > > When I look at the outcome of two function calls I expected no differences > but much to my surprise it goes wrong when the global variable is > imported. It doesn't give the updated value but the value it get when > instantiated. Who come? What should I do to get the updated value > > greetings, > > Sjaak van Werkhoven > > ****************************DISCLAIMER*********************************** Deze e-mail is uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. Fortis sluit iedere aansprakelijkheid uit die voortvloeit uit electronische verzending. This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). Fortis rules out any and every liability resulting from any electronic transmission. ******************************************************************************

2 1

Re: [Python-Dev] Rounding float to int directly ...
by Michael Chermside 02 Aug '06

02 Aug '06

Nick Maclaren: > The "wobbling precision" effect may be overstated, > but is real, and gets worse the larger the base is. To the best of my > knowledge, that is almost the only way in which binary is more accurate > than decimal, in absolute terms, and it is a marginal difference. Okay, that makes sense. However, if I understand "wobbling precision" correctly (and it's a BIG if) then it refers to the fact that interpolating from the last digit of precision doesn't work so well (intentionally vague phrase). So I would think (but could be wrong) that it is always trumped by adding another digit of precision to your numbers / lookup tables / whatever. If so, then even more credit needs to be given to the system that supports adjustable precision (the Decimal module). -- Michael Chermside

1 0