Hellos to those not at Spectrum....I'm stuck in a port here and can't
get up. Help?

On D3 (and probably other "Picks"), this program:

1 PRECISION 0
2 X = 2.25
3 Y = 9
4 X = MOD(X,Y)-2
5 IF X THEN PRINT "X TRUE" ELSE PRINT "X FALSE"

prints "X false", because the result of the line 4 calculation is zero
("precision 0" means no decimal places are stored, ever, at all).
That's what I'd expect to happen.

However, on Universe (10.x), the same code produces "X true",
apparently because on Universe the "precision 0" only affects the only
the *output* of the decimal places, not its internal representation -
the result of the line 4 calculation is ".25" and therefore X is
non-zero for the purposes of the IF statement.

1) Do I have this right?
2) Is there any way to get Universe to act like Pick in this particular
case? (I'm already compiling the program on a Pick flavor account,
btw).

Thanks.
---jon---

Works this way on 9.6. Assume that's just how it is.

You can say IF X 'R0' THEN or IF INT(X) THEN to get your desired result,
but I suspect you;re talking about not changing existing programs?

Chandru

"Jonathan Rogers" <thatseattleguy (AT) gmail (DOT) com> wrote

There's some sort of explanation about "wide zero" in the update notes for
10 but I don't remember the details. Has to do, of course, with the
conversions among floating and fixed and binary and decimal. I think
there's an option to treat many 9s after the radix as zero.
BobJ
"murthi" <c_xyz_murthi (AT) seeing_xyz_green (DOT) net> wrote

"Wide zero"? That must be one of those signs of the End Days...back
when I was a lad, when dinosaurs roamed the earth and computers had
toggle switches to change bits in memory and dammit, 64k was enough
memory for 16 or more users, you could count on zero *meaning* ZERO.
Jeesh.

Anyways, that's a new one for me. Though even if it was the source of
the problem, changing the wide-zero value won't help because it looks
like you can only set it on a SYSTEM-wide basis, not for an individual
user or program. Talk about major impacts. ("Sorry, Mr. CFO, but we
decided to run all our Universe programs with no decimals at all...hope
that still works for the payroll and GL...")

Well, if that's the way "PRECISION n" functions on Universe, I'm not
happy, and I think it's a bug, but I doubt I'm going to get anyone to
change anything. Looks like I need to recode these routines unless
someone comes up with another idea....

thanks -jon-

Goo'day,

Back in our early UniVerse days (9.3....), some of our users in NT4
struck the zero not equal to zero problem and we were advised to
change wide zero from "3dc" to "3eb", which we did, and never fell
into that particular hole in the floor again....

In spite of it "being a system-wide" thing, I'd highly recommend a
permanent change - you're only worring about squidgets of a decimal
point - there is "Wide Zero" documentation within UniVerse........

If your problem is "wide zero" - read about the UniVerse condition
before climbing too highly up the "bug tree" .... Zero ain't always
zero.

On 7 Mar 2006 16:03:14 -0800, "Jonathan Rogers"
<thatseattleguy (AT) gmail (DOT) com> wrote:


Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....

If it wasn't clear from my posting, my problem isn't wide zero. It's
the fact that PRECISION on universe is only affecting the display of a
variable; it seemlingly doesn't affect internal calculations at all (or
inconsistently). That's what I mean by "bug".

The wide zero thing is fun, but I really doubt it's what I'm seeing
here that makes the original program run differently on universe than
on other Picks.

And you can avoid the whole precision problem by doing all calculations
without a decimal and without using MR2 until you are presenting the results
to a human. Even then you will get better presentations with a little
coding. If you find that confusing, and many very smart business people do,
then look for a basic text book that covers double precision and complex
variables. While not intended to solve accounting problems, the methods
allow perfect precision and perfect answers in the "decimal" and accounting
sense even for very large and very small numbers. The same with Heading
statements. They are very convenient - but the devil is in the details.
Once you get to fighting dates and page numbers and multi-line headers then
the heading statement is very difficult to use. For practical purposes the
Pick implementations of precision, headings, and indexes are approximations.
BobJ
"Bruce Nichol" <reverse_ecurb (AT) taloncs (DOT) com.au> wrote

This is not a bug but a difference of semantics. UniVerse is not alone
in this behaviour. Calculations are performed to the maximum precision
of the machine and the PRECISION value simply affects how conversion
from number to string is done. Personally, I think UV has it right. If
you really want integer arithmetic, you can always use INT(A/B) instead
of A/B.

Martin Phillips, Ladybridge Systems.

Martin:

That's well said, and I don't disagree that UV has an excellent
argument for PRECISION working the way it does on their implementation.
You've convinced me.

However, *given how it works in other systems, and the legacy
represented by lots of programs coded with the expectation it works
that way*, it still would have been nice if there was a compile-time
option in UV that made the PRECISION statement act as it does on
Pickish systems. It wouldn't be hard for them to have the run machine
to lop off any extra decimal places after calculation as it pushes
and/or pops the results off the stack.

But it's definitely hard to go through lots of legacy code and put
INT() statements around any calculation you suspect might have
different results on UV and hope you're correct...

thanks all for the input and feedback...
-JON-

"BobJ" <bobj (AT) wildblue (DOT) net> wrote

My advice is don't even think about doing this. Always convert to the
external format first. I am well aware that no conversion is the preferred
mathematical approach (I love F correlatives and I use an HP scientific
calculator) but I know the disastrous results I had when I followed It.
Certainly the available maximum size of a number has changed over the years
but you will have to keep a close eye on results and the effect of PRECISION
statements if you do not scale all the way. As I remember it the most
significant bits just used to fall off the end without an error warning, and
we do know that some people are still using R83!
Peter McMurray