Introduction to BBC BASIC

[ejolson]

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]

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]

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]

gives me a chance to fully grock the code

A quick point of language - it's "grok", not "grock".

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]

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]

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]

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]

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]

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]

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]

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]

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

[RichardRussell]

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]

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]

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.

[RichardRussell]

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.

[DavidS]

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.

[Heater]

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]

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

[Heater]

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]

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

[Heater]

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]

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]

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]

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.