BBC BASIC for Windows
« Different result »

Welcome Guest. Please Login or Register.
Apr 5th, 2018, 9:59pm



ATTENTION MEMBERS: Conforums will be closing it doors and discontinuing its service on April 15, 2018.
Ad-Free has been deactivated. Outstanding Ad-Free credits will be reimbursed to respective payment methods.

If you require a dump of the post on your message board, please come to the support board and request it.


Thank you Conforums members.

BBC BASIC for Windows Resources
Online BBC BASIC for Windows documentation
BBC BASIC for Windows Beginners' Tutorial
BBC BASIC Home Page
BBC BASIC on Rosetta Code
BBC BASIC discussion group
BBC BASIC for Windows Programmers' Reference

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: Different result  (Read 1227 times)
mohsen
New Member
Image


member is offline

Avatar




PM

Gender: Male
Posts: 39
xx Different result
« Thread started 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.

User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: Different result
« Reply #1 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.
User IP Logged

mohsen
New Member
Image


member is offline

Avatar




PM

Gender: Male
Posts: 39
xx Re: Different result
« Reply #2 on: Nov 19th, 2008, 04:35am »

on Nov 18th, 2008, 11:07pm, Richard Russell wrote:
I wonder if you can work out why!
Richard.


grin
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.

User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: Different result
« Reply #3 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.
User IP Logged

mohsen
New Member
Image


member is offline

Avatar




PM

Gender: Male
Posts: 39
xx Re: Different result
« Reply #4 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.

User IP Logged

mohsen
New Member
Image


member is offline

Avatar




PM

Gender: Male
Posts: 39
xx Re: Different result
« Reply #5 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.
User IP Logged

mohsen
New Member
Image


member is offline

Avatar




PM

Gender: Male
Posts: 39
xx Re: Different result
« Reply #6 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.

User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: Different result
« Reply #7 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.
User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: Different result
« Reply #8 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.
User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

| |

This forum powered for FREE by Conforums ©
Terms of Service | Privacy Policy | Conforums Support | Parental Controls