[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Liberty-eiffel] user-friendly real constants
From: |
Raphael Mack |
Subject: |
Re: [Liberty-eiffel] user-friendly real constants |
Date: |
Sat, 03 Jan 2015 22:42:19 +0000 |
User-agent: |
Internet Messaging Program (IMP) H5 (6.2.1) |
Mh, yes and no.
One the one hand you are right, the behavior is not very nice, but the
problem I see here is to decide which type is "sufficient". While it
is surely possible in the compiler to do a decision, it is not obvious
for the programmer which is the correct one. Take the code
a := 1.2
should the compiler use 32 or 64 bit? This number is not exactly
representable by IEEE floting point numbers with 32 or 64 bits.
Closest values are
single: 1.2000000476837158203125E0
double: 1.19999999999999995559107901499E0
so clearly the 64-bit type is better, right? - Mh, probably not what
the programmer expected.
If you write
a := 1.5000000000
single precision is sufficient to encode it exactly, but when I change
this constant to
a := 1.5100000000
would I, as a programmer, expect it's type to change to REAL_64?
Considering only the absolute maximum range representable by REAL_32
() is also not the way to go, as the programmer might need the 64 bit
type due to accuracy not due to range requirements...
So in front of the expectation, that most Eiffel programs run on
machines with FPU and the REAL_64 arithmetics is not much slower than
REAL_32 and the trend is, that 32 bit types will become "unnatural" on
64-bit machines I don't think the current solution is the worst
choice...
Or if we want to support those who often use REAL_32 (or 80/128) bit
types we could make the default type for real constants configurable.
Cheers and a happy new year to all Eiffelers!
Rapha
Zitat von Laurie Moye <address@hidden>:
Hi,
Is this really the behaviour of a user friendly compiler:-
************************************************
class TEST_REAL
creation {ANY}
run
-------------------------------------------------------------------------------
feature {ANY} -- Public features
run is
local
r_32 : REAL_32
do
r_32 := 1.234
end
-------------------------------------------------------------------------------
end -- class TEST_REAL
************************************************
ceres/test_r32: compile test_real -o test_real
****** Fatal Error: Bad assignment. Cannot assign `1.234' which
is of type REAL_64 into `r_32' which is of type REAL_32.
The source lines involved by the message are the following:
Line 12 columns 4, 12 in TEST_REAL
(/home/laurie/lib/Eiffel/liberty/args/test_r32/test_real.e):
r_32 := 1.234
^ ^
------
Error occurs while compiling. Compilation process aborted.
************************************************
Shouldn't the compiler have a look at 1.234 to see what is the smallest
real that it will fit into, and seeing that it will fit into a REAL_32
put it into one so that it can be assigned to a REAL_32, then it can be
promoted if it has to be assigned to a REAL_64 or larger?
This seems to be what happens in the case of integers.
Best wishes,
Laurie