liberty-eiffel
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]