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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 5:08 am

scruss wrote:
Mon Nov 26, 2018 4:44 am
DavidS wrote:
Mon Nov 26, 2018 2:05 am
What do you consider an effective scripting language? On RISC OS …
Something like Perl or Python: it'll allow me to dig about in deep and messy structures without having to bother me with memory allocation. Maybe store stuff in a SQLite or Spatialite database: take a query and spit it out in the the vector data format of my choice for further transformation in (say) OpenSCAD. The language doesn't have to be super fast or pure: just no limits. F'rinstance, I just realized that the database I looked at for neighbourhood buildings is around 2.6 GB, but Python didn't complain.
Without going to RISC OS I can see how other BASIC implementations would be limiting for you. Now some of that can not be done easily with any more traditional programming language, so for those things your choices are of reason.
RISC OS is such a productivity killer for me: single core, no wifi, broken multitasking, only runs on small hardware, the most unusual GUI ever. I know you're very partial to it, but it's a fast nope for me.
Nothing wrong with that view. Different people do best with different systems. For me something like LXDE, KDE, GNOME, Windows, etc are productivity killers, so I can see how the UI can kill productivity when it is far enough outside what you are accustomed to.

Though I would point out that RISC OS is no longer restrained to single core. Yes SMP is a new beast for RISC OS so there is precious little that takes advantage of it yet, though as with any new feature it will see more and more use.

Yes the GUI is different from many others. For some of us it is easier, there are those that do not like it. Each person has what works for them.
ejolson wrote:
Mon Nov 26, 2018 4:02 am
How hard would it be to rewrite most Unix shell scripts in Basic?
I know that the first bootstrap Unix commands were written in Fortran, 'cos back in the day most computers shipped with a Fortran compiler. HP used to write a lot of their system stuff in Basic dialects. But I'd hate to think of how Basic shell scripts would handle big data with mixed Unicode data.
That depends on the BASIC. For BBC Basic V handling multiple byte character strings is no different from any other language, so you may have to only one time write a couple of conversion/comparison routines to correctly compare between charactor encodings (something that used to be a common need, and is again thanks to Unicode). And there is no limit to the potential size of the data source.
Wouldn't it have been nice if, instead of replacing those confusing System V init scripts by a huge C program, that those systemd programmers would have written a collection of easy to understand startup scripts in Basic.
If you want AppleDOS 3.3, you know where to find it. ☺
MS-BASIC realy, how does MS-8K BASIC with a few extensions qualify in this at all, one of the worse examples of BASIC on small systems ever was MS-8K BASIC. Though it is MS-8K BASIC that tainted the view of many about BASIC, as we all saw MS-BASIC sometimes called AppleSoft, sometimes called CBM BASIC, sometimes called TRS BASIC all of it was MS 8K BASIC.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 5:23 am

ejolson wrote:
Mon Nov 26, 2018 4:02 am
Instead of built-in features a scripting language could also assemble features provided by external programs and subroutines. How hard would it be to rewrite most Unix shell scripts in Basic?

Wouldn't it have been nice if, instead of replacing those confusing System V init scripts by a huge C program, that those systemd programmers would have written a collection of easy to understand startup scripts in Basic.
Now I do not see BASIC as being a good fit with Unix, especially if you look at what BASIC was in the late 1960's early 1970's. Of course there were not many other options either, hence why we ended up with the shell scripts. Though if you look at the shell scripting abilities of a Unix from the mid 1980's and compare it with an up to date BASIC of the mid 1980's, then BASIC would have been a better choice, though Unix was already pretty much set in stone.

And even on systems that do have integrated BASIC that is very powerfull, we still have a seperate native shell scripting language (in the case of RISC OS we call shell scripts Obey files). As a shell script is meant to be good at dealing with file names, environment variables, running things, simple command embeding, and the like. these are things that a full blown programming language is not that good at.

