Integer/floating point type conversion in Prolog 
Author Message
 Integer/floating point type conversion in Prolog

[]
In your opinion, what is the proper behavior of the following code fragments?

        % Is type conversion is done before test?
        main1 :- a(1.0, 1).
        a(X, Y) :- X == Y, write(a), fail.
        a(X, Y) :- X = Y, write(b), fail.
        a(X, Y) :- X =:= Y, write(c), fail.

        % What about round-off errors?
        main2 :- X is (2.0/7.0)*7.0, Z is X - 2.0, write(Z), b(X, 2.0).
        b(X, Y) :- X == Y, write(a), fail.
        b(X, Y) :- X = Y, write(b), fail.
        b(X, Y) :- X =:= Y, write(c), fail.

To save you the work, here are the results for prologs we use:

        C-Prolog (version 1.5)
                main1:  abc
                main2:  0abc
        Quintus (VAX version 1.6 interpreted):
                main1:  c
                main2:  -1.9073e-06
        Quintus (VAX version 1.6 compiled):
                main1:  c
                main2:  0.0abc
        SB-Prolog (version 2.2 compiled)
                main1:  bc
                main2:  -0.000000b

As you can see, no one can agree on what the correct answers are!

So should type conversion be done before =/2 or ==/2?
Quintus says no, C-Prolog says yes, and SB-Prolog is in between.

Concerning round-off errors, Quintus compiled code probably
computes multi-operation expressions with full precision (and rounds
the answer), whereas execution time floating point is 29-bit for all
operations.  My opinion is that a program should produce identical
results, regardless of whether it is interpreted or compiled.
SB-Prolog uses an 'EPSILON' during unification to do a 'prettymuch_equal',
but I would think that anything that is '=/2' should also be '=:=/2'.

Thanks for your comments,
Bruce



Mon, 19 Apr 1993 21:43:00 GMT  
 Integer/floating point type conversion in Prolog
We are developing a quasi expert system to make a conceptual design
of a spacecraft. This involves a lot of data and rules at the
spacecraft mission level and at the subsystem(acs,power,comm,etc.)
level. We will also be keeping track of 'historical' info on spacecraft
that have already been launched.

The system is being written in Quintus Prolog, which is relatively new to
me. Is there some way to segment the data bases so that there are fewer
facts for the 'matcher' to plough through till it finds the appropriate
data?  I have been considering separating the data into different files
and only loading in what is needed to do the inferencing & calculations,
& then deleting it -- if I can figure out when to do that & hope the
overhead is less than the search time when all that info is in the
database at once.

I've implemented Sterling & Shapiro's symbolic equation solver with some
enhancements, but it is fairly slow on the substitution part. (By the way,
I recommend The Art of Prolog. It's been very useful.) I'm assuming that
is because there's so much data associated with each spacecraft, and for
simplicities sake I'm using the same format for most of the data. This
allows many routines to be used in many different situations, but there is
all that data!

Thanks for any help on this.

                April Gillam

                Aerospace Corp.



Mon, 19 Apr 1993 09:44:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Slow floating point to integer conversion in VC++ -- Pentium Pro/II

2. HELP: Fast Integer to Floating-Point Conversion on a Pentium

3. An alternative to floating point (was Re: Floating point non-exactness)

4. IBM 370 Floating point to IEEE floating point

5. floating point number into integer -JavaScript

6. Looking to license integer and floating point arithmetic cores

7. Floating point and integer input and output

8. Problem with storing floating point numbers as integers

9. integers or floating point?

10. How many floating-point numbers are integers?

11. integers vs floating point

12. checking if a floating point number is equal in value to an integer

 

 
Powered by phpBB® Forum Software