Conference clt::dec_pascal_bugs

825.0. "Double Precision Negative Numbers?" by SNOFS1::ELEFTHERIOU () Sun Feb 09 1997 15:17

    Hi,
    
    Not being a pascal guru, I have a customer who believes he may have
    found a bug in the compiler.  The original problem was described as an
    inability to be able to declare a double precision number.  The sample
    code and description as supplied was:
    
    ========================================================================
    I can't seem to get any information on what appears to be a
    pascal compiler problem on lorien. The program I am writing
    requires at least 8 digit precision, and I cannot find a way
    to get more than 7 digit precision with the pascal compiler
    on lorien. I have changed the variable declaration from
    REAL to DOUBLE or QUADRUPLE but it does not seem to have any
    effect on the precision. According to the manuals the DOUBLE
    declaration should work. Here is a very simple pascal program
    that demonstrates the problem:
    
    program Design (Input, Output);
    
    var X : double;
    
    begin
       X:= 0.8;
       writeln(X:20:15);
    end.
    
    When I run this program it writes 0.800000011920929 instead of
    0.8000000000000000. This does not seem to be a problem when I
    compile this program on a sparcstation which leads me to
    beleive that it is an OSF compiler problem.
    ========================================================================
    
    To which an answer was provided in the form of declaring the variable
    like so:
    
    -------------------
    .
    ...displays as you describe.  If you force the representation of this
    number as a double by using the following:
    
    begin
       X:= 0.8d0;
       writeln(X:20:15);
    end.
    
    The number will be displayed as expected.  An additional run-time
    library containing portable math routines is available for the Alpha CPU's. 
    This is known as the Digital Portable Math Library (DPML).
    -----------------
    
    
    The customer has now written back advising he can not declare a
    constant as a double precision number when the number is negative. 
    Example description and code:
    ========================================================================
    
    
    (The customers words...)
    I got the message from the DEC people about the pascal compiler. I'm
    a bit disappointed that their compiler does not handle things better.
    I thought these sort of problems were solved by most compilers years
    ago - I guess that's not the case with DEC. I have found a related
    problem that I think is actually a bug. Perhaps we could pass this
    along as part of this same call.
    
    The problem is that you cannot create a negative constant in double
    precision. Here is an example:
    
    program Example (Input, Output);
    
    const
    {   lnEffZero         = - 161.18096d0;  this won't compile }
    {   lnEffZero         = 161.18096d0;  this will compile }
       lnEffZero          = - 161.18096; { this is not double precision }
    
    begin
       writeln(LnEffZero:30:20);
    end.
    
    Let me know if they think this is a bug.
    
    ===================================================================
    
    What is the behaviour that should be seen?
    
    Many thanks for any advise,
    
    Harry E.
    CSC-Sydney
    [n13719]
    

  Harry,
    That program compiles fine on OpenVMS/Alpha. What error does the OSF
  compiler generate?
						John Gillings, Sydney CSC

    1) We never heard about this customer's concern about double-precision
    numbers and having to use the "d" syntax.  I wonder who in Digital
    talked to them and what they were told?  While the the answer of
    "you must use the d0 syntax to get a double-precision constant",
    I'd like to understand the customer's needs and competetor's behavior.
    
    2) I took the program to my Digital UNIX machine.  The compilation
    got 2 unaligned access faults.  That is indeed a bug in the
    compiler.  However, unaligned access faults are just warnings.  
    The resulting a.out worked just fine for me.
    
    # a.out
         -161.18095999999999889951
    
    				-John

    I fixed the unaligned access faults for the double-precision constant
    expressions.
    
    				-John