Why Avoid BASIC on RPi?

[Paeryn]

I have now. No change.

Could the problem be related to Linux subsystem for Windows?

No, I tested it on Linux Mint, I've updated my post above which shows gst clearly has a problem with certain LargeInteger maths on the PC (possibly a 64-bit problem?), will have to look at the source code for gst later.

[ejolson]

I have now. No change.

Could the problem be related to Linux subsystem for Windows?

No, I tested it on Linux Mint, I've updated my post above which shows gst clearly has a problem with certain LargeInteger maths on the PC (possibly a 64-bit problem?), will have to look at the source code for gst later.

About 20 years ago I was working on a mathematical model in which certain Bessel and hypergeometric functions appeared in awkward combinations with respect to loss of precision due to rounding error. I tried a well-known computer algebra system that supported arbitrary precision evaluation of those functions and soon discovered for the choice of parameters I needed that most of the 200 digits of precision the software computed were wrong and sometimes all of them. That was commercial software.

A revolutionary way of developing open source software was described by Eric Raymond in his book, The Cathedral and the Bazaar. Last year the open-source compiler FreeBasic generated faulty code for my line-numbered Fibonacci code. Today the cathedral is burning and GNU Smalltalk can't even multiply integers.

If the efforts and hopes of the multitudes accumulated over centuries end like this, then why avoid Basic?

[Gavinmc42]

Reminds me of some solar and lunar recursion calculations for tides I did on 68HC05s long time ago.
The recursion loop was 104 times so floating point gave ridiculous errors every now and again.
Did it in BCD integers and got 1 minute tide accuracy.
With 1440 minutes in each day that was accurate enough

32bit floating point is sometimes not good enough
I have always wondered since then has 32bit float point maths caused accidents?

[timrowledge]

Tim,

If I tweak your fibIterative so that it runs in GNU Smalltalk, like so:

{snip}
It does indeed produce the correct result.

Do I have a bug in my code?

The most likely bug I can think of is that you probably don't know that Smalltalk does *not* futz around with arithmetic stuff for precedence rules. Its strictly left to right sending messages. Why? Because it's simpler to read when non-arithmetic stuff can be mixed in as well. Consistency internally, as it were. Yes, it annoys some people. No it doesn't cause pimples.
Now my problem in looking at that fast-fibonacci website (neat!) is that the example implementations are all in languages I find confusing and annoying. So let's see... i before * except after mod unless the sound is \\, right?

OK, this seems to work -

Code: Select all

fastDoublingFib
"derived from https://www.nayuki.io/page/fast-fibonacci-algorithms"
"(1 to: 20) collect:[:i| i fastDoublingFib]"

	| a b c |
	a :=  0.
	b := 1.
	self highBit to: 1 by: -1 do:[:i|
		|d e|
		d := (b bitShift: 1) - a * a.
		e := a squared + b squared.
		a := d.
		b := e.
		(self bitAt: i) = 1  ifTrue:[
			c := a + b.
			a := b.
			b := c]
		].
	^a

... in Squeak. Takes less than 2 millisecond to do 8577 on my Pi 3b+. The full insane 4784969 takes 72 secs on the Pi and 14s on a 3.5GHz i7 with 24Gb ram. Of course, I can spy on the performance in Smalltalk which surprisingly often leads to noticeable performance improvements; maybe I'l find time to do that tomorrow but I suspect that the limit here is the performance of the C code that gets used for the lowest level bit slinging.

[Heater]

Wow WTF?

This fun.... On my Linux for WIndows In Python:

Code: Select all

$ python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 72723460248141 * 72723460248141
5288701670462944237293955881
>>> 7272346024814 * 7272346024814
52887016704627987903734596
>>> 727234602481 * 727234602481
528870167045698091355361
>>> 72723460248 * 72723460248
5288701670442436221504
>>> 100000000000000 * 100000000000000
10000000000000000000000000000
>>>

The same in gst:

Code: Select all

$ gst
"Global garbage collection... done"
GNU Smalltalk ready

st> 72723460248141 * 72723460248141
685887298156391209                                                  ,<---------- WRONG
st> 7272346024814 * 7272346024814
-1468882107384405180                                                      <---- WRONG Negative WTF?!
st> 727234602481 * 727234602481
2014452445246524641                                                      <---- WRONG 
st> 72723460248 * 72723460248
5288701670442436221504                                                      <---- CORRECT
st>
st> 100000000000000 * 100000000000000
4477988020393345024                                                      <---- WRONG 

[Heater]

timrowledge,

The most likely bug I can think of is that you probably don't know that Smalltalk does *not* futz around with arithmetic stuff for precedence rules.

I am old enough, ugly enough and been around the block enough to know not to trust operator precedence rules unless I know the language really well, then one always forgets..

My operation ordering is just fine. The problem is my gst version 3.2.5 cannot multiply:

Code: Select all

st> 2 * 2
4
st> 200000000000000 * 200000000000000
-534791992136171520
st>

And see examples in last post.

This gst 3.9.92 on line works:
https://www.jdoodle.com/execute-smalltalk-online

[Heater]

I thought I'd download and build a gst from the latest sources at gnu.org. http://smalltalk.gnu.org/download

