On 17 Nov 2011, at 20:51, Seth Grover wrote:
Notice that in x86_64, unless you explicitly cast the longword as a
double before the division, you get some sort of rounding error or
loss of precision.
http://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants
Jonas
On 2011-11-18 13:04, Jonas Maebe wrote:
http://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants
The description of the new behaviour should change then. The part that
says ...which doesn't cause data loss is now false, given Seth's
example. He lost precision compared to previous
On 18 Nov 2011, at 12:20, Graeme Geldenhuys wrote:
On 2011-11-18 13:04, Jonas Maebe wrote:
http://wiki.freepascal.org/
User_Changes_2.2.0#Floating_point_constants
The description of the new behaviour should change then. The part
that
says ...which doesn't cause data loss is now false,
On 11/18/2011 12:04 PM, Jonas Maebe wrote:
http://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants
Taking a look at the go language:
Here all constants are considered to be of arbitrary precision. This
also holds for integers !
A constant can be 101000 there.
Compiler
On 2011-11-18 13:37, Jonas Maebe wrote:
It says that the floating point *constant* (in Seth's example: 24.0) is
converted to the lowest precision that does not cause data loss.
My mistake, I read it wrong.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free
In a project I'm working on making platform portable, I was getting a
different answer for a calculation on i386 vs. x86_64. I boiled it
down to this:
===
program project1;
{$mode objfpc}{$H+}
uses
Classes,
SysUtils;
var
iHour : longword;
r64 : double;
begin
On 17 November 2011 21:51, Seth Grover sethdgrover@g wrote:
For what it's worth, in C (compiled with gcc) both
64-bit and 32-bit give the same (correct) answer, 733682.6250.
For what it's worth, a Java test (compiled under 64-bit Linux) also
gives the answer of 733682.6250.
--
Regards,
Am 17.11.2011 20:51, schrieb Seth Grover:
Although I can avoid the problem by casting the longword to a double
How should the compiler know that the division should be done using
double? Using always double slows down calculations. Because the range
of longword fits into a single as well as
