## Introduction to BBC BASIC

ejolson
Posts: 3232
Joined: Tue Mar 18, 2014 11:47 am

### Re: Introduction to BBC BASIC

jahboater wrote:
Mon Jul 15, 2019 7:11 pm
ejolson wrote:
Mon Jul 15, 2019 6:53 pm
One obtains a different but still not fully satisfying result with the C program

Code: Select all

``````#include <stdio.h>
#include <math.h>

int main(){
for(double x=1e3;x<=1e32;x*=10){
double y=floor(x);
printf("floor(%g)=%f %s\n",
x,y,y==x?"equal":"not equal");
}
return 0;
}``````
wonder if Richard's BBC Basic does the same.
The results for this C code are correct and as expected.

floor(x) returns largest integral value not greater than x.

Therefore if x is an integer, floor(x) will return x. And in your example x is always an integer.

I think you need for the example: long n = lrint(x)

If the rounded value of x cannot be stored in a long, it will report a domain error (and raise the FE_INVALID exception).
Thanks! I realized that and already changed my post to read "almost satisfying" instead of "not fully satisfying."

I wonder what happens if one moves along exact powers of two.

jahboater
Posts: 4595
Joined: Wed Feb 04, 2015 6:38 pm

### Re: Introduction to BBC BASIC

ejolson wrote:
Mon Jul 15, 2019 7:15 pm
I wonder what happens if one moves along exact powers of two.
For floor, or more usefully trunc (floor truncates towards negative infinity), I suspect it would work all the way up to 1.8e308 (DBL_MAX). Although precision is lost above 2^53, they remain integers!

Incidentally, Javascript stores "integers" in double precision floating-point. I guess it was useful in the days before 64-bit integer hardware became available as you had 53 bits instead of 32 bits.

RichardRussell
Posts: 572
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

DavidS wrote:
Mon Jul 15, 2019 6:26 pm
No bug, all documentation of the INT function (parens optional) explicitly states for int real that real must be in the range of possible integers.
That's still ambiguous. By "possible integers" it seems to mean "values which can be stored in an integer variable" but why should it? You can perfectly well store an integer in a floating-point variable, it's still an integer when you do so. So "possible integers" ought to imply a much bigger range of values than it actually does.

If you prefer, I'll call it an 'undesirable feature' rather than a 'bug', but it's ridiculous nonetheless. If you have a variable type that can hold an integer with more then 32 bits, there should be a function supplied which will truncate (towards minus infinity, which is what INT does in BASIC) a non-integral value to such an integer.

Even if I'd known ARM BASIC 6 works like this, I would never have copied it in my BASICs.

ZXDunny
Posts: 116
Joined: Sun Jul 08, 2012 7:57 pm

### Re: Introduction to BBC BASIC

DavidS wrote:
Mon Jul 15, 2019 3:44 pm
gives me a chance to fully grock the code
A quick point of language - it's "grok", not "grock".
Heater wrote:
Mon Jul 15, 2019 4:34 pm
Except...and I'm not totally sure on this, the Sinclair Spectrum had BASIC keywords on it's keyboard. I always imagined that hitting those keys produced their tokens directly. Never had a Speccy so I don't know for sure. But even then what you see on the screen is source text not tokens.
Correct, mostly. The Speccy had tokens on its keyboard - pressing a key (or combination of keys, it was quite horrific for the 16k/48k models prior to the 128k editor) would insert a token into the edit line. The program was stored as tokens, and any display of the code was de-tokenised before printing. Tokenisation happened as the user entered the code.

As each keyword had its own ASCII value (above 127) assigned to it, there was no chance that variables and keywords could be confused by the interpreter.

Heater
Posts: 12964
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

ZXDunny,
Correct, mostly
You then go on to explain how I was correct, entirely.

Of course in the days when machines like the Specy had such tiny amounts of RAM and there was not much processing power a tokenized system makes sense.

Arguably DavidS is correct in his assertion that the tokenized form of BASIC is the source code in that case. Ignoring the fact that it's not what you see on the screen which is just regular text.

After all, the GPL requires delivering source code for redistributed software. They defined that as something like "in the form used for editing". Which would be the tokenized form in the Specy case.

Were there any other machines that did that?

Heater
Posts: 12964
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

ejolson,

Should I be updating the classic_bbc.bas version of fibo in the Fibonacci challenge repository with that all caps fibo you posted here?

Does that version run on RISC OS ?

ejolson
Posts: 3232
Joined: Tue Mar 18, 2014 11:47 am

### Re: Introduction to BBC BASIC

Heater wrote:
Tue Jul 16, 2019 2:48 am
ejolson,

