https://bugzilla.wikimedia.org/show_bug.cgi?id=6068
Philippe Verdy <verd...@wanadoo.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WONTFIX |REMIND
--- Comment #51 from Philippe Verdy <verd...@wanadoo.fr> 2009-09-30 07:39:52
UTC ---
the INT_DIVIDE operator (idiv) is still wrong in the final patch, as it uses
the formula:
$stack[] = (int)($left / $right);
which overflows the too small capacity of ints.
Note that the parameters $left and $right can already be floatting points, so
the division results in a floatting point, but the typecast to (int) gets a
wrong result. Well, at least we could rewrite the formula using "floor(x/y)" in
templates instead of "x idiv y", and in that case, the way "idiv" works should
be either "floor(floor(x)/floor(y))" OR "(int)(x)/(int)(y)", but NOT the way as
it is written that mixes everything. But these two solutions would break
existing code that depend on "idiv" to continue getting the result from the
division of two floaating points without rounding them down to an integer
before the division.
For this reason, it should really be:
$stack[] = floor($left / $right);
However this would even change the behavior of "idiv" if the result of the
division is negative, because the typecast to int does not really uses floor,
but truncates towards zero. So the effective change should be:
$left = $left / $right;
$stack[] = ($left < 0) ? ceil($left) : floor($left);
This correction will preserve ALL result values that are already correct with
the current implementation (truncating the result of the floatting point
division to the nearest integer towards zero), but it will extend the usage of
"idiv" to cover a wider range of values than just the native binary integers.
I can't understand that implementers are not thinking about the coherence of
numeric operations and datatypes, when they finally implement things the wrong
way to solve a floating point problem : floatting points values are NOT
interchangeable with native integer values, and typecasts to (int) is a
wellknown source of bugs in many programs, because of lack of experience of
developpers !
I've seen such error frequently even in C or C++ where ALL variables types are
declared with float (or double), but with a formula using incorrectly a
typecast with (int) instead of "floor()". This same error occurs once again
here... When developing a software with global usage, I can assert that this
stupid bug is a result of incompetence (i.e. lack of training or experience).
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
