SuperBASIC Quirks

[qbits]

Hi all,
When displaying coordinates with central positioning, sometimes requires exchange of sequential values ie. 1 to 40 with +/- values ie. 20< >0< >-20

I use variable ‘wz’ for PRINT out of values 20< >2 0 -2< > -20. The calculation are with variable ‘vs’ ranging from ‘0.4’ to ‘2.4’ in STEPS of ‘.1’ vs=1.4 equates to ‘0’

Coding (1) IF vs=1.4 : wz=0 : ELSE wz=(vs*20)-28 comes up with invalid parameter when vs=1.4 (ie. ‘0’)

I assume the Interpreter still calculates (1.4 * 20) -28 as floating-point maths causing the ‘0’ Error?

SuperBASIC has the ability to convert Integers and Floating-point values to Strings and back so I used this

Coding (2) Z$=vs*20 : wz=Z$-28 with success! Gives wz values 20 < > 2..0..-2 < > -20 in STEPS of ‘2’

Que: QL Experts. Are my assumptions correct about ‘0’ error and will my Coding (2) Compile OK.

Norman - if you what to add Assembly code for this I dare say it wouldn’t go a miss for some.

QBITS

[NormanDunbar]

Norman - if you what to add Assembly code for this I dare say it wouldn’t go a miss for some.

I might be able to, but I'm afraid I have absolutely no idea what you are meaning in your post. Sorry.


Cheers,
Norm.

[tofro]

Hi all,
When displaying coordinates with central positioning, sometimes requires exchange of sequential values ie. 1 to 40 with +/- values ie. 20< >0< >-20

I use variable ‘wz’ for PRINT out of values 20< >2 0 -2< > -20. The calculation are with variable ‘vs’ ranging from ‘0.4’ to ‘2.4’ in STEPS of ‘.1’ vs=1.4 equates to ‘0’

Coding (1) IF vs=1.4 : wz=0 : ELSE wz=(vs*20)-28 comes up with invalid parameter when vs=1.4 (ie. ‘0’)

I assume the Interpreter still calculates (1.4 * 20) -28 as floating-point maths causing the ‘0’ Error?

SuperBASIC has the ability to convert Integers and Floating-point values to Strings and back so I used this

Coding (2) Z$=vs*20 : wz=Z$-28 with success! Gives wz values 20 < > 2..0..-2 < > -20 in STEPS of ‘2’

Que: QL Experts. Are my assumptions correct about ‘0’ error and will my Coding (2) Compile OK.

Norman - if you what to add Assembly code for this I dare say it wouldn’t go a miss for some.

QBITS

Comparing floating point variables against floating point constants is always dangerous and shouldn't be done. The computer (not just the QL, but basically any computer) has difficulties hitting the exact value. Try the following:

Code: Select all

PRINT (1.4 * 20) = 28

This returns 0 on all my QLs, while common sense would assume it should return 1. That is caused my minimal inaccuracies in floating point (some decimal values simply cannot be exactly reproduced in the computer's floating point format). And that is why S*BASIC has the "==" operator, which does an "approximate comparison" (as in "close to")

Code: Select all

PRINT (1.4 * 20) == 28

Returns 1, as it should. Simply replace your "=" comparisons with "==" ones and it should work.

[dilwyn]

S*BASIC is a little unique in having the "approximately equal" (double =), for both floats and strings in their respective ways.
It's really useful for float comparisons when tiny calculation inequalities become obvious in cases like this for such numbers.

[stevepoole]

Hi Folks,
Do not use the == operator if either side of the operator is zero : PRINT (1E-99)==0 returns false !
Always add 1 to either side : PRINT (1+1E-99)==1 returns true...
(This was described many years ago in documentation). Steve.
____________________________________________________________

[qbits]

Hi,
My Simples solution to avoid the ‘0’ problem with floating point calculations was an
IF statement to catch the variable vs value of 1.4 equating to the ‘0’
ELSE all other calculation for wz=(vs*20)-28 provides the output scale of -20 to +20.

Is there a more sophisticate coding method or does SIMPLES suffice!

From members experience do we have any more quirky use of SuperBASIC code.

QBITS

[dilwyn]

It had never quite sunk in with me about what Steve said about == 0, although it is mentioned in the Jan Jones BASIC guide:

X == Y will be true if [X-Y] <= [Y*1E-7] , where [X-Y] means the absolute, or positive, value of X-Y.
Note : It may not be immediately obvious to you that no value will ever be == 0. If, in the above equation, Y is zero, then the check reduces to [X] <= 0, clearly impossible when X is non-zero. If you make X zero instead of Y, then the test becomes [Y] <= [Y * 1E-7], also somewhat unfeasible. To test for a quantity being very close to zero therefore, adding one to both sides gives the desired result, e.g. (X+1) == 1

[tofro]

It had never quite sunk in with me about what Steve said about == 0, although it is mentioned in the Jan Jones BASIC guide:

X == Y will be true if [X-Y] <= [Y*1E-7] , where [X-Y] means the absolute, or positive, value of X-Y.
Note : It may not be immediately obvious to you that no value will ever be == 0. If, in the above equation, Y is zero, then the check reduces to [X] <= 0, clearly impossible when X is non-zero. If you make X zero instead of Y, then the test becomes [Y] <= [Y * 1E-7], also somewhat unfeasible. To test for a quantity being very close to zero therefore, adding one to both sides gives the desired result, e.g. (X+1) == 1

In QBits' example that translates to simply "don't subtract before compare"), and that's why I wrote

Code: Select all

(1.4 * 20) == 28

The "reasoning" in the Jones' book, is, however, a bit dubious - "x == y" should actually be implemented as "Eps = ABS (x - y) : IF Eps < 1E-7 RETurn 1 ELSE RETurn 0" and apparently isn't, which in my book is just wrong rather than "not immediately obvious" .

[bwinkel67]

This is a bit costly, but couldn't you just do this:

IF INT (ABS (X)) = 0

[pjw]

This is a bit costly, but couldn't you just do this:

IF INT (ABS (X)) = 0

It works, but remember INT is word sized in SuperBASIC, long in SBASIC.