Should I be updating the classic_bbc.bas version of fibo in the Fibonacci challenge repository with that all caps fibo you posted here?

Does that version run on RISC OS ?
It's for Matrix Brandy Basic rather than Richard's BBC Basic, so probably not. I'm still waiting to hear whether it runs on RISC OS. However, of you are looking for programs to include the Pascal code is a candidate.

John_Spikowski
Posts: 1308
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA

### Re: Introduction to BBC BASIC

What BASIC language runs the classic fibo the fastest. I'm assuming FreeBasic as it's a BASIC to C translator. Has anyone tried porting classic to BaCon?

Heater
Posts: 12964
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

ejolson,

OK. So we still don't have a version that runs on RISC OS right? Which is odd as the BASIC on RISC OS is always touted as one of it's major selling points.

I was not really looking for more entries for the Fibo challenge but a Pascal solution seems to have passed me by, where is it exactly?

Heater
Posts: 12964
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

ScriptBasic,
What BASIC language runs the classic fibo the fastest. I'm assuming FreeBasic as it's a BASIC to C translator. Has anyone tried porting classic to BaCon?
That is a silly question isn't it?

All BASICs are different. No one particular program has been found to run under more than one BASIC engine so far. They all require the code to be adapted. As such there is a bunch of different BASIC solutions for different run-times in the Fibo Challenge repository.

If you want to try them and get some timings on your machine here they are: https://github.com/ZiCog/fibo_4784969/tree/master/BASIC
Complete with a README file with notes on how I got them to run and some timings on Pi Zero from ejolson.

BASIC has been the biggest time waster of all the languages in the Fibonacci Challenge (Except for Smalltalk possibly) What with all the different variants and having to get different engines working. We are still having difficulty getting a Fibo challenge solution working at all in some BASIC variants or their platform.

If anyone creates a Fibo Challenge solution in BaCon I really do not want to here about it

Heater
Posts: 12964
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

How can that be. Nothing of what I have said there is fantasy.

The facts are out there: https://github.com/ZiCog/fibo_4784969/tree/master/BASIC

John_Spikowski
Posts: 1308
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA

### Re: Introduction to BBC BASIC

Build a moat and fill it with pythons. That should keep those BASIC scum bags in check.

RichardRussell
Posts: 572
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

Heater wrote:
Tue Jul 16, 2019 2:46 am
Arguably DavidS is correct in his assertion that the tokenized form of BASIC is the source code in that case. Ignoring the fact that it's not what you see on the screen which is just regular text.
No, I don't think so. Tokens are just shorthand for keywords, they shorten the program and speed up execution somewhat; you can think of them as a simple form of compression. But how they are entered in the first place doesn't change their status in respect of what the 'source code' is; how the program is listed to the screen is a much better guide to that.

Several home computers BITD had single-key keyword entry (irrespective of whether they tokenised the program). The BBC Micro didn't (although you could program the function keys to produce any string), but it did have keyword abbreviations: typing one or more characters followed by a dot/period (e.g. P. for PRINT or CL. for CLEAR).

RichardRussell
Posts: 572
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

ejolson wrote:
Mon Jul 15, 2019 6:17 pm
The classic BASIC program should automatically detect the floating-point precision and proceed accordingly.
In coding that test have you assumed that floats will be either 32-bits or 64-bits? If so that might explain it failing to run on early BBC BASICs, because they all use 40-bit floats (32-bit mantissa, 8-bit exponent), including BBC BASIC 5 on RISC OS.

Soruk
Posts: 21
Joined: Thu Jun 20, 2019 11:25 am

### Re: Introduction to BBC BASIC

This has, unsurprisingly, uncovered a bug in Matrix Brandy. INT was accepting values that were out of range (which is not allowed on the BBC Micro nor RISC OS BBC BASIC implementations).
INT was being implemented as casting the float to a 32-bit int, which happened to get the sign right and work on a RasPi, but failed spectactularly on x86 (32-bit and 64-bit). Lines 8520 and 8600 inclusively should be removed, and in its place, add:

Code: Select all

``8520 F0=&7FFFFFFF``
Also, line 241 should be removed, really it should crash the interpreter but for some reason it isn't! I need to check on that......

Edit: regarding line 241, no, it should be completely ignored, which did seem to be happening in the program but caused a segfault when running in isolation at the command line. This has now been fixed.
Last edited by Soruk on Wed Jul 17, 2019 10:31 am, edited 1 time in total.

RichardRussell
Posts: 572
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