Personally I would never recommend a full blown programming language as a shell scripting language. The question posed is if basic would be good at it, and yes BASIC would be good at it, though BASIC is better as a programming language.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 6:26 am

DavidS wrote:
Mon Nov 26, 2018 5:23 am
ejolson wrote:
Mon Nov 26, 2018 4:02 am
Instead of built-in features a scripting language could also assemble features provided by external programs and subroutines. How hard would it be to rewrite most Unix shell scripts in Basic?

Wouldn't it have been nice if, instead of replacing those confusing System V init scripts by a huge C program, that those systemd programmers would have written a collection of easy to understand startup scripts in Basic.
Now I do not see BASIC as being a good fit with Unix, especially if you look at what BASIC was in the late 1960's early 1970's. Of course there were not many other options either, hence why we ended up with the shell scripts. Though if you look at the shell scripting abilities of a Unix from the mid 1980's and compare it with an up to date BASIC of the mid 1980's, then BASIC would have been a better choice, though Unix was already pretty much set in stone.

And even on systems that do have integrated BASIC that is very powerfull, we still have a seperate native shell scripting language (in the case of RISC OS we call shell scripts Obey files). As a shell script is meant to be good at dealing with file names, environment variables, running things, simple command embeding, and the like. these are things that a full blown programming language is not that good at.

Personally I would never recommend a full blown programming language as a shell scripting language. The question posed is if basic would be good at it, and yes BASIC would be good at it, though BASIC is better as a programming language.
One example of a full-blown programming language used for scripting is the just-in-time compiled Holy C from Terry Davis's Temple OS. According to Wikipedia
HolyC is a variation of C, developed by Davis as the programming language of TempleOS. It is used to interact with the shell, and to write and execute entire applications from the shell.
Similar to many Basic interpreters, you can type Holy C code directly into the terminal and then call the resulting functions directly from the command line.

Another programming language that is sometimes used as a shell is MATLAB. While you can run any excutable from within the environment, it is also possible to write Fortran subroutines that return complex data structures such as matrices and script those subroutines together directly from the MATLAB command line.

Finally, one might note that the ksh93 Korn shell and Microsoft's PowerShell both do floating point arithmetic and contain many of the other features (except JIT compiled efficiency) that one would expect from an interactive general-purpose programming language.

In the end, almost anything would have been better than replacing all those Unix-shell startup scripts with a giant C program.

User avatar
PeterO
Posts: 5456
Joined: Sun Jul 22, 2012 4:14 pm

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 7:55 am

Indeed the 803 has no hardware stack, nor instructions for a software stack.

Subroutines were implemented via "links", which often were the first word of a subroutine. To call a subroutine took two instructions, as shown below for a call to a subroutine at location 1000 from location 500.

Code: Select all

500     73 1000:40 1001
......
1000  +0
Subroutine code here
1010  00  1000/40   1
Function 73 is described as "Write the address of this instruction", and stores the current value of the Sequence Control Register (SCR) (Program Counter in modern terms.) into the specified location. So 500 is written into 1000.
40 1001 Jumps to 1001 (I.e. puts 1001 into the SCR)

00 1000 is a no op on location 1000 (the link). Because the B modifier bit is set (indicated by the "/" between the two instructions), when it comes to fetching the second instruction in the word the contents of location 1000 are added to the instruction before execution. So the instruction "40 1" (which is a jump to location 1) becomes 40 501 which jumps back to the word after the subroutine call.

Note that with this technique you can have multiple return points , so on an error the return could be to the first instruction after the call, and on success the return could be to the second instruction after the call.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 8:46 am

ejolson wrote:
Mon Nov 26, 2018 6:26 am
Another programming language that is sometimes used as a shell is MATLAB. While you can run any excutable from within the environment, it is also possible to write Fortran subroutines that return complex data structures such as matrices and script those subroutines together directly from the MATLAB command line.
Another very powerful language is Rexx for IBM mainframes. This was a capable modern general purpose language, which was also used for anything that might need a scripting language such as a command scripts, editor scripts etc. It was called the "System Product Interpreter".

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 9:37 am

