Path: utzoo!mnetor!uunet!mcvax!unido!ecrcvax!bruno From: bruno@ecrcvax.UUCP (Bruno Poterie) Newsgroups: comp.lang.prolog Subject: Re: Arithmetic problems with Quintus Prolog Message-ID: <523@ecrcvax.UUCP> Date: 14 Apr 88 08:15:41 GMT References: <11111@shemp.CS.UCLA.EDU> <869@cresswell.quintus.UUCP> Reply-To: bruno@ecrcvax.UUCP (Bruno Poterie) Organization: ECRC, Munich 81, West Germany Lines: 37 In article 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, ...