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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:58 pm

ejolson wrote:
Thu Jan 10, 2019 7:36 pm
I had the opportunity to avoid Waterloo BASIC but ended up using it under VM/CMS. I can't remember what the code did, but only that it was very slow in comparison to FortranG and VSPascal on the same system. I also remember being astonished at the uses of a virtual punch card reader.
I worked as a systems programmer on an Amdahl mainframe running VM/CMS and had fond memories of it. VS Fortran was the fastest language around. REXX was the most fun language. I also ran UNIX in a VM (Amdahl UTS) which of course had a C compiler. Never saw any kind of BASIC on the machine.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 8:12 pm

ejolson,

I have only ever heard of Waterloo BASIC but I loved the Watcom C compiler. When 32 bit 386 and 486 PC's became available and MS-DOS was stuck in it's 16 bit stone age, the Watcom C compiler enabled one to easily use all the memory available on those new machines as a flat 32 bit address space, no more messing around with 16 bit segments, NEAR and FAR pointers etc. It was awesome power!

Yeah, I always imagined GPU's were great for "embarrassingly parallel" algorithms where hundreds or thousands of little jobs can be crunched in isolation. Not so good if they are all interdependent and interconnected. It's all down to Amdahl's Law.
I suspect it reasonably reflects the RISCOS BASIC programming environment as typically used. In comparison to how the current Linux programming environment is used, this would be similar to writing your own implementation of the doubling formulas to compute Fibonacci numbers with GMP doing the big-number arithmetic either behind the scenes or explicitly.
The difference, to my mind at least, is that if you say your solution is written in C and uses no non-standard C features or libraries then using GMP is out. But if you say your solution is in RISC OS BASIC I can well imagine using RISC OS features is all part of that "standard".

Given the total lack of any standard for "BASIC" it all gets a bit wibbly-wobbly.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 8:20 pm

jahboater wrote:
Thu Jan 10, 2019 7:58 pm
ejolson wrote:
Thu Jan 10, 2019 7:36 pm
I had the opportunity to avoid Waterloo BASIC but ended up using it under VM/CMS. I can't remember what the code did, but only that it was very slow in comparison to FortranG and VSPascal on the same system. I also remember being astonished at the uses of a virtual punch card reader.
I worked as a systems programmer on an Amdahl mainframe running VM/CMS and had fond memories of it. VS Fortran was the fastest language around. REXX was the most fun language. I also ran UNIX in a VM (Amdahl UTS) which of course had a C compiler. Never saw any kind of BASIC on the machine.
My recollection is the advantage of FortranG at the time was that it was free. Waterloo BASIC was an official IBM product, so you didn't have to acquire it from a third party. Is there anything more fun than using EBCDIC to write C code?

If REXX had been used in place of Python, would yours and my favourite single-board computer then be called the Raspberry Rex? The current logo might look even nicer with a crown on top. Here is a version of the Fibonacci code written in NetRexx.
Last edited by ejolson on Thu Jan 10, 2019 8:43 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 8:40 pm