Soruk wrote:
Tue Jul 16, 2019 4:58 pm
This has, unsurprisingly, uncovered a bug in Matrix Brandy.
Will this affect other versions of Brandy (Napoleon Brandy etc.), or is it in an area where you modified the code for Matrix?
INT was accepting values that were out of range (which is not allowed on the BBC Micro nor RISC OS BBC BASIC implementations).
Those implementations of BBC BASIC (that is up to and including ARM BASIC 5) use 40-bit floats with a 32-bit mantissa. So although the range of integers which can be stored in a floating-point variable is greater than what can be stored in an integer variable (by a factor of two) it's arguable - and indeed Acorn did successfully argue - that it's reasonable to limit the range of values accepted by INT to -2^31 to +2^31-1. If you supply a value outside of this range you get a 'Number too big' error.

However in ARM BASIC 6 and Brandy floating-point variables are 64-bit doubles, which can contain a much larger integer (53-bits rather than 32). In that situation I don't think it's possible to argue that such a restriction is acceptable: you may well want to truncate to an integer a value much larger than 2^31 and the INT function should support doing that.

Here's a simple program to try on any BASIC that has floating-point variables with 64-bits or more:

Code: Select all

``````      a = 2^50 + 0.5
b = INT(a)
PRINT a - b
``````
This should print '0.5'. If it doesn't I would say something is seriously wrong.
Last edited by RichardRussell on Tue Jul 16, 2019 6:36 pm, edited 1 time in total.

DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

### Re: Introduction to BBC BASIC

ejolson wrote:
Mon Jul 15, 2019 7:05 pm
DavidS wrote:
Mon Jul 15, 2019 7:04 pm
Same results using either LOG or LN.
Did you try the Matrix Brandy Basic code just posted above?
Not yet. Been sleeping, getting taken care of medicaly, and cleaning. Will give it a try when done cleaning.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 12964
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

Wow, my humble Fibo challenge seems to have been doing a great job of shaking out the bugs in various language run-times. I hope they are all getting reported and fixed so that this has not been entirely a waste of time.

John_Spikowski
Posts: 1308
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA

### Re: Introduction to BBC BASIC

Any challenge where obscure is its foundation will produce unexpected results.

Heater
Posts: 12964
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

You keep saying that.

But I fail to see what is obscure about calculating with numbers and keeping those numbers in arrays.

Conversely we could say that every program, anyone writes, ever, is obscure in it's own way.

People hit all kind of "obscure" bugs like this all the time.

They are only obscure for the developers who never thought to test whatever it is that is failing.

John_Spikowski
Posts: 1308
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA

### Re: Introduction to BBC BASIC

For me the fibo challenge was a huge waste of my time.

Heater
Posts: 12964
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

That is a shame. I learned a lot. About all kind of interesting languages I have never looked at before. About algorithms and techniques I had never seen. About the sensitivity of developers to anything that might sound like criticism of their babies. About being humbled by programmers more skillful than I. It's been fun as well as pain.

ejolson
Posts: 3232
Joined: Tue Mar 18, 2014 11:47 am

### Re: Introduction to BBC BASIC

Heater wrote:
Tue Jul 16, 2019 7:12 pm
That is a shame. I learned a lot. About all kind of interesting languages I have never looked at before. About algorithms and techniques I had never seen. About the sensitivity of developers to anything that might sound like criticism of their babies. About being humbled by programmers more skillful than I. It's been fun as well as pain.
As this is his thread, it's worth noting that Richard's BBC Basic seems to handle the INT function in a reasonable way.

At the same time, unexpected results happen all the time in any type of nontrivial project--especially with research related the end of the golden age of personal computing.

jahboater
Posts: 4595
Joined: Wed Feb 04, 2015 6:38 pm

### Re: Introduction to BBC BASIC

ejolson wrote:
Tue Jul 16, 2019 7:20 pm
As this is his thread, it's worth noting that Richard's BBC Basic seems to handle the INT function in a reasonable way.
Yes it handles out of range errors well, but I do find it strange that it truncates towards minus infinity rather than zero as is the norm. Is there something mathematical I am missing, because Python division does the same?

ejolson
Posts: 3232
Joined: Tue Mar 18, 2014 11:47 am

### Re: Introduction to BBC BASIC

jahboater wrote:
Tue Jul 16, 2019 7:29 pm
ejolson wrote:
Tue Jul 16, 2019 7:20 pm
As this is his thread, it's worth noting that Richard's BBC Basic seems to handle the INT function in a reasonable way.
Yes it handles out of range errors well, but I do find it strange that it truncates towards minus infinity rather than zero as is the norm. Is there something mathematical I am missing, because Python division does the same?
The mathematical definition usually says that INT(x) is the greatest integer less than or equal x. The advantage over truncation is that this definition does not require decimal (or diadic) expansions.