RE: Float error, OnLine 7.23

It absolutely should not matter whether the RHS of the assignment is 0 or 0.0; the result in the variable in the LHS should be identical. If the value was more obscure than 0, such as containing decimal fractions, it might make a difference whether the value was converted into a C double literal or into a decimal in some shape or form. If the result of assigning 0 and 0.00 is different, that is evidence of a bug, in and of itself. Yours, Jonathan Leffler (jleffler@visa.com) #include <bother.ms-exchange.h> >---------- From: Randy L. Cross[SMTP:rcross@fssd.fssc.k12.ar.us] >Sent: Wednesday, April 15, 1998 1:39 PM >On 15 Apr 98 at 9:55, Leffler, Jonathan wrote: >>> From: Christian Winterhager[SMTP:christian.winterhager@orbit.de] >>> Sent: Wednesday, April 15, 1998 1:10 AM >>> We have moved to OnLine 7.23 UC6 (from Online 5.01), 4GL 6.05 UD1 >>> (RDS), and all our 4GL-Programs now stop at the following statements: >>> DEFINE x FLOAT, y DECIMAL(6,2) >>> LET y = 0 >>> LET x = y >> After this, we get Error 1223. >> The problem is in I4GL, not in OnLine per se. >> The error is 'value will not fit in a FLOAT', which leads one to question >> what value is in y. Given that you're using p-code rather than c-code, it >> is more difficult to debug what's going on. Do you have c-code? If so, >> does it work? What about if you add 'WHENEVER ANY ERROR STOP' to it (which >> is how p-code runs)? If the c-code also breaks with the W.A.E.S set, then >> you could send me the c-code which is generated for the statements above >> enclosed in MAIN and END MAIN - a minimal test case. >I don't know if this has anything to do with it, but we have noticed >different behaviors in some cases with decimal types using or not >using a decimal point. >LET y = 0 then using y in a comparison (or something) yields a >different result than LET y = 0.00 >Seems as if it shouldn't, but 4GL isn't the only language I've encountered this in.