ejolson wrote:
Thu Jan 10, 2019 8:20 pm
My recollection is the advantage of FortranG at the time was that it was free.
I have never heard of FortranG. We used IBM's VS Fortran product. Very very fast, I tried a couple of times to beat it by writing assembler and failed. The compiler was retained in memory in shared segments. It was used for university post grad research work.
ejolson wrote:
Thu Jan 10, 2019 8:20 pm
Is there anything more fun than using EBCDIC to write C code?
In my UNIX VM it was all ASCII, thank the lord!!!!
Printing was an issue because the printers used EBCDIC and there were problems with the translation.
The computer centre manager was an IBM man and would not pay for a C compiler for CMS, after all you had a very good assembler, why not use that :(
To be fair it was a very good assembler and the VM/SP source code was beautiful.
ARM assembler on the Pi was likely inspired by it.

REXX was clever because it was the "System Product Interpreter". Which meant that if any program such as an editor (Xedit) or a database, or the OS, or anything else, needed a scripting language, REXX would do the job. As well as being a great general purpose language.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 9:06 pm

jahboater wrote:
Thu Jan 10, 2019 8:40 pm
ejolson wrote:
Thu Jan 10, 2019 8:20 pm
My recollection is the advantage of FortranG at the time was that it was free.
I have never heard of FortranG.
It seems I've got the name slightly wrong as I'm unable to find any reference by searching. It was an older 66-standards compliant compiler from IBM. Among other things, I used that compiler to write a graphical front end, indexing system and spectrum matching search for what was at that time a fairly large mass-spectrometry database.

Steve Drain
Posts: 105
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 9:19 pm

Heater wrote:
Thu Jan 10, 2019 7:31 pm
That is interesting. I never knew RISC OS had such a big numbers module built in before you mentioned it.
It does not. You soft-load the module and it become part of the OS. You can do this with a multitude of modules. RISC OS is very modular. :-)
I'm puzzling how this fits with the agreed aims of the fibo(4784969) challenge.
I do not think it does, but it is interesting. :-)

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 10:20 pm

Seems it does not fit the challenge.

What the heck, I'd like to see it.

Hey, nobody presented a solution where a big number arithmetic was written as a Linux kernel module, load it up before you run your code!

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 10:52 pm

Heater wrote:
Thu Jan 10, 2019 10:20 pm
Seems it does not fit the challenge.

What the heck, I'd like to see it.

Hey, nobody presented a solution where a big number arithmetic was written as a Linux kernel module, load it up before you run your code!
The reason things like the Linux Crypto API exists, is because some hardware requires running in ring 0 to access certain cryptographic features? If there were any big-number hardware (perhaps a cryptographic accelerator for RSA) that required similar privileges to work, that would lead the way to getting a big-number API accepted into the kernel. As things are, it might be easier to add a big-number module to systemd callable through dbus. Maybe gcc could be assimilated at the same time for convenience.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 12:21 am

Heater wrote:
Thu Jan 10, 2019 8:12 pm
ejolson,

I have only ever heard of Waterloo BASIC but I loved the Watcom C compiler. When 32 bit 386 and 486 PC's became available and MS-DOS was stuck in it's 16 bit stone age, the Watcom C compiler enabled one to easily use all the memory available on those new machines as a flat 32 bit address space, no more messing around with 16 bit segments, NEAR and FAR pointers etc. It was awesome power!

Yeah, I always imagined GPU's were great for "embarrassingly parallel" algorithms where hundreds or thousands of little jobs can be crunched in isolation. Not so good if they are all interdependent and interconnected. It's all down to Amdahl's Law.
I suspect it reasonably reflects the RISCOS BASIC programming environment as typically used. In comparison to how the current Linux programming environment is used, this would be similar to writing your own implementation of the doubling formulas to compute Fibonacci numbers with GMP doing the big-number arithmetic either behind the scenes or explicitly.
The difference, to my mind at least, is that if you say your solution is written in C and uses no non-standard C features or libraries then using GMP is out. But if you say your solution is in RISC OS BASIC I can well imagine using RISC OS features is all part of that "standard".

Given the total lack of any standard for "BASIC" it all gets a bit wibbly-wobbly.
If you are developing code in a GNU/Linux programming environment, then GMP is standard. It is actually a build dependency for gcc even though C as described in common standards doesn't have built-in big numbers.

Loading modules and talking to them through software interrupts is essentially how RISCOS implements shared libraries, so the missing BBC BASIC code is much like the Haskell code in that the programmer has reached the point of coding the doubling formula but the resulting big number computations are done using code written by someone else. While such things are fine, it is worth noting that the doubling formula are much simpler than the algorithms behind big-number arithmetic. Therefore, if one is wanting to determine which languages have the ability to liberate the person who learns them so that they can program complicated new algorithms, the exercise is yet to be done with respect to either Haskell or RISCOS BASIC.
Last edited by ejolson on Fri Jan 11, 2019 7:13 am, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 12:28 am

