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

Re: Why Avoid BASIC on RPi?

Wed Jan 30, 2019 7:12 am

Heater wrote:
Tue Jan 29, 2019 7:47 am
I'd be tempted to boot up a 2001 vintage Linux distribution in a virtual machine and use the GCC in there.
That may be what I end up doing. It's definitely no fun debugging the build system for a 20-year-old compiler on 20-year-old hardware.

I've been thinking where this thread started. The original challenge stated that taking 13 seconds or less to compute the 4784969th Fibonacci number on an i7-class CPU was the minimum performance a programming language needed. Best efforts using parallel OpenMP C and C++ programs computed this million-digit number in a fraction of a second. A program written in traditional line-numbered Basic and compiled by the FreeBASIC compiler took less than two seconds and Visual Basic interpreted by the mono just-in-time compiler took less than four seconds. Although both Basic programs performed significantly slower than half the speed of the fastest programs, they easily meet the minimum requirements of the challenge.

The present focus has been on how efficiently a programming language can convey complicated algorithms to the CPU; however, it was also suggested early in this thread that another measure of a language is how many job listings mention proficiency in that language as a requirement. On one hand education is informed by what industry needs; on the other hand industry is guided by the engineering and fundamental research produced by universities.

Although Python was created for teaching, it has become a popular language for practical applications. Although R was developed for academic research, it is an important tool used by industry for processing big data and business analytics. Still, no matter what happens in education, it takes some effort to imagine Basic regaining its former dominance for solving problems in the domain now dominated by Python.

Those who remember punching the comments in column one, the continuation character in column 6 and the statement in column 7 might pause to wonder what kind of snake the serpent from the garden of Eden has become. Indeed, Python as prefigured by Fortran IV may not be as comforting as the memory of Basic recalled by modern structured versions of that language. Moreover, if the goal is digital liberation through a second age of personal computing, then getting a job writing programs for someone else matters not. At the same time, it does help pay the bills.
Last edited by ejolson on Wed Jan 30, 2019 10:08 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Wed Jan 30, 2019 8:45 am

But wait, if you actually have a two decades old machine that works you could install an old distro on it. Debian "Woody" for example:
http://archive.debian.org/debian/dists/

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

Re: Why Avoid BASIC on RPi?

Wed Jan 30, 2019 5:18 pm

Heater wrote:
Wed Jan 30, 2019 8:45 am
But wait, if you actually have a two decades old machine that works you could install an old distro on it. Debian "Woody" for example:
http://archive.debian.org/debian/dists/
Aha, it is currently running Wheezy with a version-4.x system compiler.

That Athlon computer is mysteriously being useful in its present state and unfortunately not available for software upgrades or downgrades. It may be possible to install Woody in a virtual machine somewhere and then copy the resulting executable to the Athlon for testing.

I've been thinking about whether parallel speedup can be realized when computing large Fibonacci numbers using a distributed-memory system such as this super-cheap computing cluster. Given the additional latencies and bandwidth limitations inherent in cluster computing, I wonder whether it is possible to reproduce even the modest parallel scaling we currently have.

Have you added the BBC Basic and Visual Basic programs to the famous Fibonacci code repository? It's difficult to practice avoiding them if they are not there.

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

Re: Why Avoid BASIC on RPi?

Wed Jan 30, 2019 9:56 pm

ejolson,
Have you added the BBC Basic and Visual Basic programs to the famous Fibonacci code repository? It's difficult to practice avoiding them if they are not there.
Ah, no. I was busy avoiding BASIC so it did not happen. I'll try and find time to face it head on and do that tomorrow.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 31, 2019 1:07 am

Found this and wonder if anyone has a copy?
http://www.tasoft.com/tawk.html

I use Awk and Sed in my 24/7 Linux data loggers, a compiled version of these would be interesting.
Free Basic is Compiled which is why it is faster than interpreted.
Never thought about an Awk compiler.

I use it to change the HTML web pages which are just text files for online data loggers.
Thinking about that in C and micropython gave me the brain strain.
I just used Awk and Sed, no need to install extra compilers etc
Wonder how it would compare to JS etc?

