FAQ  •  Register  •  Login

Possible issue with < and > (* solved *)

<<

LTee

Posts: 153

Joined: Tue Jul 07, 2009 2:54 pm

Post Tue Jun 20, 2017 9:12 pm

Possible issue with < and > (* solved *)

I'm struggling a bit with the behaviour of the < and > operators compared to Spectrum BASIC and I'm not sure if what I'm seeing is a bug or expected behaviour.

Check out this program:
  Code:
dim t,t2 as byte

let t=1
let t2=0

print 1>0
print 1<0
print t>0
print t<0
print t>t2
print t<t2


If I run the equivalent of this in Sinclair BASIC then the output is:
1
0
1
0
1
0

But compiled in ZX Basic I get:
1
0
255
0
255
0

With just numbers the result is the same as Spectrum BASIC, but as soon as I start using typed variables in ZX Basic the 'true' value switches from 1 to 255. Is that expected behaviour? It seems a bit odd, but I realise there might be a really good reason for it.

The program I'm trying to compile relies on the result of similar clauses to perform calculations, so if the answer could be something other than 0 or 1 I'll have to rewrite it a bit. That's not a problem, but I didn't want to do that if this is actually a bug that might get fixed later. :)

Thanks for any help!
<<

boriel

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Wed Jun 21, 2017 8:25 am

Re: Possible issue with < and >

Yes, it's intended behaviour. This is because, believe it or not, it's faster to get 255 (which is -1 in two-complement) using Z80 ASM.
You will get -1 (the real value) if you use Byte type: CAST(Byte, t > 0).

Anyway, if you really need "1" value, then use --strict-bool parameter.
This will ensure True values are always "1", at the cost of a small (very small) overhead. :roll:
<<

LTee

Posts: 153

Joined: Tue Jul 07, 2009 2:54 pm

Post Wed Jun 21, 2017 11:00 am

Re: Possible issue with < and > (* solved *)

That's great, boriel - thanks for the clarification. It won't cause me any problems, I'll just adapt the code accordingly - just wanted to make sure it was 'correct' behaviour before I did that.
<<

boriel

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Wed Jun 21, 2017 11:32 am

Re: Possible issue with < and > (* solved *)

LTee wrote:That's great, boriel - thanks for the clarification. It won't cause me any problems, I'll just adapt the code accordingly - just wanted to make sure it was 'correct' behaviour before I did that.

But remember if you need to have 1/0 logic to use:
  Code:
zxb --strict-bool program.bas
so you don't have to change your code :!: :roll:
<<

LTee

Posts: 153

Joined: Tue Jul 07, 2009 2:54 pm

Post Wed Jun 21, 2017 11:54 am

Re: Possible issue with < and > (* solved *)

Ah, yes - I'd somehow managed to forget about that by the end of the sentence, sorry! The tiny increase in processing time shouldn't be a big deal in this scenario, I think, so it's probably the safest solution.

The --base-string issue is causing me more problems at the moment, tbh - this issue at least only causes some wrong colours to appear on screen. :)

Thanks again!
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Wed Jun 21, 2017 4:05 pm

Re: Possible issue with < and > (* solved *)

For most cases having non 1 value for "True" doesn't matter (even in Sinclair basic, a positive value > 1 is "true)

So if you are doing

let bool=1>2
if bool then print "True" : end if

It's fine if bool=255, for logic. It's bad logic in ZX Basic to assume true=1, though. You can cast it with SGN, probably, or BAND 1 to limit it to definite 1/0 - then you aren't putting the overhead into every comparison. Your call as to which is most efficient, probably.
<<

LTee

Posts: 153

Joined: Tue Jul 07, 2009 2:54 pm

Post Thu Jun 22, 2017 8:35 pm

Re: Possible issue with < and > (* solved *)

In the original BASIC listing I was using it as a memory/time-saving way of selecting a colour based on the value of a variable.

e.g.
PRINT INK 1+(val<5);val

So if val>=5 the message prints in ink 1, but if it's less than 5 it becomes ink 2. Obviously this doesn't work out so well if the value is suddenly 255 instead of 1 or 0. :D
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Sun Jul 30, 2017 7:05 pm

Re: Possible issue with < and > (* solved *)

LTee wrote:In the original BASIC listing I was using it as a memory/time-saving way of selecting a colour based on the value of a variable.

e.g.
PRINT INK 1+(val<5);val

So if val>=5 the message prints in ink 1, but if it's less than 5 it becomes ink 2. Obviously this doesn't work out so well if the value is suddenly 255 instead of 1 or 0. :D


Yup. You'd have to wrap it in the SGN function, which I think should return 1 for positive numbers, 0 for zero, and -1 for negative numbers if you want to explicitly do that. It's a bit of a sinclair basic cheat, really. Languages that have an explicit boolean type wouldn't let you get away with this cheese either :)

I haven't tested, but try 1+SGN(val<5)

Though given VAL is a reserved word, that's a bad variable name choice btw.
<<

boriel

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Mon Jul 31, 2017 7:50 am

Re: Possible issue with < and > (* solved *)

That's a good idea.

You can enable strict boolean evaluation (which always returns 0 or 1) in the code with:

  Code:
#pragma strict_bool = true


On the other hand, you can also create this macro, using Britlion's idea:

  Code:
#define BOOL(x)  (ABS(SGN(x)))

PRINT INK 1+BOOL(value<5);value
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Tue Aug 08, 2017 8:52 am

Re: Possible issue with < and > (* solved *)

That's quite clever, Boriel. Then you only lock things to strict where you need them, and don't have to lengthen the code for each individual boolean calculation.

Return to Bug Reports

Who is online

Users browsing this forum: No registered users and 1 guest

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by Vjacheslav Trushkin for Free Forums/DivisionCore.

phpBB SEO