[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::pascal

Title:	DEC Pascal Notes
Notice:	See note 1 for kits. Bug reports to CLT::DEC_PASCAL_BUGS
Moderator:	TLE::REAGAN

Created:	Sat Jan 25 1986
Last Modified:	Tue Jun 03 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2675
Total number of notes:	13409

2669.0. "Alpha PASCAL, REAL data types fail to compare" by CSC32::D_SANFORD () Thu Apr 17 1997 18:23

    DEC Pascal V5.5-52
    OpenVMS Alpha V6.2

    This program works on an Alpha when compiled /NOOPTIMIZE, but fails 
    when /OPTIMIZE is used.  Additionally, when compiled with /OPTIMIZE 
    on a VAX, it works fine.

    This is typical of our processing to validate the state of our database.
    We are checking to see if the first three digits, along with the decimal, 
    are being represented in a string.

      - convert the string to a real
      - massage the database "real" value to omit all but the first three digits
      - compare the results

    In this example, the values should be the same.

    I tried this with DEC Pascal V5.4-41 on OpenVMS VAX V6.2 and even
    when compiled with /FLOAT=G_FLOAT worked.  Since this is not fixed
    decimal notation, I suspect these numbers are just close.

    In the example below, if the results are printed when the floats
    fail to compare.

    Regards, Drew Sanford
    Customer Support Center
    C970411-4930


[INHERIT    ('SYS$LIBRARY:STARLET')]

PROGRAM TEST (INPUT,OUTPUT);

VAR

R1 : [STATIC,VOLATILE]  REAL;
R2 : [STATIC,VOLATILE]  REAL;
R3 : [STATIC,VOLATILE]  REAL;

BEGIN

	READV ('36.6',R1);

	R2 := 36.625;

	R3 := TRUNC(R2 * 10.0) / 10.0;

	IF (R1 <> R3)
	THEN
	    BEGIN
		WRITELN ('R1 = ',R1);
		WRITELN ('R3 = ',R3);
		WRITELN ('');
		WRITELN ('R2 = ',R2);
	    END;

END.

T.R	Title	User	Personal Name	Date	Lines
2669.1		TLE::REAGAN	All of this chaos makes perfect sense	`Thu Apr 17 1997 20:32`	41
	Yeah, its just "close" numbers, but there is a little more to it. In all shipping versions of DEC Pascal, for /OPTIMIZE, the code generator does some transformations (like changing "divide by a constant" to "multiple by reciprical of constant"). These transformations might be detected by code which is accuracy sensitive. Starting with V5.5-56 (not shipping and not part of the current ECO in TIMA), we have changed the compiler so that the default optimization nolonger does these transformations. We have also added a /ASSUME=[NO]ACCURACY_SENSITIVE qualifier if you wish to restore the previous transformations. I've just verified that with the latest network kit (V5.5-57), I get: (hiyall)$ pascal x (hiyall)$ link x (hiyall)$ run x (hiyall)$ pascal/noopt x (hiyall)$ link x (hiyall)$ run x (hiyall)$ pascal/assume=noaccur x (hiyall)$ link x (hiyall)$ run x R1 = 3.66000E+01 R3 = 3.66000E+01 R2 = 3.66250E+01 This gets the behavior the customer is looking for. However, I'll point out that with floating numbers (as you know), numbers like 36.6 aren't exactly represented in hardware. For instance, 36.6 is actually 36.59999847412109375000 give or take. So, we can either get a network kit to the customer or wait until our next SSB kit (ships in August). Perhaps the customer would like to be a FT site for V5.6? We're looking for a few sites right now if they are interested. I wasn't planning on doing another TIMA ECO before the next network kit. -John
2669.2		WIBBIN::NOYCE	Pulling weeds, pickin' stones	`Fri Apr 18 1997 11:25`	2
	Also FYI, 36.625 is represented exactly (it's 293/8), and so is 366.25 (it's 1465/4).