The build tests fail on integer and float maths:

Code: Select all

## -------------------------------- ##
## GNU Smalltalk 3.2.91 test suite. ##
## -------------------------------- ##

Regression tests.

  1: arrays.st                                       ok
  2: classes.st                                      ok
  3: blocks.st                                       ok
  4: sets.st                                         ok
  5: processes.st                                    ok
  6: exceptions.st                                   ok
  7: intmath.st                                      FAILED (testsuite.at:33)
  8: floatmath.st                                    FAILED (testsuite.at:34)

So that is not getting installed.

That seems to be the end of the line for Smalltalk for me. The only language so far that fails the challenge.

Or has anyone got a Smalltalk fibo(4784969) running on Raspbian/Debian?

[Gavinmc42]

Been reading up on Forth again, I think it might be starting to click after reading the 8th webpages.
Perhaps I needed to learn a dozen language to see the advantages of Forth

Anyone done a baremetal Forth yet?
Is there anything like Forth that makes readable code?
The idea of making a MISC on a Lattice FPGA and using Forth on it
Later Forth developments had parallel chips, would it fit in Prop2?

Too bad about Smalltalk, I have not used that before.
Seems a bit old too, nothing new in Smalltalk land?

[Heater]

Gavinmc42,

Perhaps I needed to learn a dozen language to see the advantages of Forth

I did, and I didn't. If you see what I mean. The only advantage of Forth is that it makes the syntax of Smalltalk, Haskell, Erlang etc look tolerable.

For sure hundreds of people have made bare metal Forth for all kind of micro-controllers, micro-processors. No idea about the Pi.

There have been Forths available for the Propeller 1 since forever, and now the Propeller 2.

Unless someone can find me a Smalltalk that runs correctly on Debian I'll never know what is new in Smalltalk land.

[jahboater]

I did, and I didn't. If you see what I mean. The only advatage of Forth is that it makes the syntax of Smalltalk, Haskell, Erlang etc look tolerable.

Long ago I had a Jupiter Ace computer. This was basically a Sinclair zx81 that ran Forth instead of BASIC (which was why I bought it).
Forth was many times faster than the same machine running BASIC.

[jahboater]

Life is too short to write a fibo(4784969) in assembler by hand.
Here is a hand written assembler fibo(24) for amusement. It will go up to 93 which is the largest that will fit in 64-bits.
Its only claim to fame is its small size, the executable is 274 bytes, and that it has zero dependencies (needs no libraries).
Its no faster than the C version of course (less than 1ms user CPU time).

Code: Select all

/*
 *  Calculate the 24th fibonacci term using A64
 *
 *  as fibo.s -o fibo.o && ld -s fibo.o -o fibo
 */

.globl _start
.text

_start:

  /*
   *  Fibonacci loop, result in X0
   */
  mov   w3,23    // target fibo term - 1
  mov   x1,1
  mov   x2,0
loop:
  add   x0,x2,x1
  mov   x2,x1
  mov   x1,x0
  sub   w3,w3,1
  cbnz  w3,loop

  /*
   *  Print the result to a decimal string
   */
  adr   x1,message
  add   x4,x1,1       // save end of buffer (and include the LF)
  mov   w2,10
digit:
  udiv  x3,x0,x2      // n / 10
  msub  x0,x3,x2,x0   // n % 10
  orr   w0,w0,48      // convert to ascii
  strb  w0,[x1,-1]!   // write byte and dec ptr
  mov   x0,x3
  cbnz  x3,digit

  /*
   *  Display result in X1
   */
  mov   w8,64      // write syscall number
  mov   w0,1       // fd
  sub   x2,x4,x1   // length
  svc   0

  /*
   *  Exit the program
   */
  mov   w8,93
  svc   0

.data

  /*
   *  Space for the result as an ascii string
   *  Increase for larger terms (fibo(93) needs 20 bytes)
   */
.zero 5
message:
.byte 10

[Heater]

Correction:

The only advantages of Forth are that it makes the syntax of Smalltalk, Haskell, Erlang etc look tolerable and made BASIC look fast back in the day.

[ejolson]

I thought I'd download and build a gst from the latest sources at gnu.org. http://smalltalk.gnu.org/download

The build tests fail on integer and float maths:

Code: Select all

## -------------------------------- ##
## GNU Smalltalk 3.2.91 test suite. ##
## -------------------------------- ##

Regression tests.

  1: arrays.st                                       ok
  2: classes.st                                      ok
  3: blocks.st                                       ok
  4: sets.st                                         ok
  5: processes.st                                    ok
  6: exceptions.st                                   ok
  7: intmath.st                                      FAILED (testsuite.at:33)
  8: floatmath.st                                    FAILED (testsuite.at:34)

So that is not getting installed.

That seems to be the end of the line for Smalltalk for me. The only language so far that fails the challenge.

Or has anyone got a Smalltalk fibo(4784969) running on Raspbian/Debian?

The fact that there are regression tests which fail suggests the Debian maintainer might also have known something was wrong and shipped the package anyway. Still, one can never fully know what things led to this and other misfortunes. Is it possible that GNU Smalltalk links to a library like GMP which has also burned? If Linux Subsystem for Windows had a GUI with a mouse you could try Squeak.