Been lots of C/C++ math stuff but what about text handling, Perl, yuk ;)
Suppose you want to search for words in a lot of files, would you use C/C++?
Is Basic easier than C for word searching?

When dealing with humans words are probably more important than maths only a few understand :lol:
So for human machine AI interaction word handling languages would be better?
Understanding humans spoken word recog running on parallel threads/cores?

So what do Siri and others use?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Thu Jan 31, 2019 6:53 am

Interesting. TAWK seems to be dead, unobtainium. Passing around any executables one might find would probably constitute copyright infringement. It's DOS only so not much use anyway.

I'm sure that the likes of Siri employ neural networks, "deep learning". It's all maths...

Actually, I would not say we had a lot of maths going on here. It's all simple stuff, mostly arithmetic, that should be understandable by anyone with a high school education.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 31, 2019 7:25 am

Gavinmc42 wrote:
Thu Jan 31, 2019 1:07 am
Found this and wonder if anyone has a copy?
http://www.tasoft.com/tawk.html

I use Awk and Sed in my 24/7 Linux data loggers, a compiled version of these would be interesting.
Free Basic is Compiled which is why it is faster than interpreted.
Never thought about an Awk compiler.

I use it to change the HTML web pages which are just text files for online data loggers.
Thinking about that in C and micropython gave me the brain strain.
I just used Awk and Sed, no need to install extra compilers etc
Wonder how it would compare to JS etc?

Been lots of C/C++ math stuff but what about text handling, Perl, yuk ;)
Suppose you want to search for words in a lot of files, would you use C/C++?
Is Basic easier than C for word searching?

When dealing with humans words are probably more important than maths only a few understand :lol:
So for human machine AI interaction word handling languages would be better?
Understanding humans spoken word recog running on parallel threads/cores?

So what do Siri and others use?
My impression is that grep is good at searching files for keywords. As far as I know grep, awk and sed were all written in C, likely with some automatic code generation by yacc, lex or both. Hadoop, on the other hand, was written in Java and further designed to search huge collections of files distributed across multiple computers. Google has their own versions of map-reduce not written in Java. I think they avoided Basic as well.

I agree that the algorithms behind artificial intelligence have plenty of maths in them. In my opinion, however, if you want learned prejudices and unpredictable behaviour you're better off hiring a human rather than developing a deep learning neural network. A computer brings the greatest benefits to the human-machine working relationship by being different than the person. If the computer behaved the same as the person, then one or the other would be redundant.

Introducing AI word-based human interactions makes the computer much more complicated to understand. For example, it is impossible to tell whether a neural network will prefer cats or dogs by examining the numerical weights on the connections. At the same time, traditional computer programs written in Basic and other languages can be audited by reading them to see exactly what they will do and how.

The ability for a person to audit the code by reading it is one of the reasons computer literacy is important. The ability for a computer to reliably carry out the instructions specified by the code is the other reason computer literacy is important. Together these two abilities result in a powerful cyborg-like partnership in which the human and the computer both play indispensable roles. Such a partnership distinguishes the second age of personal computing from the servitude of digital feudalism.

Now that it's clear the alternative is deep learning neural-network-based artificial intelligence that takes over the world, why avoid Basic?

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

Re: Why Avoid BASIC on RPi?

Thu Jan 31, 2019 8:11 am

ejolson,

I do enjoy your philosophical asides over a cup of tea in the morning...
In my opinion, however, if you want learned prejudices and unpredictable behaviour you're better off hiring a human rather than developing a deep learning neural network.
I presume that when adopting neural nets, deep learning, etc one gets all the prejudices and unpredictable behavior of humans but with some distinct advantages. The thing operates 24/7 without complaint. It probably works faster. It's probably cheaper, no salaries, no need for comfy working conditions, etc, etc. Sure it has those prejudices and unpredictable behaviors but over all it is a net win.
Introducing AI word-based human interactions makes the computer much more complicated to understand. For example, it is impossible to tell whether a neutral network will prefer cats or dogs by examining the numerical weights on the connections. At the same time, traditional computer programs written in Basic and other languages can be audited by reading them to see exactly what they will do and how.
I'm not totally convinced this is true... It is often impossible to see exactly what a program will do, no matter how carefully one reads the source code. Some examples:

1) Almost any code I write. After a certain level of complexity I start to not understand it anymore. It becomes impossible to fathom how the parts will interact. The simple fibo codes presented here are a good example. Small changes in the code can have huge impact on run time and I might never know exactly why or predict it before actually running it.

2) One could show the equation/procedure for generating the Madlebrot set to any high schooler and they could easily see how it operates and likely write the code to do it. However I posit that if they did not know already they would never be able to tell you what pattern it will draw before they run it. There are many such examples.

3) Presumably one could write a neural net/deep learning algorithm in, for example, BASIC. Then we are, full circle, back in the world of unpredictability you strive to avoid.

I would argue there is not much difference between a neural net and something like the Mandlebrot set. Sure you can find out if the net likes cats or dogs by knowing the weights on the connections, you just have to run it with those weights and see what happens. In the same way that you know what color your Mandlebrot set program will use for a pixel, you just have to plug the coordinates in and run it.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 31, 2019 8:41 am

Did a google and came across spectrograms for words.
They need FFT maths?
Does Sir etc do a spectrograms and then run them thorugh parallel matching filters?
Got my new Lattice fpga vision kit, got two microphones, time to read the examples.

Dig out that old Jetpac? QPU FFT code or would quad core Arm's be faster for FFT's?
Fastest langauge for FFT's = C?
Can FFT's be done in FPGA hardware?

I don't like how PI's keep showing up my ignorance?
Only Google can save me?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Thu Jan 31, 2019 6:10 pm

Yay, fibo_karatsuba just shaved off another 10% or more...

I have been outputting the result using c++ std::cout and "<<". I had long suspected this was a bit slow. At least it has that reputation. Today I pruned the output to just the first and last few digits. And boom, 20% faster!

Before:

Code: Select all

$ time ./fibo_karatsuba | head -c 32
10727395641800477229364813596225
real    0m0.238s
user    0m1.141s
sys     0m0.203s
After:

Code: Select all

$ time ./fibo_karatsuba
1072739564 ... 405156269

real    0m0.213s
user    0m1.203s
sys     0m0.125s
Time to revert to good old printf and/or some custom output formatter.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 31, 2019 6:26 pm

Did a google and came across spectrograms for words. ... They need FFT maths?..Does Sir etc do a spectrograms and then run them thorugh parallel matching filters?
I have no idea but I always assumed the fist thing that happens in any speech/music/sound analysis is that the thing gets stuffed through an FFT. After all, when I'm listening to someone speak I don't much care how loud it is, within reason, but the cochlea in my ears are busy extracting frequency information for my brain to work on. Basically doing an FFT mechanically.

Does it need maths? My ears don't thinks so. They just do it mechanically as I said, there is no maths going on in there. On computers we soon find ourselves swimming in complex numbers and trig functions.
Fastest langauge for FFT's = C?
That sounds like a whole new coding challenge...
Can FFT's be done in FPGA hardware?
Sure, why not. The neat thing about a lot of FPGA is that they have a whole bunch of multiplier hardware blocks. That means a lot of parallel calculation can be going on.
Only Google can save me?
Judging by your posts Google will be your downfall.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 31, 2019 11:45 pm

Heater wrote:
Thu Jan 31, 2019 8:11 am
I presume that when adopting neural nets, deep learning, etc one gets all the prejudices and unpredictable behavior of humans but with some distinct advantages. The thing operates 24/7 without complaint. It probably works faster. It's probably cheaper, no salaries, no need for comfy working conditions, etc, etc. Sure it has those prejudices and unpredictable behaviors but over all it is a net win.
Unless your neural net / whatever is the brain behind a certain android called Marvin. Imagine what would happen if Google's (or Apple's, Amazon's, Microsoft's etc.) computers got fed up of banal search requests and decided to have fun by making stuff up...
She who travels light — forgot something.

User avatar
davidcoton
Posts: 3770
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK

Re: Why Avoid BASIC on RPi?

Thu Jan 31, 2019 11:52 pm

