Re: UniBasic code that should work


"Mike Preece" <michael@xxxxxxxxxx> wrote in message
news:1143604482.637300.236570@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Yeah but yeah but yeah but... (too much "Little Britain" maybe)

What's to scale when we're comparing 4.57 minus 4.58 with zero minus
0.01???
Agreed, it must be an anomalous use of wide zero.
Works on uv 9.xx
Parens don't change the type, the internal expression of (-0.01) is pure
numeric.

Chandru

Mike.

Excalibur wrote:

Hi
I must admit that there are significant problems with having too great a
precision with miles of digits.
However the alternative of having N significant digits I can't remember
whether it is 14 or 16 also has its moments of glory. I did the rental
programs for Australia arcade back in the 70's where rent was 10% of
turnover or a fixed figure whichever was greater. I happily followed
normal
maths practise and scaled all at the end. Everything went swimmingly for
a
few months then Murphy kicked in. A Melbourne Winter when fur coats
where
de riguer, no pc then, minks were $50,000 plus, turnover went through the
roof, and my program said we should pay the fur shop for being there. It
transpired that when one hit the maximum digits it was the most
significant
digit that fell off the end. Big OOPS!
I scale faithfully on all varieties at every step of the calculation.
Regards
Peter McMurray
"Mike Preece" <michael@xxxxxxxxxx> wrote in message
news:1143602018.556655.313360@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
My colleague has accepted that he has to put oconvs around the values.
I'm sure he's not totally happy with that - but it works.

As for me - I am appalled! It's not nice to realise that there is a ton
of code out there that I have written over the years that will break if
migrated to dUniData or dUniVerse. It's ridiculous for 4.57 minus 4.58
not to equal zero minus .01. If this is "wide zero" then wide zero is a
pile of poo.

Mike.

Excalibur wrote:

Hi
Welcome to the world of wide zero. Always do conversions before
comparisons. Openqm has a flag to force rounding at a reasonable
level
and
I suspect so does Unidata. D3 uses x significant digits (16 I think)
so
skips the problem in normal maths.
Regards
Peter McMurray
"Mike Preece" <michael@xxxxxxxxxx> wrote in message
news:1143593229.817870.273060@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Posted on behalf of a colleague who wishes to remain nameless...

UniBasic code that should work

The results of the following code are proving to be troublesome:

A = 4.57 + (-4.58)
B = (-0.01)
PRINT 'TEST ONE: ARE ':A:' AND ':B:' THE SAME? ':
IF A = B THEN
PRINT 'YES'
END ELSE
PRINT 'NO'
END

A = OCONV(A,'MD20')
B = OCONV(B,'MD20')
PRINT 'TEST TWO: ARE ':A:' AND ':B:' THE SAME? ':
IF A = B THEN
PRINT 'YES'
END ELSE
PRINT 'NO'
END

You would expect both tests to return 'YES', but in fact, only the
second test returns 'YES'.

TEST ONE: ARE -0.01 AND -0.01 THE SAME? NO
TEST TWO: ARE -0.01 AND -0.01 THE SAME? YES

Is there something simple that I am missing?





.

Relevant Pages

  • Re: UniBasic code that should work
    ... Yeah but yeah but yeah but... ... What's to scale when we're comparing 4.57 minus 4.58 with zero minus ... However the alternative of having N significant digits I can't remember ...
    (comp.databases.pick)
  • Re: Very weird numeric values
    ... Ken Snell (MVP) wrote: ... slightly round numbers when storing them, zero minus zero minus zero minus ... the expression using the CCur function; ...
    (microsoft.public.access.gettingstarted)
  • Re: How to increase Working Precision?
    ... I don't get credit for letting "generally outstanding" slip by? ... and 9.95, with three correct digits. ... It printed as zero because it ... is deemed to have too little precision to print otherwise ...
    (sci.math.symbolic)
  • Re: MAX-FLOAT-DIGITS
    ... There is no easy way to determine the maximum number of usable digits ... The value to be used for MAX-FLOAT-DIGITS is implementation dependent. ... applications to be written in a more portable manner. ... If u is greater than zero the significand is rounded to u digits ...
    (comp.lang.forth)
  • Re: 0 SIZE returns 0.; bug?
    ... Number following the prologue is not the length of ZINT it's rather the ... So in fact the above is ZERO length ZINT ... all digits *are* significant. ... but if working with reals is assumed to be approx mode. ...
    (comp.sys.hp48)