When built-in language features and subroutine libraries function in such unexpected an unreliable ways, one wonders how many eyes in the bazaar were blind and longs for the cathedral to be rebuilt with even greater reverence.

[Heater]

With this rude and crude little loop I find that our doubling formula fibo agrees with Tim's iterative fibo about 20% of the time.

Code: Select all

n := 1
10000 timesRepeat: [ | a b | 
    n printNl.
    a := n fibo printNl.
    b := n fibIterative printNl.
    (a = b) printNl.
    n := n + 1
]

Mind you I have not checked that Tim's is correct here all the time either. But they should not be different right?

There has not been a stable release of GNU Smalltalk since 4/8/13. The last alpha release was 11/7/15.

With this random error it's quite likely it was tested and passed.

I conclude that not many people in the bazaar are using Smalltalk and there are no maintainers left.

Whilst the bazaar code will no doubt have bugs I'm not sure why you conclude the cathedral code will have less.

These results are rather bizarre anyway.

If Linux Subsystem for Windows had a GUI with a mouse you could try Squeak.

The suggestion by the Squeak folks is to install an X server in Windows and have Squeak in the LSW display on it.

That is not going to happen here. Frankly if Smalltalk requires YAF GUI IDE to write a 10 line Fibonnaci program it's not for me.

[jahboater]

That is not going to happen here. Frankly if Smalltalk requires YAF GUI IDE to write a 10 line Fibonnaci program it's not for me.

It is also a problem on headless Pi's (like mine).

Perhaps GST should be fixed to use GMP which is fast, well proven, and widely used by other languages that support big ints.
The is also MPFR which provides high quality arbitrary precision floating-point (with IEEE semantics).

[timrowledge]

Or has anyone got a Smalltalk fibo(4784969) running on Raspbian/Debian?

I'm certainly not going to defend the specific gnu implementation of Smalltalk - it's clearly sorely lacking. Generalising that to "Smalltalk can't do it" is a bit silly though.

I've given a working implementation and results and timings for a real Smalltalk running on a Pi, so yes, somebody does have a functioning "Smalltalk fibo(4784969) running on Raspbian/Debian". I have no doubt that it could be done on a RISC-V cpu just as well as on all the other cpus that have working Smalltalk systems available.

[timrowledge]

Too bad about Smalltalk, I have not used that before.
Seems a bit old too, nothing new in Smalltalk land?

Well let's see, Squeak is updated somewhat almost every day as people work on things, ditto the Pharo fork (aimed more at commercial needs), VA Smalltalk from Instantiations is still under active development and has recent product releases, GemTalk (a yuuuuugedatabase system in Smalltalk) has recent updates, Smalltalk/X is activley developed, and there must be another half-dozen implementations active out there.
GST is a single, small, limited, not actively developed, project that has rarely had more than one person involved and seems to be aimed at being a commandline scripting thing. Basing an opinion about Smalltalk overall on that example is foolish in the extreme. I'm pretty sure a copy of GWBasic wouldn't run on Heater's RISC-V board - do we then claim that no BASIC could? Didn't think so.

[Heater]

Tim,

Generalising that to "Smalltalk can't do it" is a bit silly though.

I did not say that. I'm sure it can be done in Smalltalk.

My question is how do I get it to do it for me?

gst seems to be broken. So what next?

[timrowledge]

My question is how do I get it to do it for me?

gst seems to be broken. So what next?

I don't have much experience in trying to do commandline run stuff but I do know that some people do; I'll ask on the squeak forums to see if anyone has a plausible solution that won't use up too much effort.
What C environment do you have for building the VM? GCC plus typical unix/ansi libraries? Less, more, different?

[Heater]

Great. All set with GCC and Clang here.

[timrowledge]

Great. All set with GCC and Clang here.

Any sort of display stuff ? Even a framebuffer ?

[Heater]

Yay! After 6 hours Tim's iterative fibo(4784969) produced a result on my PC.

Code: Select all

$ cat fibo.gst
Integer extend [
    fibIterative [ | a b |
        a := b := 1.
        (self - 1) timesRepeat: [
            a := b + (b := a)
        ].
        ^b
    ]
]

4784969 fibIterative printNl.

$ time gst -g fibo.st > results.txt

real    382m27.801s
user    301m9.922s
sys     80m48.891s

$ head results.txt -c 32
10727395641800477229364813596225
$ tail  results.txt -c 32
4856539211500699706378405156269

Which I believe is correct.

[Heater]

timrowledge,

Any sort of display stuff ? Even a framebuffer ?

I can only reach my Pi via SSH. Or there is the LSW terminal on my PC.

I don't want to start messing around with X Windows servers or VNC.

[timrowledge]

Yay! After 6 hours Tim's iterative fibo(4784969) produced a result on my PC.

Crikey; that does rather show up the difference in algorithms.

[timrowledge]

I can only reach my Pi via SSH. Or there is the LSW terminal on my PC.

Wait a minute - I thought you were trying to run this stuff on a bare-metal-RISC-V-thing?