I found a few minutes to play with threading the C++ fibo() again. This time I attacked the karatsuba multiplication rather than the fibo() itself.

I hacked the karatsuba "shuffle" to use threads if the big integer arrays are bigger than 4096 elements (about 40,000 decimal digits):

Code: Select all

        // Do da karatsaba shuffle, yabba dabba do.
        if ((this->width > (1<<12)) && (b.width > (1<<12))) { 
            auto f0 = std::async([low1, low2  ](){ return(low1 * low2) ; });
            auto f2 = std::async([high1, high2]( { return(high1 * high2); });
            z1 = (low1 + high1) * (low2 + high2);
            z2 = f2.get();
            z0 = f0.get();
        } else {
            z0 = low1 * low2;
            z1 = (low1 + high1) * (low2 + high2);
            z2 = high1 * high2;
        }
With results like this:

Code: Select all

$ time ./fibo_karatsuba_serial | tail -c 32
4856539211500699706378405156269

real    0m0.635s
user    0m0.609s
sys     0m0.031s

$ time ./fibo_karatsuba_parallel | tail -c 32
4856539211500699706378405156269

real    0m0.308s
user    0m0.828s
sys     0m0.609s
A speed up of almost exactly 2. Not so impressive for an 4 core, 8 hyper thread, machine. But compares favorably with the parallel C version:

Code: Select all

$ time ./parallel | tail  -c 32
4856539211500699706378405156269

real    0m0.249s
user    0m1.406s
sys     0m0.031s
With the recursive nature of all this I find it hard to fathom what actually happens. How many threads does that actually end up running? If it's more than the number of hyper threads that will slow things down. Perhaps it's not enough? Perhaps we can figure a smarter way to determine when to spawn a thread and when not?

The fact that the results show a user time of 0.8 secs vs the C version's 1.4 secs hints to me that I have not been using as much of the available cores as I could.

I should tweak my google benchmark to find out exactly at what size numbers using threads starts to help and when it hinders.

User avatar
Gavinmc42
Posts: 3736
Joined: Wed Aug 28, 2013 3:31 am

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 12:58 am

I got Sakaki to explain to me how she does big builds for Gentoo64.
Elsewhere she has described her PC, it's serious hardware ;)
I think I need to upgrade my PC and Pi3B+ storage.
The only thing I seem to do in shops these days is check uSD card prices.

Who is the law of "Data fills all available storage" named after?
Mostly now for emerges etc. I work on a QEMU binfmt_misc aarch64 chroot on a PC workstation. As explained in my wiki article about it (here), this allows me to have a large tmpfs-based /var/tmp/portage, and sufficient memory that swapping is not necessary during builds. Root (and boot) for the build system is on a 250GB Samsung SSD connected via a Sabrent USB adaptor - when building on a PC this can take advantage of the USB3 interface speed. For odd packages that won't build in this way, I simply boot the same image on a regular RPi3B+, and, where possible, distribute the build using distcc (as explained here ff.)

For testing, I currently write the image to a 64GB Sandisk Extreme Pro class A2 microSD card, pretty happy with the speed of this.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 12:59 am

ejolson,
If you are developing code in a GNU/Linux programming environment, then GMP is standard.
Mostly true. However I have worked on many Linux systems that are very minimalist and do not have a GMP. Embedded systems.
It is actually a build dependency for gcc even though C as described in common standards doesn't have built-in big numbers.
Yes, that's my point. It's not C standard, no matter what GCC does. Ergo does not qualify for the fibo(4784969) challenge.
Loading modules and talking to them through software interrupts is essentially how RISCOS implements shared libraries, so the missing BBC BASIC code is much like Haskell code...
I think it's very different. Haskell has the concept of big integers built into the syntactic and semantic definition of the language. BBC BASIC does not. How Haskell actually does it under the hood is beside the point. See previous posts here about this.
...in that the programmer has reached the point of coding the doubling formula but the resulting big number computations are done using code written by someone else.
True. Remember though that the fibo(4784969) challenge does not state that you have to write your own big integer arithmetic. It only asks to calculate big fibos using the language of your choice whilst not using non-standard language features or libraries. If your chosen language supports big integer maths you are home dry, if not you have work to do...
While such things are fine, it is worth noting that the doubling formula are much simpler to code than the algorithms behind big-number arithmetic. Therefore, if one is wanting to determine which languages have the ability to liberate the person who learns them so that they can program complicated new algorithms, the exercise is yet to be done with respect to either Haskell or RISCOS BASIC.
Well, I agree. If the aim is to get people to learn, think about and implement all the algorithms involved then yes. It's just that anything after fibo is out of scope for the challenge. Where does one draw the line? For example we are now both using threads, are we cheating by using OpenMP, Cilk, C++ std::async? Should we be writing our own thread scheduler...operating system...to do that efficiently?

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 1:12 am

Heater wrote:
Tue Jan 08, 2019 2:59 pm
ejolson,
expressiveness -
The quality of effectively conveying an algorithm to a CPU or similar computing hardware.


From a clarity and syntax point of view there may be a difference, but from the computer's point of view both expressions express the same thing and in this sense are exactly equally expressive.
Ah yes.

There is that aspect of "expressiveness", who, or what, are we making the expression to? Who is the audience?
While grandma always likes a nice line-numbered BASIC code printed out on green-striped fan-fold paper around the holidays, the intended recipient of most computer programs is, in fact, a computer.

Having reached the natural conclusion that machine code is unsurpassed in expressiveness, it suddenly makes sense why corporate vendors provide their proprietary software in the form of binary executables. Still, one is faced with the inconvenient fact that machine code doesn't look as pretty as BASIC when printed on green-striped fan-fold paper. Therefore, the path to digital liberation is unlikely a second curricular reform that replaces Scratch and Python with toggling in machine code using switches and blinking lights, even if a Raspberry Pi is involved. While it is important for a language to be expressive to the CPU, other aspects such as readability by the programmer and productivity are also important.

Readability and productivity are subjective and difficult to measure. Given the number of views this thread has received, I'm expecting anyday that someone will testify they found the version in line-numbered BASIC easiest to understand. Likely such testimony hasn't already appeared because the prospective new member is having trouble with the captcha.

Expressivity to the CPU, on the other hand, can be measured quantitatively: time how long the program takes to run. While a factor of two loss in performance is huge, I would suggest that any language which is no slower than half the speed of the best engineering effort is expressive enough to be liberating. Programming languages which can not reach this modest level of performance, no matter how nice in other ways, also inflict a form of digital servitude. The programmer who uses them is unable to create new algorithms of any significant complexity and must instead rely on built-in features and subroutine libraries.

In my opinion, in order for the second age of personal computing to be successful, the effort spent learning to program must liberate a person from digital servitude. This means the language chosen must be expressive enough. Lack of expressivity may be a reason to avoid Basic.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 1:35 am

Heater wrote:
Fri Jan 11, 2019 12:59 am
True. Remember though that the fibo(4784969) challenge does not state that you have to write your own big integer arithmetic. It only asks to calculate big fibos using the language of your choice whilst not using non-standard language features or libraries. If your chosen language supports big integer maths you are home dry, if not you have work to do...
Fair enough, as it was your challenge. I've tried to modify it to my own interests!

As I want to measure how expressive a language is to the CPU by how efficiently the code runs, it makes an important difference which compiler and what libraries are used behind the scenes. For example, if a particular Haskell compiler used an O(n^2) multiplication routine or worse for the built-in big numbers, can you write your own that works better if Haskell is the only language you know. What if you are working on a new technique that turns O(n^1.58) into O(n^1.38)? Does the programming language give you the freedom to efficiently express your new algorithm.

If a student is lucky enough that the answers are in the back of the book, that doesn't usually mean they shouldn't do the exercises. For me the challenge is not finding million-digit Fibonacci numbers, but answering the questions why avoid BASIC and what led to the end of the golden age of personal computing. Moreover, I'm interested how to reverse the current trend towards digital feudalism with a second age of personal computing that lasts.

This is not to say Fibonacci numbers aren't interesting. At least we haven't been computing million digit approximations to Pi--that would not have been off topic enough.
Last edited by ejolson on Fri Jan 11, 2019 1:54 am, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 1:52 am

ejolson,

I pretty much agree with all that. With a few niggles of course...
While it is important for a language to be expressive to the CPU, other aspects such as readability by the programmer and productivity are also important.
That is what I said here a page or so back.
...the path to digital liberation is unlikely a second curricular reform that replaces Scratch and Python with toggling in machine code using switches and blinking lights,
Actually, an eye opening part of my early programming experience was almost exactly that. We had the processor but we did not have any software, not even an assembler, just the chips. Motorola 6809 as it happened. The first problem was to build a computer out of that adding RAM, ROM, serial port etc on a wire wrap board. Then the programming... nothing for it but to write down the assembler instructions on paper then assemble them manually into hexadecimal then load that into the EPROM programmer via paper tape. Except we wrote the program we wanted in a pseudo code that looked like ALGOL 69 first, then compiled that manually on paper into assembler.

Before long we had a debug monitor up and running on that board, including a program loader from cassette tape, commands to display/set memory and registers, run the code, single step, etc.

I think everyone serious about programming should have that experience!
The programmer who uses them is unable to create new algorithms of any significant complexity and must instead rely on built-in features and subroutine libraries.
Kind of true except many algorithms invented to speed things up have been invented by people who don't even program. They are called mathematicians. For example the Fast Fourier Transform was first discovered by Gauss. Famously Tukey also had the FFT idea in the 1960's, but it was down to Cooley to turn that algorithm into a computer program. At that point it would not have mattered if Cooley wrote the FFT in assembler or slow interpreted BASIC, it would still have been faster than doing it the way people did.

No matter what you know about programming or how brilliant you are at it if you don't have the maths chops you ain't going to find it.
In my opinion, in order for the second age of personal computing to be successful, the effort spent learning to program must liberate a person from digital servitude. This means the language chosen must be expressive enough.
Yes.
Lack of expressivity may be a reason to avoid Basic.
Dijkstra (and I) agree with you.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 2:15 am

ejolson,
Fair enough, as it was your challenge. I've tried to modify it to my own interests!
It's all good stuff. I enjoy the debate. Also my off the cuff challenge has led me to all kind of things I was not expecting when I thought of it. Including learning some new C++ tricks.
This is not to say Fibonacci numbers aren't interesting.
The Fibonacci numbers aren't the main point for me even. That was just the first thing that came to mind when I wanted DavidS to support his claim that BASIC is so easy. Could well have been a million digits of PI or something to do with big primes...

I do appreciate your concern for performance. That is somewhat orthogonal to language implementations. If I wrote a C compiler it would be horribly slow!

I very much appreciate your ideas about getting folks to think about algorithms and how we will never get algorithmic improvements if they only lean on what is available in existing languages and libraries.

I suspect a language like Haskell is something that could be used to express all kind of algorithms nicely, once one is familiar with it. For example karatsuba. Nothing stopping people implementing that in Haskell as a learning exercise. I have no idea if the end result would be as efficient as Haskell's built in big math or what we can do in C/C++. I though Paeryn was going to have a go at that.

Funnily enough I stumbled across a big integer maths class in Java the other day. The author claimed he wrote it because he wanted something faster than what came out of the box with Java!

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 2:18 am

Now, as a practical matter, what are we going to do about making efficient use of multiple cores for this problem?

Neither of us seem to have done very well with that so far.

Is this problem somehow impervious to parallel processing?

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 2:37 am

Hey jahboater,

Your GCC build script is not entirely happy. It builds my C++ fibo but the executable does not run:

Code: Select all

$ /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --enable-languages=c,c++ --enable-checking=no
Thread model: posix
gcc version 8.2.0 (GCC)
$
$ /usr/local/bin/g++ -std=c++17 -Wall -Wextra -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp -lpthread
$
$ ./fibo_karatsuba
./fibo_karatsuba: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by ./fibo_karatsuba)
$
Edit:

