🚀 go-pugleaf

In article <pQ_:u[!@sea.sm.unisys.com> eggert@sea.sm.unisys.com (Paul Eggert) writes:
[deleted]
>	If a number can be exactly represented in both floating point and
>	integer formats, then use integer format.

While this rule may be acceptable for *formatted output* (cf. printf("%g")),
it is less than acceptable for internal representation and computation.
Remember, prolog objects are typed, so this implies type checking and conversion
in all arithmetic operations. Depending on the implementation, this may lead to
different truncations depending on the direction of conversion (due to the
possibly different numbers of bits left for the value, etc...), which could lead
to a modification of the value after twice converting.

[deleted]
>This rule matches most people's intuition better than Quintus's conversion
>rules.  It's not as fast as Quintus's arithmetic, but if you prize correct
>answers over fast ones, you will insist on overflow checking anyway, and you
>may find that a cheap test for the question "Is the number X exactly
>representable in integer format?" folds naturally into overflow checking.

It would be interesting to know *most people's intuition* more precisely.
My own idea on the subject is that an integer is not the same thing than a
floating point number, which is itself an approximation of a real number.
Using explicit conversions when needed:
	Y is float(50)
	Y is floor(0.5e1)
is at least as clear as implicit conversion, certainly as correct if not more
[because the answer to your "cheap test" is implementation and hardware 
 dependant, so the request ?- 1000000000 = 1000000000.0 . would get different
 answers on different systems], and has furthermore the triple advantage of:
	1- allowing your system to generate rather optimised and compact code
	   by using for example directly immediate floating-point resp. integer
	   machine instructions and by avoiding to call generic conversions.
	2- easing the job of an automatic program-checker in issuing warnings
	   about badly choosen arithmetic operations, incompatible arguments,...
	3- increasing the efficiency of an automatic program-transformer in
	   expression reduction, constant propagation, pre-unification, ...