ejolson,
The value of recursion for expressing and reasoning about algorithms was known long before digital computers existed.
Certainly it was. From the world of mathematics and logic.

My claim is that many programmers, to this day, are not mathematicians or even very good at it. Is "recursion" a thing that kids are familiar with after a high school maths education? Recursion is a somewhat esoteric, academic thing. An advanced concept that programmers still have trouble getting their heads around. Our DavidS here stated that we should avoid recursion in this very thread.
As Algol was originally intended to be a theoretical programming language used to describe published algorithms in a way suitable for people to understand, including recursive constructs was mathematically natural.
This is not true. There was nothing "natural" about it. In fact most of the ALGOL 69 committee wanted to specifically ban recursion in the language definition. They considered it a step too far in "advanced programming language semantics".

It has been said that "In several ways the committee was advancing beyond the most advanced existing ideas and beyond their own intellectual grasp."

Turns out recursion was introduced into ALGOL at the last minute and in a very sneaky way that was not spotted by those who objected to it.

You will be interested to read this fascinating article on the history of ALGOL 60 and how recursion was snuck in there: https://vanemden.wordpress.com/2014/06/ ... f-errors-3

Anecdote:

In the mid 1980's I worked in a team building a CAD package for schematic capture and printed circuit board layout. In that massive, for the time, code base they had a recursive algorithm that searched for solutions to some problem or other, I forget. Amazingly I found they had not written it recursively. No, they had basically had the same code in many procedures which called each other in a chain down to about seven levels deep. Then returned up the call chain with the result. The project lead told me they had tried to implement it as a recursive function but never got it to work!

You can still buy that CAD package today: https://www.zuken.com/en/products/pcb-design/cadstar Although it's all been rewritten in C/C++ since then. The original was in PL/M 86.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 9:49 am

PeterO,
Subroutines were implemented via "links", which often were the first word of a subroutine.
This kind of thing still goes on today.

In the Propeller micro-controller from Parallax Inc. when you write the CALL instruction in assembler it sticks the return address into the last instruction in the subroutine, which is your RET instruction.

Thing is the Propeller does not have a CALL and RET instruction. What it has is a "JMPRET" instruction that jumps to some target location whilst saving PC + 1 in some other location. The assembler synthesizes CALL and RET from this.

But JMPRET allows other interesting things, like coroutines, you can have two endless loops that exchange execution time with each other using JMPRET. There is a nice explanation of JMPRET coroutines here: https://lamestation.atlassian.net/wiki/ ... 325/JMPRET
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 1:37 pm

Heater wrote:
Mon Nov 26, 2018 9:37 am
ejolson,
The value of recursion for expressing and reasoning about algorithms was known long before digital computers existed.
Certainly it was. From the world of mathematics and logic.

My claim is that many programmers, to this day, are not mathematicians or even very good at it. Is "recursion" a thing that kids are familiar with after a high school maths education? Recursion is a somewhat esoteric, academic thing. An advanced concept that programmers still have trouble getting their heads around. Our DavidS here stated that we should avoid recursion in this very thread.
Not correct. I stated that using a long Fibonacci sequence calculation in a recursive implementation is a way to show why to avoid abusing the stack.

There is nothing wrong with recursion, and I use it all the time. It is when you get thousands of calls deep into recursion that it becomes a problem, often slowing things a bit, especially if the OS has to grow the stack, or you just run out of stack space.

Whenever we write a file utility that operates on multiple files and supports walking a subdirectory tree we use recursion, because it is the effecient way to do that. When we are walking a parse tree in an interpreter or compiler we often use recursion, because it is an effecient way to do so. And many many more examples, many when dealing with trees, though just as many for other reasons.