That's odd. I though it worked earlier today.

This gets it working again...

Code: Select all

$ export LD_LIBRARY_PATH=/usr/local/lib64
$ time ./fibo_karatsuba | tail -c 32
4856539211500699706378405156269

real    0m0.317s
user    0m1.125s
sys     0m0.438s
[code]

User avatar
Paeryn
Posts: 2669
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 5:19 am

Heater wrote:
Fri Jan 11, 2019 2:15 am
I suspect a language like Haskell is something that could be used to express all kind of algorithms nicely, once one is familiar with it. For example karatsuba. Nothing stopping people implementing that in Haskell as a learning exercise. I have no idea if the end result would be as efficient as Haskell's built in big math or what we can do in C/C++. I though Paeryn was going to have a go at that.
Karatsuba should be doable in Haskell relatively cleanly, though it might get a bit messy using lists of Ints to represent Integers. Haskell has Arrays which might be better, though I've not used them before (and I don't know how they are implemented), looks like I've got some reading up to do.

I've not had much opportunity to do much programming, one of my cats (the one in my profile pic) has taken to doing what he is on there, only in front of my monitor whilst sat on the keyboard, every time he sees me at the computer. He's not a very good typist and he thinks the monitor is a touch screen, he's nearly toppled it a few times playing "catch all the windows that keep appearing from the random keypresses".
She who travels light — forgot something.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 6:11 am

