Different result
Post by mohsen on Nov 18th, 2008, 6:53pm
The following code when run (from the IDE) produces the output -1 (TRUE).
But when compiled and run produces the output 0.
Code: 10 all=250
20 empty=FALSE
30 IF all=250empty=TRUE:PRINT empty
40 REM more code here
Note: All options selected when compiling.
Re: Different result
Post by admin on Nov 18th, 2008, 11:07pm
Quote:The following code when run (from the IDE) produces the output -1 (TRUE).
But when compiled and run produces the output 0.
|
|
Add a space between the 250 and the empty thus:
Code:
10 all=250
20 empty=FALSE
30 IF all=250 empty=TRUE:PRINT empty
40 REM more code here
As a general rule, allow the compiler to make the program more compact (and faster) by omitting spaces; don't omit them yourself!
Incidentally, if you add *lowercase as the first line of your program then the IDE and the compiler give the same answer:
Code:
*lowercase
all=250
empty=FALSE
IF all=250empty=TRUE:PRINT empty
REM more code here
I wonder if you can work out why!
Richard.
Re: Different result
Post by mohsen on Nov 19th, 2008, 04:35am
on Nov 18th, 2008, 11:07pm, Richard Russell wrote:I wonder if you can work out why!
Richard. |
|
you are just forcing the IDE to give the same incorrect result as the compiler is doing by forcing an alternative interpretation to the form:
IF all=250E mpty=TRUE : PRINT empty
The Compiler is fine. It is the Cruncher variables replacer that seems to confuse numbers in exponent formats. It needs a space present to work properly.
Re: Different result
Post by admin on Nov 19th, 2008, 09:09am
Quote:| you are just forcing the IDE to give the same incorrect result as the compiler |
|
The result is not incorrect.
I have just run this program on a genuine BBC Master computer running 6502 BBC BASIC 4:
Code:
10 ALL=250
20 EMPTY=FALSE
30 IF ALL=250EMPTY=TRUE:PRINT EMPTY
(note capital-letter variables).
IT PRINTS THE ANSWER 0 !!
The program I listed (with the *lowercase command) is equivalent to this, and the answer it gives is the same. That's how BBC BASIC works.
Richard.
Re: Different result
Post by mohsen on Nov 19th, 2008, 09:30am
it is the lower case not the upper case:
i.e. this one:
Code:IF all=250empty=TRUE:PRINT empty
BB4W gives the result TRUE, so does BASIC V, which is the correct answer.
The letter "e" part of the variable "empty" should not be recogised as an exponent number format unless it is uppercase "E".
by using the *lowercase command you are forcing the interpreter to treat it as:
Code:IF all=250Empty=TRUE:PRINT empty
i.e. accepting lower case keywords including lower case exponent number formats.
But there is another issue:
Even though the *lowercase command is not used, the cruncher treats the "e" as an exponent and tags it to the number 250 becoming 250e and then renames the new variable "mpty" to a shorter equivalent.
To summarise:
1. The interpreter correctly recognises "E" as an exponent (not "e") - unless forced to do so by the command *lowercase.
2. The Cruncher treats both "E" and "e" as exponents, irrespective of the *lowercase Command.
Re: Different result
Post by mohsen on Nov 19th, 2008, 09:33am
I guess the simple solution is to ensure that a space is present between the end of a number and any variable starting with the letters "E" or "e".
This will fix the Cruncher problem.
Re: Different result
Post by mohsen on Nov 19th, 2008, 09:43am
The following failed to run after compiling although a valid BB4W syntax and executes fine in the IDE:
Code:MODE 8 : OFF *FONT Monospac821 BT,10,B
The Cruncher requires a colon before *Commands else it will treat the Command line as variables. In the above example it will creat four (4) new replacement variables for the "FONT", "Monospac821", "BT" and "B".
Solution:
Always ensure that a colon ":" is present before *Commands on multi-line statements.
Re: Different result
Post by admin on Nov 19th, 2008, 2:18pm
Quote:The Cruncher treats both "E" and "e" as exponents, irrespective of the *lowercase Command.
|
|
That's right, BECAUSE IT HAS NO ALTERNATIVE! The acceptance of lowercase exponents and hex digits (by means of *lowercase) is a run-time selection, which can (and often does) change during the execution of a program.
The cruncher has no way of knowing whether *lowercase is in force or not. When it encounters code such as your example, it cannot determine whether it should interpret the 'e' as an exponent (which would be the case for *lowercase on) or as the first letter of the following variable name (which would be the case for *lowercase off).
Consequently the cruncher has to make an assumption, and the assumption it makes is that *lowercase is active. This choice reduces the chance of a program not compiling correctly.
So it is not a "cruncher problem" in the sense that you imply (i.e. a fault), but an unavoidable feature that arises because of the support for lowercase exponents.
I wish BBC BASIC had insisted that the exponent 'E' be followed by a digit (or +/-), but it doesn't. It is one of those legacy features that has unwanted consequences.
Richard.
Re: Different result
Post by admin on Nov 19th, 2008, 2:26pm
Quote:| The following failed to run after compiling although a valid BB4W syntax and executes fine in the IDE |
|
You are lucky that it executed "fine" in the IDE. It is not valid syntax and it could easily fail, even in the IDE, if the star command happened to include a keyword. For example this does not execute correctly in the IDE:
Code:
MODE 8 : OFF *PRINTER HP Laserjet Plus
Richard.