Paeryn wrote:
Thu Jan 31, 2019 11:45 pm
Imagine what would happen if Google's (or Apple's, Amazon's, Microsoft's etc.) computers got fed up of banal search requests and decided to have fun by making stuff up...
They don't have to. There's enough fiction posing as fact on the www already, Marvin just has to tune his search to put fiction before fact ... sometimes.
Signature retired

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 1:18 am

FPGA filters and Adrian Thompson is a interesting read.
google found me a new review of his work,
https://www-verimag.imag.fr/PEOPLE/Nico ... rault2.pdf
Marvin would be pleased in Adrian's final design there were 5 cells hooked up to nothing.
Sort of like our redundant DNA?

Imagine C code with functions that do nothing but if you take them out the progtam crashes ;)
NOP is redundant computing DNA? I can remember using them for fixing timing issues ;)

Hearing, Speech, Vision, all big number crunching that has only just been mastered enough to be useful.
Convert those code routines to hardware and that robot Ted gets closer.
Anyway, thinking about chopper amps, sigma delta, variable freq generators and accumulators makes a change from Karatsuba and Fibonacci.
If Verilog and VHDL are assembler, higher level is SpinalHDL, Chisel?
More bloody languages to learn :lol:

Hmm can Fibonacci be done in fpga? Logic cells not RISC-V plus code?
Actually FFT etc would be of more use?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 3:29 am

Gavinmc42,
Imagine C code with functions that do nothing but if you take them out the progtam crashes
Funny you should mention that. I just learned of an example where removing an unused C function caused the program to run significantly slower. The conclusion was that removing code was changing the alignment of the instructions that were used and/or upsetting the way it sat in instruction cache memory.

Certainly Fibonacci can be done in FPGA. The schoolboy algorithm would be trivial to implement and generate the Fibonacci sequence at 100 million per second for small values, up to a couple of hundred bits wide perhaps.

gibiansky/fib.v: https://gist.github.com/gibiansky/4247200

Propagating the carry across additions of million digit numbers might get rather slow. At which point a faster algorithm would be required.

At that point it may be as well to use a processor core to manage things but equip it with the means to do fast additions and multiplications in parallel.

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 7:00 am

Heater wrote:
Thu Jan 31, 2019 8:11 am
I would argue there is not much difference between a neural net and something like the Mandlebrot set. Sure you can find out if the net likes cats or dogs by knowing the weights on the connections, you just have to run it with those weights and see what happens. In the same way that you know what color your Mandlebrot set program will use for a pixel, you just have to plug the coordinates in and run it.
The answer in both cases is unknown until the program is run; however, the nature of each program is quite different. For the Mandelbrot calculation one can read the code, determine the exact operations being performed and what the colours mean that are used to draw the picture. The dog detector, on the other hand, is a set of weights that were learned through back propagation and Bayesian inference. This program was not written by humans and there is no code to read.

While the dog-detector weights can be loaded into a compatible neural network and run in much the same way that a Z80 Mandelbrot binary can be executed by the SIMH Altair emulator, there is a notable difference: The Mandlebrot binary can be disassembled if necessary, whereas the dog detector represents a new kind of opaque executable that cannot be disassembled.

It is admittedly possible to create a neural network using BASIC, just as it is possible to create a Z80 simulator. While it may be best to avoid BASIC, it is better to avoid the zombie apocalypse as well as neural-network executables created by deep learning which cannot be audited.

Do you think it might be possible to compute million-digit Fibonacci numbers using a neural network?

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 7:47 am

whereas the dog detector represents a new kind of opaque executable that cannot be disassembled.
Yep not much point if it is not transferable, if every bot has to learn the same things.
How to pass that knowledge on to the next gen of bots or others of the same make?

Not sure is we would be able to audit it anyway.
It is not as if we can audit human brains either, we can only judge them by their actions?

Does anyone knows exactly how AlphaGo wins?
When a "highly inventive" bot can teach us things about Go, the World has changed.

Not too worried about the robot apocalapse yet, brush motors wear out, batteries go flat, they don't heal.
Worry when the Corperations/Banks have robot CEO's, not that the ones they have now are human ;)