Heater wrote:
Fri Jan 11, 2019 1:52 am
Kind of true except many algorithms invented to speed things up have been invented by people who don't even program. They are called mathematicians. For example the Fast Fourier Transform was first discovered by Gauss. Famously Tukey also had the FFT idea in the 1960's, but it was down to Cooley to turn that algorithm into a computer program. At that point it would not have mattered if Cooley wrote the FFT in assembler or slow interpreted BASIC, it would still have been faster than doing it the way people did.
Ask any (former) communist and they will tell you true freedom lies in the ability to do something not the ability to think about it. The same is true with authentic Christianity. In an IT setting James 2:18 may be translated as
Yea, a man may say, Thou hast algorithms, and I have code: shew me thy algorithms without thy code, and I will shew thee my algorithms by my code.
While something appears to have been lost in translation, an important consequence of being freed from sin is that a person can then go out and do good things. This is the freedom of doing.

Gauss wrote down the divide-and-conquer step of the FFT on some paper discovered in his desk. The fact that he did not publish indicates he felt his work was incomplete. In addition to a missing analysis of the asymptotic time complexity and many of the relevant applications, the main obstacle to publication may have been lack of a suitable computer program written in line-numbered BASIC. Latin pseudo code is just not expressive enough, especially on today's computing hardware. Notably though, he did more than just write the idea down: His notes also contain computational examples involving interpolation. At any rate, Gauss as well as both Cooley and Tukey were mathematicians.

