If the decision comes to be that int(float) should be blessed as a correct way to truncate a float, I'd agree with Raymond that trunc() is just duplication and should be eliminated.
Yay, we've make progress!
I'd,of course, rather have a spelling that says what it means. :)
I wouldn't fret about this too much. Intrepreting int(f) as meaning truncate has a *long* history in *many* programming languages. It is a specious argument int(f) is ambiguous. No one thinks it means ceil(f). Go ask a dozen people if they are surprised that int(3.7) returns 3. No one will be surprised (even folks who just use Excel or VB). It is foolhardy to be a purist and rage against the existing art: SQL: "The INT() function returns its numeric argument with any fractional digits removed and truncates all digits to the right of the decimal point." www.basis.com/onlinedocs/documentation/b3odbc/bbjds_int_function.htm VB: "Both the Int and Fix functions remove the fractional part of Number and return the resulting integer value." http://msdn2.microsoft.com/en-us/library/xh29swte.aspx Excel: "The Int function returns the integer portion of a number." http://www.techonthenet.com/excel/formulas/int.php These docs suggest where the thinking has gone wrong. Writing int(f) doesn't mean "arbritrary select one of round|ceil|floor|trunc as a way of getting to an integer"; instead, it means "return the integer portion (non-fractional component) of a number." The latter definition seems common and is entirely unambiguous. Raymond
Does no-one thinks it means round(f) either? That's the main confusion here (plus the fact that in C it's undefined -- or at some point was undefined). BTW the list of functions considered here should include round() in addition to ceil(), floor(), and trunc(), even if 2-arg round() doesn't quite fit. --Guido On Jan 25, 2008 11:22 AM, Raymond Hettinger <python@rcn.com> wrote:
If the decision comes to be that int(float) should be blessed as a correct way to truncate a float, I'd agree with Raymond that trunc() is just duplication and should be eliminated.
Yay, we've make progress!
I'd,of course, rather have a spelling that says what it means. :)
I wouldn't fret about this too much. Intrepreting int(f) as meaning truncate has a *long* history in *many* programming languages. It is a specious argument int(f) is ambiguous. No one thinks it means ceil(f).
Go ask a dozen people if they are surprised that int(3.7) returns 3. No one will be surprised (even folks who just use Excel or VB). It is foolhardy to be a purist and rage against the existing art:
SQL: "The INT() function returns its numeric argument with any fractional digits removed and truncates all digits to the right of the decimal point." www.basis.com/onlinedocs/documentation/b3odbc/bbjds_int_function.htm
VB: "Both the Int and Fix functions remove the fractional part of Number and return the resulting integer value." http://msdn2.microsoft.com/en-us/library/xh29swte.aspx
Excel: "The Int function returns the integer portion of a number." http://www.techonthenet.com/excel/formulas/int.php
These docs suggest where the thinking has gone wrong. Writing int(f) doesn't mean "arbritrary select one of round|ceil|floor|trunc as a way of getting to an integer"; instead, it means "return the integer portion (non-fractional component) of a number." The latter definition seems common and is entirely unambiguous.
Raymond
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, Jan 25, 2008 at 11:32:54AM -0800, Guido van Rossum wrote:
Does no-one thinks it means round(f) either?
I don't think so. I often emulate round(f) as int(f + 0.5). Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Raymond Hettinger <python <at> rcn.com> writes:
Go ask a dozen people if they are surprised that int(3.7) returns 3. No one will be surprised (even folks who just use Excel or VB). It is foolhardy to be a purist and rage against the existing art:
Well, for what it's worth, here are MySQL's own two cents: mysql> create table t (a int); Query OK, 0 rows affected (0.00 sec) mysql> insert t (a) values (1.4), (1.6), (-1.6), (-1.4); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql> select * from t; +------+ | a | +------+ | 1 | | 2 | | -2 | | -1 | +------+ 4 rows in set (0.00 sec)
On Jan 25, 2008, at 1:22 PM, Raymond Hettinger wrote:
I wouldn't fret about this too much. Intrepreting int(f) as meaning truncate has a *long* history in *many* programming languages. It is a specious argument int(f) is ambiguous. No one thinks it means ceil(f).
Not that I think my opinion will have any weight in this discussion, but I'd agree that int has a long history not likely to be misinterpreted when applied to real numbers. Quoting from Graham, Knuth and Patashnik "Concrete Mathematics...2nd edition" page 67: "We start by covering the floor (greatest integer) and ceiling (least integer) functions, which are defined for all real x... ...some pocket calculators have an INT function, defined as floor(x) when x is positive and ceil(x) when x is negative. The designers of these calculators probably wanted their INT function to satisfy the identity INT(-X) = -INT(X). But we'll stick to our floor and ceiling functions, because they have even nicer properties than this." jared
Antoine Pitrou wrote:
Raymond Hettinger <python <at> rcn.com> writes:
Go ask a dozen people if they are surprised that int(3.7) returns 3. No one will be surprised (even folks who just use Excel or VB). It is foolhardy to be a purist and rage against the existing art:
Well, for what it's worth, here are MySQL's own two cents:
mysql> create table t (a int); Query OK, 0 rows affected (0.00 sec)
mysql> insert t (a) values (1.4), (1.6), (-1.6), (-1.4); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0
mysql> select * from t; +------+ | a | +------+ | 1 | | 2 | | -2 | | -1 | +------+ 4 rows in set (0.00 sec)
Two points. Firstly, regarding MySQL as authoritative from a standards point of view is bound to lead to trouble, since they have always played fast and loose with the standard for reasons (I suspect) of implementation convenience. Second, that example isn't making use of the INT() function. I was going to show you result of taking the INT() of a float column containing your test values. That was when I found out that MySQL (5.0.41, anyway) doesn't implement the INT() function. What was I saying about standards? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
On 25/01/2008, Guido van Rossum <guido@python.org> wrote:
Does no-one thinks it means round(f) either? That's the main confusion here (plus the fact that in C it's undefined -- or at some point was undefined).
Not me. My intuition agrees with Raymond that int means "the integer part of", i.e. trunc(), when dealing with a numeric argument. (int(string) is a different matter, and I have no problem having different intuitions for that. So sue me) I'd like to keep trunc (as math.trunc) for those cases where I want to be completely explicit, but it's not a big deal to me.
BTW the list of functions considered here should include round() in addition to ceil(), floor(), and trunc(), even if 2-arg round() doesn't quite fit.
My original message suggested that round go into math as well. It didn't get much comment, though, as everyone latched onto the more controversial suggestion that int(float) be an error - which is the bit I was least concerned about, ironically. Paul.
On 2008-01-25 21:26, Steve Holden wrote:
Antoine Pitrou wrote:
Raymond Hettinger <python <at> rcn.com> writes:
Go ask a dozen people if they are surprised that int(3.7) returns 3. No one will be surprised (even folks who just use Excel or VB). It is foolhardy to be a purist and rage against the existing art:
Well, for what it's worth, here are MySQL's own two cents:
mysql> create table t (a int); Query OK, 0 rows affected (0.00 sec)
mysql> insert t (a) values (1.4), (1.6), (-1.6), (-1.4); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0
mysql> select * from t; +------+ | a | +------+ | 1 | | 2 | | -2 | | -1 | +------+ 4 rows in set (0.00 sec)
Two points. Firstly, regarding MySQL as authoritative from a standards point of view is bound to lead to trouble, since they have always played fast and loose with the standard for reasons (I suspect) of implementation convenience.
Second, that example isn't making use of the INT() function. I was going to show you result of taking the INT() of a float column containing your test values. That was when I found out that MySQL (5.0.41, anyway) doesn't implement the INT() function. What was I saying about standards?
FWIW, here's what IBM has to say to this: http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.... """If the argument is a numeric-expression, the result is the same number that would occur if the argument were assigned to a large integer column or variable. If the whole part of the argument is not within the range of integers, an error occurs. The decimal part of the argument is truncated if present.""" AFAIK, the INTEGER() function is not part of the SQL standard, at least not of SQL92: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt The way to convert a value to an integer is by casting it to one, e.g. CAST (X AS INTEGER). The INT() function is basically a short-cut for this. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 25 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
Hello,
Two points. Firstly, regarding MySQL as authoritative from a standards point of view is bound to lead to trouble, since they have always played fast and loose with the standard for reasons (I suspect) of implementation convenience.
To that I heartily agree. I was just pointing out that implicit conversion of float to int did not always use the moral equivalent of trunc() under all programming platforms. That said, I don't think it's that important, it's just something you have to learn. Regards Antoine.
"Guido van Rossum" <guido@python.org> wrote in message news:ca471dc20801251132j7a758bc5uc076e859dd9f84b0@mail.gmail.com... | Does no-one thinks it means round(f) either? Not me. Int should truncate, so trunc() not needed unless is does something different. And I would prefer the float-input-only converters be in math. There is nothing second-class, really, about functions in modules. Just more specific. tjr
Terry Reedy wrote:
"Guido van Rossum" <guido@python.org> wrote in message news:ca471dc20801251132j7a758bc5uc076e859dd9f84b0@mail.gmail.com... | Does no-one thinks it means round(f) either?
Not me. Int should truncate, so trunc() not needed unless is does something different.
Like returning a value of the same type as the input? int(), being a call to a type, should never return a value of another type. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
participants (9)
-
Antoine Pitrou -
Guido van Rossum -
Jared Flatow -
M.-A. Lemburg -
Oleg Broytmann -
Paul Moore -
Raymond Hettinger -
Steve Holden -
Terry Reedy