I take you missunderstood what I meant earlier in the thread so I am being more explicit this time.
As Algol was originally intended to be a theoretical programming language used to describe published algorithms in a way suitable for people to understand, including recursive constructs was mathematically natural.
This is not true. There was nothing "natural" about it. In fact most of the ALGOL 69 committee wanted to specifically ban recursion in the language definition. They considered it a step too far in "advanced programming language semantics".

It has been said that "In several ways the committee was advancing beyond the most advanced existing ideas and beyond their own intellectual grasp."

Turns out recursion was introduced into ALGOL at the last minute and in a very sneaky way that was not spotted by those who objected to it.
That is interesting, when even a young child can easily understand using recursion. Many of the little toy programs I wrote as a young child used recursion, sometimes to much so, I still have my old childhood notebooks where I hand wrote the programs before testing them, then wrote a version containing any corrections I had to make to get it to work.

While I may have not known the word recursion, it was a concept that was natural for me even as a young child.

I remember when I was about 10 years old, I was set infront of one of the school computers that had a structured BASIC interpreter that did not support recursion, I was asked to write some simple program, so i did and it did not work because I was trying to use recursion. I ended up asking why a procedure could not call itself on that computer when it works on my computers, and the instructor did not have an answer.
You will be interested to read this fascinating article on the history of ALGOL 60 and how recursion was snuck in there: https://vanemden.wordpress.com/2014/06/ ... f-errors-3

Anecdote:

In the mid 1980's I worked in a team building a CAD package for schematic capture and printed circuit board layout. In that massive, for the time, code base they had a recursive algorithm that searched for solutions to some problem or other, I forget. Amazingly I found they had not written it recursively. No, they had basically had the same code in many procedures which called each other in a chain down to about seven levels deep. Then returned up the call chain with the result. The project lead told me they had tried to implement it as a recursive function but never got it to work!

You can still buy that CAD package today: https://www.zuken.com/en/products/pcb-design/cadstar Although it's all been rewritten in C/C++ since then. The original was in PL/M 86.
That is surprising. Cool story.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 1:39 pm

@Heater:
And how is that C code coming?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 5:03 pm

DavidS wrote:
Mon Nov 26, 2018 1:39 pm
@Heater:
And how is that C code coming?
Somewhere I have a simple set of C subroutines that perform big number addition, subtraction, multiplication and division. They were written for one of the Sphere Online contest questions (and also as a learning project). My recollection is that the multiplication was done via the Karatsuba algorithm and that division used Newton's method. Since the asymptotically correct way to multiply big numbers is by means of an FFT, it is likely that GMP is faster both algorithmically and from a machine optimized point of view.

Are you wanting code that generates all the Fibonacci numbers in sequence, or do you want to use squaring to obtain only the final number?

Another way to compare the expressivity of Basic and specifically compiled FreeBasic with C is to translate the non-parallel versions of the prime sieve, merge sort, Fourier transform and Lorenz 96 dynamical simulation from this thread. A pie chart depicting the relative speeds of single-core versions of the benchmark is here. Since the speed of the C code has already been measured for all the different Pi models, comparison with other programming languages should be straight forward.

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 5:57 pm

DavidS,
And how is that C code coming?
It's, shall we say, fermenting. Real work has been in the way today.

I think I will end up with the same problem again. Getting a result is one thing, printing it out in decimal is a pain.

Assuming I can get a result that is...
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 6:21 pm

ejolson wrote: Another way to compare the expressivity of Basic and specifically compiled FreeBasic with C is to translate the non-parallel versions of the prime sieve, merge sort, Fourier transform and Lorenz 96 dynamical simulation from thisthread. A pie chart depicting the relative speeds of single-core versions of the benchmark is here. Since the speed of the C code has already been measured for all the different Pi models, comparison with other programming languages should be straight forward.
Yes it would. Do you have a version in say a zip or spk archive? For some reason the tar I have will not do squat with that file you posted.
Heater wrote:
DavidS wrote: And how is that C code coming?
It's, shall we say, fermenting. Real work has been in the way today.

I think I will end up with the same problem again. Getting a result is one thing, printing it out in decimal is a pain.