Back in those days there weren't any separate computer science programs or departments. As computers became more popular, the mathematicians knowledgeable about computers realised they could have higher salaries if they formed a separate department. They also wouldn't have to teach service courses filled with students disinterested in learning calculus. Unfortunately, teaching students disinterested in C++ is just as bad.

Thinking up algorithms is nice as are higher salaries; however, digital liberation comes through personal computing by providing people the language skills necessary to write programs so the computer efficiently does what they want it to do and not what someone else decided. Since BASIC initiated the golden age of personal computing why avoid it now?
Last edited by ejolson on Fri Jan 11, 2019 8:07 am, edited 5 times in total.

User avatar
Gavinmc42
Posts: 3736
Joined: Wed Aug 28, 2013 3:31 am

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 6:31 am

Just found out there are pre-built binaries for LLVM/Clang
http://releases.llvm.org/download.html

I have only tested the 3.9.1 AArch64 version, it works enough to report it's version/help etc.

Someone who is really determined or OCD could try all versions.
The armv7a version will run in 32bit Raspbian?

I was not looking forwards to making another C compiler.
Hopefully one day RISC-V prebuilt too?
Whoops that another post ;)
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 7:49 am

Paeryn wrote:
Fri Jan 11, 2019 5:19 am
I've not had much opportunity to do much programming, one of my cats (the one in my profile pic) has taken to doing what he is on there, only in front of my monitor whilst sat on the keyboard, every time he sees me at the computer. He's not a very good typist and he thinks the monitor is a touch screen, he's nearly toppled it a few times playing "catch all the windows that keep appearing from the random keypresses".
My cat deliberately and carefully stands in front of the screen to get my attention. Fortunately she avoids BASIC and keeps off the keyboard.
Trouble is she also sleeps on top of the tower PC (its warm) and moves around in her sleep, occasionally falling off. If she is quick enough she grabs anything on the way down, toppling the PC a couple of times.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 8:47 am

