I.... say, dfourier.seq from the above link... is the library useable by itself or do I have to modify Forth to accept it?
The implementation of forth on the prop is tailored to the prop, and some things are just different from ANSI and won't compile directly without modification. Which is a good thing, ANSI forth is design to be a general guideline, it certainly is not intended to be implemented to its fullest extent on every processor.
Fourier on prop is cool, but I'm not smart enough to figure it out, even after heaters great efforts.
Instead, I will cheat, and do the Fourier on the workstation, and use the prop to read the sensors and move the actuators. Right tool for the right job.
With 32 channels and a raspberry pi, it might even work!
No. I did not say FFT could never be done in Forth. And to be clear I was not even fishing for a code size or execution speed comparison. I simply wanted to see how it would look as an example of a moderately complex self contained algorithm. Any way I am studying one example now.
Peter,
I have ARM chips and DSPs that I am happy to compute an FFT on, but the Propeller is not a chip I would ever use for this purpose. There are faster, cheaper, and easier alternatives for this.
Indeed. But speed is relative and if it's fast enough to do what you want then why not?
So the gauntlet has been thrown. If Forth is really as efficient and easy to program as the proponents say they should be able to write an FFT in a few minutes.
Good challenge.
If you work from the algorithm as presented in fft_bench somewhere here on the Prop forum then we have a nice code size and speed comparison with Spin and various C implementations.
fft_bench is a basic vanila fft about as simple as they come. Had to be else I would not understand it:)
I'm sorry but a name like that and Forth programming together reminds me of those days I spent with the Nascom, listening to "the hitchhiker's guide to the galaxy" on Radio 4.
Good challenge.
If you work from the algorithm as presented in fft_bench somewhere here on the Prop forum then we have a nice code size and speed comparison with Spin and various C implementations.
fft_bench is a basic vanila fft about as simple as they come. Had to be else I would not understand it:)
Carl Jacobs posted a JDForth based version of fft_bench in the forum fft_bench thread. He quoted 1200ms for the pure forth FFT and 202ms for a version with the innermost butterfly written as a PASM based word, with a total size (code+data) of 13620 bytes. He acknowledged that the program was a straight port of the fft_bench code, and that it should be possible to do a better more forth oriented version. I suspect there are faster forth interpreters available now too.
For comparison, the Spin version is quoted in the thread at 1465ms and is 3228 bytes big, and the C version compiled with propgcc -O2 clocks in at 47 ms and 17688 bytes of code+data. Most of that is run time library, which I suspect is true for the JDForth code as well.
As far as I can tell, the fft algorithms presented need array support and to my knowledge, neither PropForth or Tachyon have this. I'll defer to one of my Forth elders in this challenge as I have never written or had the need to write (or use) an fft algorithm in my 36 or /so years of computer work and play. I seriously anyone could write an FFT in any non-mathematic language in a few minutes, especially if they have never really worked with FFT's before.
If Forth is really as efficient and easy to program as the proponents say they should be able to write an FFT in a few minutes.
This seems to be a rather dubious requirement to decide "efficient and easy to program" properties of a language. Perhaps it should read: "If C is an efficient language to stay close to the hardware and write system code in, then you should be able to manipulate the I/O pins from the command line."
This seems to be a rather dubious requirement to decide "efficient and easy to program" properties of a language. Perhaps it should read: "If C is an efficient language to stay close to the hardware and write system code in, then you should be able to manipulate the I/O pins from the command line."
I have done this many times using C code. It's called the software tool approach. You just write a tool that does what you want, and run it from the command line. This is basically how most of the "commands" in Linux work.
Very sorry, I misread your comment earlier in the evening and responded later:)
But just to restore the forum's gestalt a little... isn't an FFT just a bit of a red herring:)
I have used the Prop to do number crunching as a way of playing with math. I really like integer math and see no reason for floating points!!!
If I had an ongoing need for serious number crunching, I'd probably go elsewhere.
So, the fact that Forth might or might not less efficient even for some some kinds of math problems isn't really the point... is it a good heuristic for some kinds of minds?
Does Forth have a loyal following... do those guys buy Propellers... if not, why not?
.... need array support and to my knowledge, neither PropForth or Tachyon have this....
There isn't a default control word that provides array support, but I do arrays all the time. Its just address (variable name) plus offset (in characters, bytes, or words, as needed). Thats why its so fast, even in high level forth. If the micro supports auto indexing etc, it optimizes faster and smaller. But, you still have to understand what your trying to do, which is why I never did any FFT.
Hi altogether,
well I have to out myself, that I do use a scientific calculater and that I do not use my slide-rule anymore. I am using Excel with floating-point support. It is very nice, that these tools do the scaling of integers for me which is called floating point math. A floating point number is nothing else as an integer plus a scaling factor. And -sorry-, that Spin (and PropBasic) does not support floating point is a weakness not a strength. It is simply convenient and fast while coding to use floats. Of course, when you need speed, you will have to use integer math. And as always you should be aware of riscs. But speed seems not to have been the main target of SPIN anyways....
The funny point is, that you can directly integrate everything into Forth, for example floating point. You could even redefine "*", so that it will now do floating-point multiply from this moment on. I think, that this power given to the user gives a lot of satisfaction and makes a good deal of the fascination of the language. The other elements are, that it is so small, that you can understand it (and that a complete system can fit into the Prop) and that it can be fast. - I think for big projects with many programmers, the bad readability of the source code is a main stopper.
for big projects with many programmers, the bad readability of the source code is a main stopper.
You are correct, this is the main issue with all big projects with many programmers. Forth is nice because its a little easier to read, it reads like words in a sentence if you do it right. Of course if you do it wrong, its worse, just like any other language. Its just an question of what you wish to deal with. If you want simple, fast, and easy, you chose based on personal preference.
Hey, with the right font, that might actually be productive.
So far, the hard part to me appears to be we are very used to having established definitions of most things, combining them in the ways needed lego style, and most everything is function argument.
Forth includes next to nothing, has few established definitions and is argument function(word). Things do get built lego style, but one must first describe the bricks they want to use. Lay down the right bricks, and the resulting code is a sentence that reads well, and of course it does, because you built the words!
You were asking about where to turn for guidance. I assumed you had read the included materials, but now I realize you are busy, and possibly didn't get to start yet.
I neglected to ask - Did you look at Propforth.htm in the propforth download archive?
PropForth.HTM has the most complete, concise, end to end presentation on a forth implementation I have ever gotten my hands on, and it is specific to propforth. It is written by the architect himself and translated into regular person speak by yours truly.
It includes executable example code for every function discussed, and includes example use of the software logic analyzer and of the MCS communications for multiprop use.
Every function that is not explicitly covered in propforth.htm IS covering in the TUTORIALS directory, as these tutorials are actually examples of each function being executed correctly, as these are the regression tests that get executed by the automation. We are very sure that everything that propforth is capable of doing is done at least once in the course of the automation, so there is at least an example of each function being used correctly at least once.
The idea was that the requirements, tests, code, and documentation included should be the minimum necessary and sufficient to use the package.
If we did it right, anybody should be able to use the package to anything the prop can do. Of course if we fell short, well, there's the other references mentioned. But please let me know what works for you and what doesn't, and I'll take measures to get it fixed.
Assuming you're German (or Yoda), or schooled in one of the Semitic languages that read right-to-left.
Clearly, you have experience with the "not so good" samples of the language. That could well account for your skepticism. That's unfortunate. Some folks think they are clever and cute by making the code as impossible to read as they are able. I've always dislike clever and cute in engineering for that reason.
Comments
The implementation of forth on the prop is tailored to the prop, and some things are just different from ANSI and won't compile directly without modification. Which is a good thing, ANSI forth is design to be a general guideline, it certainly is not intended to be implemented to its fullest extent on every processor.
Fourier on prop is cool, but I'm not smart enough to figure it out, even after heaters great efforts.
Instead, I will cheat, and do the Fourier on the workstation, and use the prop to read the sensors and move the actuators. Right tool for the right job.
With 32 channels and a raspberry pi, it might even work!
No. I did not say FFT could never be done in Forth. And to be clear I was not even fishing for a code size or execution speed comparison. I simply wanted to see how it would look as an example of a moderately complex self contained algorithm. Any way I am studying one example now.
Peter,
Indeed. But speed is relative and if it's fast enough to do what you want then why not?
Jay Kickliter had success using FFT on Propeller in his energy meter project
http://forums.parallax.com/showthread.php?130549-New-Propeller-based-open-source-energy-meter
HemPeter had success using FFT on Propeller in his audio signal processing project
http://forums.parallax.com/showthread.php?140777-Audio-Signal-Processing-on-the-Propeller-Demo-Board
Be sure to check his youtube video, it's cool.
http://www.youtube.com/watch?v=E6JCXD6bbuc&hd=1
But you have to ask Nick about the details, its all beyond me.
If you work from the algorithm as presented in fft_bench somewhere here on the Prop forum then we have a nice code size and speed comparison with Spin and various C implementations.
fft_bench is a basic vanila fft about as simple as they come. Had to be else I would not understand it:)
I'm sorry but a name like that and Forth programming together reminds me of those days I spent with the Nascom, listening to "the hitchhiker's guide to the galaxy" on Radio 4.
Happy, simplistic, days ...
Carl Jacobs posted a JDForth based version of fft_bench in the forum fft_bench thread. He quoted 1200ms for the pure forth FFT and 202ms for a version with the innermost butterfly written as a PASM based word, with a total size (code+data) of 13620 bytes. He acknowledged that the program was a straight port of the fft_bench code, and that it should be possible to do a better more forth oriented version. I suspect there are faster forth interpreters available now too.
For comparison, the Spin version is quoted in the thread at 1465ms and is 3228 bytes big, and the C version compiled with propgcc -O2 clocks in at 47 ms and 17688 bytes of code+data. Most of that is run time library, which I suspect is true for the JDForth code as well.
This seems to be a rather dubious requirement to decide "efficient and easy to program" properties of a language. Perhaps it should read: "If C is an efficient language to stay close to the hardware and write system code in, then you should be able to manipulate the I/O pins from the command line."
A computer is a calculator. It only does math and moves data around. The trick is how math is applied to real world applications.
Very sorry, I misread your comment earlier in the evening and responded later:)
But just to restore the forum's gestalt a little... isn't an FFT just a bit of a red herring:)
I have used the Prop to do number crunching as a way of playing with math. I really like integer math and see no reason for floating points!!!
If I had an ongoing need for serious number crunching, I'd probably go elsewhere.
So, the fact that Forth might or might not less efficient even for some some kinds of math problems isn't really the point... is it a good heuristic for some kinds of minds?
Does Forth have a loyal following... do those guys buy Propellers... if not, why not?
et. al....
I love the conversation. You guys are the best.
Rich
There isn't a default control word that provides array support, but I do arrays all the time. Its just address (variable name) plus offset (in characters, bytes, or words, as needed). Thats why its so fast, even in high level forth. If the micro supports auto indexing etc, it optimizes faster and smaller. But, you still have to understand what your trying to do, which is why I never did any FFT.
well I have to out myself, that I do use a scientific calculater and that I do not use my slide-rule anymore. I am using Excel with floating-point support. It is very nice, that these tools do the scaling of integers for me which is called floating point math. A floating point number is nothing else as an integer plus a scaling factor. And -sorry-, that Spin (and PropBasic) does not support floating point is a weakness not a strength. It is simply convenient and fast while coding to use floats. Of course, when you need speed, you will have to use integer math. And as always you should be aware of riscs. But speed seems not to have been the main target of SPIN anyways....
The funny point is, that you can directly integrate everything into Forth, for example floating point. You could even redefine "*", so that it will now do floating-point multiply from this moment on. I think, that this power given to the user gives a lot of satisfaction and makes a good deal of the fascination of the language. The other elements are, that it is so small, that you can understand it (and that a complete system can fit into the Prop) and that it can be fast. - I think for big projects with many programmers, the bad readability of the source code is a main stopper.
Christof
You are correct, this is the main issue with all big projects with many programmers. Forth is nice because its a little easier to read, it reads like words in a sentence if you do it right. Of course if you do it wrong, its worse, just like any other language. Its just an question of what you wish to deal with. If you want simple, fast, and easy, you chose based on personal preference.
Boy, I'm still trying to get to that point!
I find it helps to read Forth source in a mirror:)
So far, the hard part to me appears to be we are very used to having established definitions of most things, combining them in the ways needed lego style, and most everything is function argument.
Forth includes next to nothing, has few established definitions and is argument function(word). Things do get built lego style, but one must first describe the bricks they want to use. Lay down the right bricks, and the resulting code is a sentence that reads well, and of course it does, because you built the words!
-Phil
You were asking about where to turn for guidance. I assumed you had read the included materials, but now I realize you are busy, and possibly didn't get to start yet.
I neglected to ask - Did you look at Propforth.htm in the propforth download archive?
PropForth.HTM has the most complete, concise, end to end presentation on a forth implementation I have ever gotten my hands on, and it is specific to propforth. It is written by the architect himself and translated into regular person speak by yours truly.
It includes executable example code for every function discussed, and includes example use of the software logic analyzer and of the MCS communications for multiprop use.
Every function that is not explicitly covered in propforth.htm IS covering in the TUTORIALS directory, as these tutorials are actually examples of each function being executed correctly, as these are the regression tests that get executed by the automation. We are very sure that everything that propforth is capable of doing is done at least once in the course of the automation, so there is at least an example of each function being used correctly at least once.
The idea was that the requirements, tests, code, and documentation included should be the minimum necessary and sufficient to use the package.
If we did it right, anybody should be able to use the package to anything the prop can do. Of course if we fell short, well, there's the other references mentioned. But please let me know what works for you and what doesn't, and I'll take measures to get it fixed.
Clearly, you have experience with the "not so good" samples of the language. That could well account for your skepticism. That's unfortunate. Some folks think they are clever and cute by making the code as impossible to read as they are able. I've always dislike clever and cute in engineering for that reason.
Not yet; I have been busy. I did manage to get Tachyon running on a DEFCON badge yesterday so I've made progress.