Assuming I can get a result that is...
I understand that issue quite well :) .

I wish you luck, and hope to see something working before long. I am still giving thought to the possible solutions without resorting to using a base(n*10) value as an intermediate (which can really make things slow when you get into more than simple addition and subtraction).

And to do the FreeBASIC version I had better download the DOS version of FreeBASIC and get it setup in my DOSBox C: drive, so that I can compile and test. Needless to say the first translation of what you come up with is going to be in compiled BBC BASIC V on RISC OS, as I am on RISC OS for now (as you likely already know from my news post on my OS site this morning).
Last edited by DavidS on Mon Nov 26, 2018 6:24 pm, edited 1 time in total.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 6:24 pm

ejolson,
Are you wanting code that generates all the Fibonacci numbers in sequence,...
The challenge at hand here is calculating fibo(4784969), the first number in the Fibonacci sequence with a million digits in decimal.

We have solutions in Javascript, Python and C already but DavidS wants to see it done without using any non-standard libraries (Not that the JS and Python solutions are using any non-standard libraries)

Sounds like a good challenge to me.

I think we have loosely agreed that presenting the result in hexadecimal is acceptable. After all, converting to decimal output takes far longer than getting the result!
Since the asymptotically correct way to multiply big numbers is by means of an FFT,...
I have been wondering about that.

I forget the idea exactly. Something about treating all the digits in your numbers as samples for an FFT. Taking the FFT of both. Multiplying elements of the results, one for one. Then taking the inverse FFT of that. All sounds like magic to me and I have never tried it.

BUT... If we are dealing with million digits numbers, as we are, doesn't that imply the FFT has to be done using floating point? Kind of feels like cheating and would be pretty shitty on a machine without floating point hardware.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 6:29 pm

@Heater:
I would agree with that hex output is acceptable.
Heater wrote: I have been wondering about that.

I forget the idea exactly. Something about treating all the digits in your numbers as samples for an FFT. Taking the FFT of both. Multiplying elements of the results, one for one. Then taking the inverse FFT of that. All sounds like magic to me and I have never tried it.

BUT... If we are dealing with million digits numbers, as we are, doesn't that imply the FFT has to be done using floating point? Kind of feels like cheating and would be pretty shitty on a machine without floating point hardware.
What machine are we using that does not have floating point HW? Or am I missing something?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 7:22 pm

Well, there is that RISC V core I have running in my FPGA board here.

Mind you, that does not have memory enough for a million digits so I guess I should not worry.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 7:23 pm

DavidS wrote:
Mon Nov 26, 2018 6:21 pm
Yes it would. Do you have a version in say a zip or spk archive? For some reason the tar I have will not do squat with that file you posted.
Likely the problem is that the tar file I posted was compressed with gzip. On Linux GNU tar can handle the file directly as

$ tar zxf pichart-current.tgz

on other systems you may need a pipeline such as

$ gunzip <pichart-current.tgz | tar xf -

If you continue to have trouble, let me know and I can put up a zip archive as well.

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 7:35 pm

Heater wrote:
Mon Nov 26, 2018 7:22 pm
Well, there is that RISC V core I have running in my FPGA board here.

Mind you, that does not have memory enough for a million digits so I guess I should not worry.
Or add memory and then perform the FFT over a finite field instead of the complex numbers.

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 7:52 pm

ejolson wrote:
Mon Nov 26, 2018 7:23 pm
DavidS wrote:
Mon Nov 26, 2018 6:21 pm
Yes it would. Do you have a version in say a zip or spk archive? For some reason the tar I have will not do squat with that file you posted.
Likely the problem is that the tar file I posted was compressed with gzip. On Linux GNU tar can handle the file directly as

$ tar zxf pichart-current.tgz

on other systems you may need a pipeline such as

$ gunzip <pichart-current.tgz | tar xf -

If you continue to have trouble, let me know and I can put up a zip archive as well.
Same trouble if I do tar xvf or if I attempt to ungzip it with gzip first.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 7:56 pm