Heater wrote:
Fri Jan 11, 2019 2:37 am
That's odd. I though it worked earlier today.

This gets it working again...

Code: Select all

$ export LD_LIBRARY_PATH=/usr/local/lib64
$ time ./fibo_karatsuba | tail -c 32
4856539211500699706378405156269

real    0m0.317s
user    0m1.125s
sys     0m0.438s
For the sanitizers, I need:
LD_PRELOAD=/usr/local/lib64/libasan.so:/usr/local/lib64/libubsan.so
otherwise I have never needed to worry about lib64.

I presume you are using a 64-bit release of Linux Mint?
I use 64-bit Mint 18.3

Steve Drain
Posts: 105
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 9:19 am

Heater wrote:
Thu Jan 10, 2019 10:20 pm
What the heck, I'd like to see it.
There would be little point, and later comments make it clear that it is not really of much interest, because it is not using just the [a] BASIC language.

It is essentially just a transliteration of the best doubling algorithm that has appeared here in various guises. I could say that the BASIC language looks clearer than most, and hence more 'expressive', but I would, wouldn't I? :-)

If, and it is a big if, I substitute BASIC routines for the Numbers SWIs and the result does the calculation in less than a lifetime, then it might be worth publishing. There is hope, because BBC BASIC can do some whole array operations, eg:

Code: Select all

c()=a()+b()
This is extremely fast and can be even faster with VFP double-float support.

Steve Drain
Posts: 105
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 9:35 am

ejolson wrote:
Fri Jan 11, 2019 12:21 am
Loading modules and talking to them through software interrupts is essentially how RISCOS implements shared libraries, so the missing BBC BASIC code is much like the Haskell code in that the programmer has reached the point of coding the doubling formula but the resulting big number computations are done using code written by someone else. While such things are fine, it is worth noting that the doubling formula are much simpler than the algorithms behind big-number arithmetic. Therefore, if one is wanting to determine which languages have the ability to liberate the person who learns them so that they can program complicated new algorithms, the exercise is yet to be done with respect to either Haskell or RISCOS BASIC.
All that is true. However, consider this. I have written a module - another one - that extends the BBC BASIC language. Among other things it allows the use of structures and, to a limited extent, classes. Should the whim take me, it would not be very difficult to add bignum support, and the syntax could be as 'expressive' as you like. To do that I would call on the Numbers module to do the grunt, just as many other bits of BASIC are just calling on OS features. If I presented code in this modified BASIC language, as with Haskell, would it be a solution to the challenge? ;-)

Another line is that the bignum routines that have been shown here for C and C++ are essentially composed of multiple loops. This is ripe fodder for assembly, and BBC BASIC has an excellent inline assembler and a very convenient interface. I am with DavidS on this, that writing these loop routines in assembler is not far short in expressivenes to the complex C++ class routines.

Return to “Off topic discussion”