What language would bots use to explain themselves to others of their knid and to us?
Our smartphones already communicate by RF and ultrasonic, would we ever know when AI emerges on our phone?
Most people are cyborgs anyway, so attached they cannot function without thier phones.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 8:51 am

ejolson,

You have made a subtle change of argument there. You initial statement was: "it is impossible to tell whether a neural network will prefer cats or dogs by examining the numerical weights on the connections."

I claim this is not true. Given the NN algorithm, the numerical weights and a picture of a dog or cat we have a completely deterministic computation. Input -> Compute -> Output. In principle a human could verify the result by hand with pencil and paper.

Like the depths of the Mandelbrot set this could take some time...but I don't see any difference in nature between Mandelbrot and NN here.

Now you have expanded your case to how those numerical weights are arrived at: "The dog detector, on the other hand, is a set of weights that were learned through back propagation and Bayesian inference. This program was not written by humans and there is no code to read."

I can make a similar counter claim here. Given the back propagation algorithm and the thousands/millions of images used for the "training", calculating those weights, we have a completely deterministic computation. Input -> Compute -> Output. In principle a human could verify the result by hand with pencil and paper.

Like the depths of the Mandelbrot set this could take some time...but I don't see any difference in nature between Mandelbrot and back propagation here.
Do you think it might be possible to compute million-digit Fibonacci numbers using a neural network?
Some would argue that we already did that. Using the neural networks in our heads. Further they argue that whatever mechanism in our heads that does that can, in principle, be implemented in a machine. Therefore, yes.

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 2:12 pm

Gavinmc42 wrote:
Fri Feb 01, 2019 7:47 am
Not sure is we would be able to audit it anyway.
It is not as if we can audit human brains either, we can only judge them by their actions?
Agreed. If there is no code to read or write then there is no code to audit. From a computer literacy point of view, this means there is no need for computer literacy. When programs are created by initialising neutral networks and complicated statistical models using training data, there is further no need for programmers. When neural networks start coding in line-numbered Basic to compute Fibonacci numbers, your and my favourite programming language becomes impossible to avoid.

My opinion is that there is a significant difference between auditing a program to verify that it performs the correct computation versus running the program and verifying that it produces the correct answer. A person can audit code for correctness without knowing the answer. In contrast, if the answer is already known, then running the program serves no useful purpose in the first place.

Suppose the dog detector was created using training data in which all dogs were coincidentally outdoors and all cats indoors. It is possible and similar things have happened, that the resulting neural-network program is not a dog detector at all. On the other hand, a person can read the source code of a Mandelbrot program and notice that it computes Julia sets instead without even knowing what either set actually looks like.

When it comes to checking answers for correctness, it is possible that random state whether intentional or hidden leads to different answers each run. For example, the order of floating-point operations in a parallel program or dynamically-tuned sequential code may change based on timing characteristics related to cache alignment, memory bandwidth contention and latencies in the networking fabric. In ocean modelling the resulting differences in rounding errors could then lead to noticeably different velocity fields at the end of a simulation. The half-precision arithmetic used in deep learning is even more susceptible to these kind of rounding errors. Moreover, the neural network itself may contain intentional stochastic elements with realisations that change from run to run.

If deep learning turns the computer into a programmer, then what should the programmer be turned into?
Last edited by ejolson on Fri Feb 01, 2019 4:46 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 2:59 pm

ejolson,
When neutral networks start coding in line-numbered Basic to compute Fibonacci numbers, your and my favourite programming language becomes impossible to avoid.
Ha! If that were to come to pass I might speculate that the resulting BASIC, whilst unavoidable, would be so huge, complex and weird that no human could fathom how it works. It might rely on theorems in number theory or whatever that we are to stupid/limited to prove for ourselves or even grasp. It might make use of those floating point math anomalies you mention for it's operation.
My opinion is that there is a significant difference between auditing a program to verify that it performs the correct computation versus running the program and verifying that it produces the correct answer.
Yes, OK, I'll go with that.

Presumably those algorithms we use for back propagation and whatever NN training are just code that can be audited to verify that it performs the correct computation without actually running it. In that way, no different from my Mandelbrot Set example or pretty much any code we write. It's just code, right?