ejolson wrote:
Mon Nov 26, 2018 7:23 pm
DavidS wrote:
Mon Nov 26, 2018 6:21 pm
Yes it would. Do you have a version in say a zip or spk archive? For some reason the tar I have will not do squat with that file you posted.
Likely the problem is that the tar file I posted was compressed with gzip. On Linux GNU tar can handle the file directly as

$ tar zxf pichart-current.tgz

on other systems you may need a pipeline such as

$ gunzip <pichart-current.tgz | tar xf -

If you continue to have trouble, let me know and I can put up a zip archive as well.
Never mind, face palm. I was attempting to send the gunzip command the wrong options.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 7:59 pm

ejolson,
Or add memory and then perform the FFT over a finite field instead of the complex numbers.
Great idea.

"Let GF(p"), or F for short, denote the Galois Field (Finite Field) of p" elements, where p is a prime and n a positive integer. Let d be a divisor of p" — 1 (possibly d = p" — 1), and r be a member of F of order d in the multiplicative group, F* say, of the nonzero elements of F (which certainly exists, since this group is cyclic of order p" — 1, [1, p. 125]). Then..."

Hmm... I suspect me and this paper are not going to get on well together.

You know, it was about 30 years between my seeing my first Fast Fourier Transform source code (In BASIC as it happens) and wondering WTF? and finally understanding what is going on in the FFT well enough to write my own from scratch. https://github.com/ZiCog/fftbench
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 8:12 pm

heater wrote:You know, it was about 30 years between my seeing my first Fast Fourier Transform source code (In BASIC as it happens) and wondering WTF? and finally understanding what is going on in the FFT well enough to write my own from scratch. https://github.com/ZiCog/fftbench
Interesting. You did a very good job of describing FFT on the Parallax forums about 10 years ago (give or take), I remember that well (though can not seem to find that old thread).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 8:18 pm

@ejolson:
I was almost able to get the pichart-serial to build as is, which is further than I expected to get :) . Though now to give a decent look through what is wrong.

The report from make and gcc thus far is:

Code: Select all

*make
gcc -std=gnu99 -O3 -ffast-math -Wall -lm -lrt -o pichart-serial pichart.c util.c sieve.c merge.c fourier.c lorenz.c
util.c: In function 'tic':
util.c:5:19: error: 'CLOCK_MONOTONIC_RAW' undeclared (first use in this function)
util.c:5:19: note: each undeclared identifier is reported only once for each function it appears in
util.c: In function 'toc':
util.c:9:19: error: 'CLOCK_MONOTONIC_RAW' undeclared (first use in this function)
Makefile:24: recipe for target 'pichart-serial' failed
make: *** [pichart-serial] Error 1
*

RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 8:22 pm

Oh boy, that is going back.

I think the breakthrough came when I realized how/why that bit reversal thing they do in the FFT works. When I saw that in source code for the fist time it was as serious WTF case. Even if I could tell you what the Fourier Transform was about and how to calculate one the slow way, that made no sense at all.

I just realized, in my FFT bench repo there are versions in Spin, C, BASIC, Go, whatever, but my PASM version is missing...
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 8:56 pm

Heater wrote:
Mon Nov 26, 2018 8:22 pm
Oh boy, that is going back.

I think the breakthrough came when I realized how/why that bit reversal thing they do in the FFT works. When I saw that in source code for the fist time it was as serious WTF case. Even if I could tell you what the Fourier Transform was about and how to calculate one the slow way, that made no sense at all.

I just realized, in my FFT bench repo there are versions in Spin, C, BASIC, Go, whatever, but my PASM version is missing...
I thought you put a copy of the PASM version in the OBEX, have you looked there.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 9:01 pm

DavidS wrote:
Mon Nov 26, 2018 8:18 pm
'CLOCK_MONOTONIC_RAW' undeclared
is in <time.h>

Return to “Off topic discussion”