Similarly those algorithms we use to to implement the NN are also just code, also amenable to auditing like any other.

I see don't see the difference you draw between such training/NN software and any other software in that respect.
Suppose the dog detector was created using training data in which all dogs were coincidentally outdoors and all cats indoors. It is possible and similar things have actually happened, that the resulting neural-network program is not a dog detector at all.
For sure that happens. Is that not just a case of "garbage in, garbage out"? The thing produces weird results even if all the actual code we created to do all that has been audited for correctness.
When it comes to checking answers for correctness, it is possible that random state whether intentional or hidden leads to different answers each run. For example, the order of floating-point operations in a parallel program or dynamically-tuned sequential code may change based on timing characteristics related to cache alignment, memory bandwidth contention and latencies in the networking fabric
Indeed that is true.

It is true of neural nets and deep learning systems in the same way it is true of weather/climate models or pretty much any non-trivial physics simulation.

All in all I'm not convinced of the difference you make between a simulation of a mental model with NN's and any other complex simulation we do.

At the end of the day nobody cares. For example: If my bank uses AI to evaluate the risk of loaning money to me then that AI may well turn me down for some spurious reason. It might be a bummer for me that I get black listed everywhere and it's pretty appalling that there will not be any real human bank manager to talk it over with, but the bank will not care, as long as the AI false positives/negatives are low enough that they make money and reduce risk of losing money they need not bother themselves with any particular case.

Seems to me we can see this playing out in the use of AI/Deep Learning to detect possible criminal behavior and so on already.

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 5:42 pm

Heater wrote:
Fri Feb 01, 2019 2:59 pm
I see don't see the difference you draw between such training/NN software and any other software in that respect.
Agreed. There is not much difference between the nature of code that implements a neural network versus code that implements a Z80 simulator. Both are written by humans and can be audited by the same. There is a difference, however, in the binaries which are subsequently loaded into these execution environments. The Z80 emulator again runs programs written by humans while the neural network runs programs created using statistical learning techniques. The fact that Z80 code can be audited for correctness without running it while the weights which represent a neural-network program cannot is a huge difference from my point of view.

As convenient as it sounds to do away with programming and instead create all software using deep-learning statistical methods, the greatest evils are often disguised as convenient goods. Before the zombie apocalypse there will be an age of digital feudalism. However, both can be avoided if the driving forces of computer literacy and digital liberation instead lead to a second age of personal computing.

Returning to the off-topic focus of this thread, although Basic may not be as fashionable as Go, Kotlin, Rust or Swift, it remains an easy to learn language that promotes computer literacy. Since the original goals of Kemeny and Kurtz have been realized in modern versions of Basic, why avoid it on the Raspberry Pi?
Last edited by ejolson on Fri Feb 01, 2019 5:44 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 6:44 pm

ejolson,
Agreed. There is not much difference between the code that implements a neural network versus the code that implements a Z80 simulator. Both are written by humans and can be audited by the same.
OK. So far so good.
There is a difference, however, in the binaries which are subsequently loaded into these execution environments. The Z80 emulator again runs programs written by humans while the neural network runs programs created using statistical learning techniques.
Ah, I see, you want to go all "meta" and say that the weights fed into the NN and the Z80 opcodes fed into the Z80 simulator are some how "code" for a machine. After all both of them are just data fed into a program. And programs are just data. OK, fair enough.
The fact that Z80 code can be audited for correctness without running it while the weights which represent a neural-network program cannot is a huge difference from my point of view.
Hmm... this starts to get a bit iffy.

If one only has the binary code to be fed into a simulator, with no specification, then it's not possible to audit it and judge if it is correct or not. If that code makes use of some mathematics that you have no idea about it will be impossible to figure out what it does by auditing it.

How is that different from tying to fathom if the weights fed into an NN are correct or not?

And hey, that Z80 code was probably written by a neural net in the first place. A human one!
As convenient as it sounds to do away with programming and instead create all software using deep-learning statistical methods, the greatest evils are often disguised as convenient goods.
It's not clear to me that we are near to doing away with programming yet.
Before the zombie apocalypse there will be an age of digital feudalism.
I would say the age of digital feudalism has been going on for decades now. Since the rise of MS and all that followed, deepening with the arrival of Google, Facebook and the "cloud" that controls us all in general.
...although Basic may not be as fashionable as Go, Kotlin, Rust or Swift, it remains an easy to learn language that promotes computer literacy.
BASIC certainly did and can still serve that purpose to some extent.
Since the original goals of Kemeny and Kurtz have been realized in modern versions of Basic, why avoid it on the Raspberry Pi?
Because, as the fibo challenge demonstrates, BASIC is not very convenient. Because we have other options now a days that can be as simple as BASIC for beginners and far less restrictive as one advances.

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 10:20 pm

Bots currently need 10,000 images to be trained, the human equivalent of rote learning.
Most people don't need that many to tell the difference between outdoor dog and indoor cat.
Pen and paper auditing is not needed for that, humans can tell if the bot was correct.
If it is wrong then surely that is the fault of the teacher.

But then how would that trained bot tell another untrained bot how it made that decision?
What language could express that trained bot brain?
How does that rote training get better, 10,000 images of everything?

We have so many computer languages because none are perfect for every use case.
Basic is good as a first language ;)

Say we have a Z80 core and fpga combo, the NN/Genetic evolution happens on the FPGA part
The Z80 is used to read the FPGA and transmit the trained configuration out, to us and perhaps another untrained system.

Autonomous vehicle training, how to audit that?
The decision to avoid the danger of hitting a pedestrian at the risk of killing the driver?
A human judgement based on evidence? Does that AI program deserve to live or is it dangerous?
Do we judge these bots by our normal grey area common law or black and white written law?
We actually have so many laws we need an AI to sort them out :lol:

What language would we invent for legal decision making bots, do we train them on all the case law?
That would certainly pick out those Judges and Magistrates who are less "correct and preferable".
Humans at less than the Dunbar number are mostly social animals, we can only judge these bots by our own rules of behavior.

In most Democracies the legal system is stuffed and not affordable and all levels of gov are corrupt or perceived to be.
Even Denmark which rates as the best, admits of gov corruption.
This is a field that is crying out for AI assistance, we already use Dr Google, Judge Google next?
Next step is an AI as our decision makers and leaders?
Currently I see that as a benefit not a harm.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Fri Feb 01, 2019 11:13 pm

Gavinmc42,
Bots currently need 10,000 images to be trained, the human equivalent of rote learning.
Most people don't need that many to tell the difference between outdoor dog and indoor cat.
I think you grossly underestimate the number of images of cats and dogs, indoors and out, you have seen in your lifetime. Or even as a child.
But then how would that trained bot tell another untrained bot how it made that decision?
How would you, as a trained recognizer of dogs and cats, indoors and out, describe how you made your classification to some other human that had never seen a dog or a cat?
We have so many computer languages because none are perfect for every use case.
Yes.

But I have begun to think, having had to work in many languages over the decades most of which are now obsolete, that the reason we have so many languages sprouting all the time is that they all become annoying if you use them long enough. Clever guys get so annoyed that they are moved to create their own language, casting aside all the errors and "cruft" of what they know already. Thus creating a new generation of languages with errors and cruft that will annoy programmers in the future...

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

Re: Why Avoid BASIC on RPi?

Sat Feb 02, 2019 4:42 am

[I think you grossly underestimate the number of images of cats and dogs, indoors and out, you have seen in your lifetime. Or even as a child.

/quote]
Pretty sure I never saw 10,000 dog and cats when I was a kid, human pattern recog is pretty good.
At least for animals that could kill us or be our friends, remember we are the survivors of thousands of generations of people who lived in the wild etc

We don't have to describe in code what what dog or cat looks like, give them unwired neurons and just point, dog, cat, horse, monkey.
They have to learn what pointing is for first. Then the trick is how to make that learned wiring transferable to a new bot.
That could be a big issue, instant memory transfer.

Descriptive language and learned language or let the bot make its own teaching language for the blank slate?
I suspect we are only half way through computer language evolution.
What is the bot equivalent of passing on learning/DNA/Genes etc.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Return to “Off topic discussion”