Starting out on Forth
Rob Spykerman
have just realised there is actually very little material out there
for the uninitiated. I have to say what little I have found has been
pretty good - and am currently thumbing thru' Leo Brodie's Starting
Forth.
I am not sure however if I am doing it mm... right?
ie if the idioms I am using are efficient. It looks to me with all the
stack manipulations, one could write really inefficient code and not
have the compiler to help compensate for it.
For example... To define a word for factorials...
: _factorial 1 swap 0 do i 1+ * loop ;
obviously if a 0 was passed to it, it would hang, so I am left with:
: _factorial 1 swap 0 do i 1+ * loop ;
: factorial ?dup if _factorial else 1 then ;
Now I've littered the namespace with 2 words to accomplish one task.
Of which none look like they can be re-used for anything else.
This is one thing that I find a little frustrating with forth. Can
anyone explain a way round littering the dictionary with all these
tiny factored words? Or is this in fact a good thing?
In the meantime I've come up with a slightly better solution:
: ?n:1 ?dup if else 1 then ;
: factorial ?n:1 1 swap 1+ 1 do i * loop ;
Now at least in this ?n:1 can be used anywhere else I need to replace
all 0's passed as 1's.
Thing is the word factorial can also be defined pretty similarly by
: factorial 1 swap ?n:1 1+ 1 do i * loop ;
This generates less efficient code on the compiler I am using for
reasons I suspect are implementation dependent.
So I don't really know if I am approaching things the right way or if
my idioms are efficient - for such a trivial problem. If some one
could enlighten me I would be very grateful - for I guess it's better
to build the foundation right from day 0 rather than pick up bad
habits that are hard to break later.
Incidentally MPE ltd were very kind to let me test-drive their
evaluation version of VFX Forth Windows. I have to say I am totally
gobsmacked. I did not know forth compilers could optimize like that.
Federico de Ceballos
> I have just begun learning forth [...]
Welcome on board!
> For example... To define a word for factorials...
>
> : _factorial 1 swap 0 do i 1+ * loop ;
>
> obviously if a 0 was passed to it, it would hang, so I am left with:
>
> : _factorial 1 swap 0 do i 1+ * loop ;
> : factorial ?dup if _factorial else 1 then ;
>
> Now I've littered the namespace with 2 words to accomplish one task.
> Of which none look like they can be re-used for anything else.
Perhaps you were thinking about:
: factorial ( u1 - u2 ) 1 swap 0 ?do i 1+ * loop ;
which also works for 0. (Don't forget your stack comments.)
If you are troubled by negative numbers you can try:
: factorial ( n - u ) 0 max 1 swap 0 ?do i 1+ * loop ;
or better still:
: factorial ( n - u ) dup 0< throw 1 swap 0 ?do i 1+ * loop ;
These words can be factored. For example:
: (fact) ( u1 - u2 ) 1 swap 0 ?do i 1+ * loop ;
: factorial ( n - u ) dup 0< throw (fact) ;
(fact) can be reused when you have to calculate the factorial of a lot
of numbers and you are sure that none is negative.
I hope this helps.
Regards,
Federico de Ceballos
dhof...@talkamerica.net
Rob Spykerman wrote:
> Now I've littered the namespace with 2 words to accomplish one task.
> Of which none look like they can be re-used for anything else.
>
> This is one thing that I find a little frustrating with forth. Can
> anyone explain a way round littering the dictionary with all these
> tiny factored words? Or is this in fact a good thing?
Don't get hung up on the idea that everything you write must be
re-useable in some other program. Write your word(s) to solve the
problem at hand. If you solve the problem with readable code, then
feel good about that.
If you happen to write some words that can be used later in some other
task, that's icing on the cake. I think with practice you will begin
to recognize when a word is written, or can be written, that you will
use again. Practice!
> So I don't really know if I am approaching things the right way or if
> my idioms are efficient - for such a trivial problem. If some one
> could enlighten me I would be very grateful - for I guess it's better
> to build the foundation right from day 0 rather than pick up bad
> habits that are hard to break later.
You are asking the right questions. With that attitude you will likely
find that you will enjoy programming in Forth more and more, as you
become more familiar with it.
Regards,
-Doug
Rob Spykerman
> These words can be factored. For example:
>
> : (fact) ( u1 - u2 ) 1 swap 0 ?do i 1+ * loop ;
> : factorial ( n - u ) dup 0< throw (fact) ;
>
> (fact) can be reused when you have to calculate the factorial of a lot
> of numbers and you are sure that none is negative.
>
> I hope this helps.
Thank you! I did not know about ?do *sheepish grin*
Well, that's a couple more words I've learnt today, ?do and throw
One thing absolutely FANTASTIC about forth i am discovering is the
ease of transistion in and out of assembly. For example the above
translates to:
see (fact)
(FACT)
( 0049D6B0 68EAD64900 ) PUSH 0049D6EA
( 0049D6B5 8BC3 ) MOV EAX, EBX
( 0049D6B7 3500000080 ) XOR EAX, 80000000
( 0049D6BC F7D8 ) NEG EAX
( 0049D6BE 50 ) PUSH EAX
( 0049D6BF 6A00 ) PUSH 00
( 0049D6C1 BB01000000 ) MOV EBX, 00000001
( 0049D6C6 817C240400000080 ) CMP [ESP+04], 80000000
( 0049D6CE 7505 ) JNZ/NE 0049D6D5
( 0049D6D0 8D642408 ) LEA ESP, [ESP+08]
( 0049D6D4 C3 ) NEXT,
( 0049D6D5 8B1424 ) MOV EDX, [ESP]
( 0049D6D8 42 ) INC EDX
( 0049D6D9 0FAFD3 ) IMUL EDX, EBX
( 0049D6DC 8BDA ) MOV EBX, EDX
( 0049D6DE FF0424 ) INC [ESP]
( 0049D6E1 FF442404 ) INC [ESP+04]
( 0049D6E5 71EE ) JNO 0049D6D5
( 0049D6E7 83C40C ) ADD ESP, 0C
( 0049D6EA C3 ) NEXT,
( 59 bytes, 20 instructions )
ok
I guess I could cheat, if I were only doing a signed int factorial
function, sorry WORD - still trying to kill old habits :) I've taken
out the increment in the loop to tighten it and just made it count
down and multiply.
code factorial
xor ecx, ecx
or ecx, ebx
dec ecx
jnle l$1
mov ebx, # 1
ret / this stuff gets rid of negatives, 0 and 1
l$1: imul ebx, ecx / this is the main loop ebx returns TOS
dec ecx
jne l$1
ret
end-code
just had a thought... cmov would be nice to have but the evaluation
edition of VFX Forth I have does not do P6 opcodes AFAIK (Steve?) ,
and I've yet to figure the assembler syntax fully so I can insert my
own hex code as a temporary stop-gap for the unimplemented opcodes
(till I figure out how to extend the assembler)
Couple of questions...
1. You put (fact) in () - is this some sort of convention?
2. I can see the virtue of factoring things to small bits but what
about the (at least to my perception) negative effect of littering the
global namespace or dictionary with all these little code fragments?
What can one do?
3. There is OBVIOUSLY a heckuva lot I don't know yet about forth. Can
someone point me to a good reference - particularly idioms, what to do
about namespaces/dictionaries, conventions etc...
Starting Forth does not go into this too much, just seems to describe
the basics of forth very well and the indirectly threaded forth model.
Cheers
Rob
robert.sp...@gmail.com
> code factorial
> xor ecx, ecx
> or ecx, ebx
> dec ecx
> jnle l$1
> mov ebx, # 1
> ret / this stuff gets rid of negatives, 0 and
1
> l$1: imul ebx, ecx / this is the main loop ebx returns TOS
> dec ecx
> jne l$1
> ret
> end-code
sorry, duh! This is better
code factorial
mov ecx, ebx
dec ecx
jnle l$1
mov ebx, # 1
ret
l$1: imul ebx, ecx
Elizabeth D. Rather
news:89589046.05011...@posting.google.com...
...
> Couple of questions...
>
> 1. You put (fact) in () - is this some sort of convention?
Yes, it's long been common to name a word that exists primarily to contain
the active part of some other word that maybe needs a shell (for security or
whatever) around it with the "visible" word's name in parens.
> 2. I can see the virtue of factoring things to small bits but what
> about the (at least to my perception) negative effect of littering the
> global namespace or dictionary with all these little code fragments?
> What can one do?
What negative effect did you have in mind? Most modern systems have
extremely fast searches (typically dividing the namespace invisibly somehow
to help) and lots of memory, and Forth is designed to make the time required
for a call to be absolutely minimal. And there are ways of subdividing the
namespace to help you (e.g. if you need a word like READ to do different
things in different contexts), but that's probably a little advanced for you
right now.
> 3. There is OBVIOUSLY a heckuva lot I don't know yet about forth. Can
> someone point me to a good reference - particularly idioms, what to do
> about namespaces/dictionaries, conventions etc...
>
> Starting Forth does not go into this too much, just seems to describe
> the basics of forth very well and the indirectly threaded forth model.
Well, the indirectly threaded model is not all that common an implementation
strategy nowadays, so don't assume that's in any way intrinsic to Forth.
There are several books on our web site, www.forth.com. One of them, "Forth
Application Techniques", is designed for beginners, and has a lot of
exercises. It is a lot more up-to-date with respect to contemporary Forth
practice than Starting Forth. It even includes a section on naming
conventions that includes the use of parens.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Thomas Pornin
> 2. I can see the virtue of factoring things to small bits but what
> about the (at least to my perception) negative effect of littering the
> global namespace or dictionary with all these little code fragments?
> What can one do?
The usual answer is that such littering is not a problem: if two words
are named the same, then they should do the same and as such be one. If
they do not do the same thing, then one of them is badly named. Besides,
most of the time, Forth refers to data implicitely, by its position
on the stack, whereas other languages have to give names (to local
variables, function parameters and so on). This gives Forth much more
"breathing room" for the word names. Moreover, Forth word names are not
limited to the letters, digits and underscore character; you can be very
creative in the way you name words, which gives you even more room. Last
but not least, Forth names can be redefined without changing the meaning
of words which were defined with the old definition; and you can easily
update your Forth so that redefinitions trigger warnings.
Such is the theory. As usual, practice may disagree. Forth also includes
some features to work with sub-dictionaries. ANS Forth defines the
"wordlist" concept which can be used to provide local namespaces. This
is also known as "vocabulary". Whether this is a good idea or not is
subject to (much heated) debate. The point of Forth is that it does
not choose for you: it gives you ways to do with or without local
namespaces, as you wish.
--Thomas Pornin
robert.sp...@gmail.com
Elizabeth D. Rather wrote:
> "Rob Spykerman" <robert.sp...@gmail.com> wrote in message
[snip]
> > 2. I can see the virtue of factoring things to small bits but what
> > about the (at least to my perception) negative effect of littering
the
> > global namespace or dictionary with all these little code
fragments?
>
> What negative effect did you have in mind? Most modern systems have
> extremely fast searches (typically dividing the namespace invisibly
somehow
> to help) and lots of memory, and Forth is designed to make the time
required
> for a call to be absolutely minimal. And there are ways of
subdividing the
> namespace to help you (e.g. if you need a word like READ to do
different
> things in different contexts), but that's probably a little advanced
for you
> right now.
The thing I feel may be a problem is trying to think of names for
words, once the 'good ones' have been used up...
At present I am trying to learn to minimize the use of traditional
'variables' by doing everything as much as possible on the stack so I
don't have to name 'variables' - haven't had to use 'locals' yet - in
fact I don't know how to do this yet which may well be a good thing.
How do I learn about the more advance stuff? Like keeping errr... name
space pollution to a minimum (okay, I guess I am a bit hung up about
this now, but that's probably cos I know no better?)
There's probably no better way to learn a language than starting to try
and write something useful.
I was thinking when I've learnt enough I might write an mp3 encoder or
adapt a DeCSS to forth. Thing is I've seen the output of optimizing c
compilers and I reckon it will be a bit of a challenge to see if one
can do better...
> Well, the indirectly threaded model is not all that common an
implementation
> strategy nowadays, so don't assume that's in any way intrinsic to
Forth.
> There are several books on our web site, www.forth.com. One of them,
"Forth
> Application Techniques", is designed for beginners, and has a lot of
> exercises. It is a lot more up-to-date with respect to contemporary
Forth
> practice than Starting Forth. It even includes a section on naming
> conventions that includes the use of parens.
Heh, is that a coincidence or what, your book's in the mail to me from
Amazon :) I'm sort of hoping it'll answer all those queries and set me
down the right path. Can I post questions here ;-)
Cheers
Rob
Stephen Pelc
>How do I learn about the more advance stuff? Like keeping errr... name
>space pollution to a minimum (okay, I guess I am a bit hung up about
>this now, but that's probably cos I know no better?)
The traditional thing to do is to hide implementation factors
inside vocabularies to provide namespace control.
vocabulary factors
also factors definitions \ new words are in FACTORS
: foo ... ;
: bar ... ;
also forth definitions \ new words are in FORTH
\ FACTORS are visible
: inForth ... foo ... bar ... ;
previous previous definitions
\ FACTORS are invisible
VFX Forth has its own MODULE mechanism as well, but the
ALSO DEFINITIONS PREVIOUS wordset is in widespread use. You
can also use the ANS wordset mechanism.
Stephen
--
Stephen Pelc, steph...@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Anton Ertl
>2. I can see the virtue of factoring things to small bits but what
>about the (at least to my perception) negative effect of littering the
>global namespace or dictionary with all these little code fragments?
What about it. It's a much smaller problem in Forth than in most
other languages, because Forth allows redefining names, but uses
static binding of names.
So even if you defined a name before, and used it in some other words,
when you define another word with the same name, the Forth system will
not give you an error (but usually a warning), and the already-defined
words will not be affected by your redefinition.
However, it is still a good idea to make word names unique, in order
to allow direct access to all the words during debugging.
As others have mentioned, you can also use wordlists to get the effect
of namespaces or modules, but that approach often gets in the way of
debugging convenience, so I use it much less often than I would in
some other programming languages.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.complang.tuwien.ac.at/forth/ansforth/forth200x.html
Elizabeth D. Rather
news:1105438620....@f14g2000cwb.googlegroups.com...
>
> ...
> The thing I feel may be a problem is trying to think of names for
> words, once the 'good ones' have been used up...
Forth enlarges its potential namespace considerably by allowing characters
other than letters, digits, and underscore. Well-chosen names are important
in writing readable code, though. I prefer simple English words (avoiding
long, concatenated "phrases"). There are some hints for naming in my book.
As others have mentioned, the concept of wordlists or vocabularies (two
terms for the same thing) can help in complex applications, but don't worry
about this for now.
> At present I am trying to learn to minimize the use of traditional
> 'variables' by doing everything as much as possible on the stack so I
> don't have to name 'variables' - haven't had to use 'locals' yet - in
> fact I don't know how to do this yet which may well be a good thing.
In the courses I teach, I don't introduce variables at all until the second
day, to ensure students get lots of practice with the stack. And even then
I get after people who define variables unnecessarily. A good guideline is
to define a variable where you would use a "global" in other languages, e.g.
for persistent data that will be accessed at various parts of your program
or for data that is needed by multiple tasks. Anything for which you'd
define a "local variable" you should use the stack for. I don't actually
teach locals in my class at all, and they are not in my introductory book.
In my experience cases in which they are actually helpful are very rare, and
for beginners they encourage bad habits and poor stack management.
> How do I learn about the more advance stuff? Like keeping errr... name
> space pollution to a minimum (okay, I guess I am a bit hung up about
> this now, but that's probably cos I know no better?)
Wordlists/vocabularies are covered briefly in my "Application Techniques"
book. But (as I and others keep saying) it really isn't as much a problem
as you seem to think. Really, don't worry about it for now.
Julian V. Noble
>
> Good day all. I have just begun learning forth just as a pastime and I
> have just realised there is actually very little material out there
> for the uninitiated. I have to say what little I have found has been
> pretty good - and am currently thumbing thru' Leo Brodie's Starting
> Forth.
>
> I am not sure however if I am doing it mm... right?
http://Galileo.phys.Virginia.EDU/classes/551.jvn.fall01/primer.htm
--
Julian V. Noble
Professor Emeritus of Physics
j...@lessspamformother.virginia.edu
^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/
"As democracy is perfected, the office of president represents, more and
more closely, the inner soul of the people. On some great and glorious
day the plain folks of the land will reach their heart's desire at last
and the White House will be adorned by a downright moron."
--- H. L. Mencken (1880 - 1956)
Albert van der Horst
<robert.sp...@gmail.com> wrote:
>
<SNIP>
>
>There's probably no better way to learn a language than starting to try
>and write something useful.
>
>I was thinking when I've learnt enough I might write an mp3 encoder or
>adapt a DeCSS to forth. Thing is I've seen the output of optimizing c
>compilers and I reckon it will be a bit of a challenge to see if one
>can do better...
If you are serious... Bernd Paysan has mentioned this before.
There is no good open source OCR program. There is a gocr, but it is
crap. Now there is a killer. I know pretty well how it should be
structured, I have put some thoughts into it. Bernd Paysan has made
some remarks too. With the recent success of a community effort to get
Thinking Forth availability, we just might ...
OCR is extremely important and valueable for the free world (as in freedom
not as in capitalism). It plays an important role in distributing news
about the crap patents that are pushed in Europe. Now they are public
in the sense that you are allowed to go there and fotocopy lousy two column
type writer pages. Conspiration theories abound here.
This hampers the free software foundation in getting competent people
look into these. There are reportedly already 60.000 of them.
You just can't search them efficiently without computers.
Then there is millions (yes millions) of books and documents to be scanned.
The strong points of Forth would suggest to have a book paging automaton
with built in ocr.
For example. After the war Unilever and the Dutch "Christen Democrats"
conspired to get hold of the margarine machines payed for by the company
my mother worked for. It is not unlikely that I own the last copy of
"Wat ons bedrijf wedervoer." This is a historic document with literal
texts of letters back and forth. I must get that out on the Internet.
<SNIP>
>
>Heh, is that a coincidence or what, your book's in the mail to me from
>Amazon :) I'm sort of hoping it'll answer all those queries and set me
>down the right path. Can I post questions here ;-)
>
>Cheers
>
>Rob
>
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
robert.sp...@gmail.com
Albert van der Horst wrote:
> If you are serious... Bernd Paysan has mentioned this before.
> There is no good open source OCR program. There is a gocr, but it is
> crap. Now there is a killer. I know pretty well how it should be
> structured, I have put some thoughts into it. Bernd Paysan has made
> some remarks too. With the recent success of a community effort to
get
> Thinking Forth availability, we just might ...
You are right, that is an interesting project. However way beyond my
means at present ;) I've yet to prove to myself I can write practical
code in forth - hey I have YET to learn it properly.
I guess the best way perhaps for me to learn is to adapt simpler
algorithms that perhaps are well known and try and translate them to
forth, ideally not direct translations but optimised to the features of
the language.
Start simple with sorts, trees and stuff all the way to perhaps file
compression that sort of thing. I can be overly abmbitious but I guess
it's best to take it slow. Rome not built in a day and all that.
I was just thinking (and this is probably blasphemy on this newsgroup)
but there are tons more C programmers around - what are the odds that
the first usable free OCR will be in C? (I have not seen FOCR so I
don't know how good it is... it is in C nope?)
What's really scary is what optimizing c compilers can do with code
these days... they're pretty impressive already on IA32's - I can't
speak with any experience on this but they must be VERY SCARY on risc
machines with tons of registers and where perhaps compiler scheduling
of instructions is more important than pentiums.
How do the native forth compilers fare on riscs?
Cheers
Rob
PS Off topic, but this google groups online newsreader is a load of
b0ll0x...
robert.sp...@gmail.com
> On 11 Jan 2005 02:17:00 -0800, robert.sp...@gmail.com wrote:
> >How do I learn about the more advance stuff? Like keeping errr...
name
> >space pollution to a minimum (okay, I guess I am a bit hung up about
> >this now, but that's probably cos I know no better?)
>
> The traditional thing to do is to hide implementation factors
> inside vocabularies to provide namespace control.
Thanks - will look into that!
At this stage I want to thank all of you here for all your help! I
stumbled onto forth quite by accident I have to admit - I have Neal
Bridges to thank in this regard - I was looking for a PalmOS dev kit
and his forth was free to try.
I also have Stephen here to thank for his free to try VFX - thanks for
a stonkin' gret compiler.
Eliz Rather: Your book arrived in the mail today. It's great,
complements Starting Forth quite well especially with regardst to the
newer aspects of forth as it is today.
And all you guys here at c.l.f. - another serendipitous find like forth
itself, I was pleasantly surprised to see pretty much who's who in
forth pretty much here.
*** Where is Chuck Moore by the way - I would have thought he would be
present here to if not intermittently given the presence of everyone
else here....
While we're at it - speaking of Chuck Moore - ColorForth - reminding me
of tail call recursion/optimisation:
ie
: foo ... ... ... ... a-word ;
compiled to : ...
jsr a-word
rts
optimized to: ...
jmp a-word
(using a-word's rts or further jmp to a rts to return)
Stephen I know you leave it pretty much as an option for your users to
implement on VFX if they want. Forth inc's Swift does it pretty much
consistently.
What's the verdict, is this good or bad?
Been wracking my brains trying to think of disadvantages to this, I can
only think if a programmer tries to get the return address of the EXACT
calling word off the stack he won't get it - but is this useful?
Well back to the day job for now - no doubts I shall be back ;)
Cheers Rob
Richard Owlett
robert.sp...@gmail.com wrote:
>[SNIP]
>
> PS Off topic, but this google groups online newsreader is a load of
> b0ll0x...
>
I just challenged Google to prove they pay attention to negative comments.
Doubt I'll get response :(
Richard Owlett
> [snip]
>
> *** Where is Chuck Moore by the way - I would have thought he would be
> present here to if not intermittently given the presence of everyone
> else here....
>
He does occasionally show up here.
I suspect that if he appeared as often as many wished, he would never
get anything done :)
I do suspect he finds a need to earn a living ;)
PS to whomever may filter mail for him,
Tell him *thank you*
Ian Osgood
robert.spykerma...@gmail.com wrote:
>
> At this stage I want to thank all of you here for all your help! I
> stumbled onto forth quite by accident I have to admit - I have Neal
> Bridges to thank in this regard - I was looking for a PalmOS dev kit
> and his forth was free to try.
I also use Quartus Forth for hacking on the bus. Check out the
Sleepless Night Wiki for lots of Quartus and Palm programming tips:
http://kristopherjohnson.net/wiki/
> *** Where is Chuck Moore by the way - I would have thought he would
be
> present here to if not intermittently given the presence of everyone
> else here....
Chuck chimes in occasionally on the colorForth mailing list.
The archives are at http://www.strangegizmo.com/forth/
Jeff Fox will sometimes update c.l.f about Chuck's current work.
> Well back to the day job for now - no doubts I shall be back ;)
> Cheers Rob
Ian
Richard Owlett
Well I got expected AD (artificially dumb) reply
Odds on intelligent reply anyone ?
Paul E. Bennett
> Stephen Pelc wrote:
>> On 11 Jan 2005 02:17:00 -0800, robert.sp...@gmail.com wrote:
>> >How do I learn about the more advance stuff? Like keeping errr...
> name
>> >space pollution to a minimum (okay, I guess I am a bit hung up about
>> >this now, but that's probably cos I know no better?)
>>
>> The traditional thing to do is to hide implementation factors
>> inside vocabularies to provide namespace control.
> [snip]
>
> Thanks - will look into that!
>
> At this stage I want to thank all of you here for all your help! I
> stumbled onto forth quite by accident I have to admit - I have Neal
> Bridges to thank in this regard - I was looking for a PalmOS dev kit
> and his forth was free to try.
>
> I also have Stephen here to thank for his free to try VFX - thanks for
> a stonkin' gret compiler.
>
> Eliz Rather: Your book arrived in the mail today. It's great,
> complements Starting Forth quite well especially with regardst to the
> newer aspects of forth as it is today.
Complete the set and get a copy of Thinking Forth as well.
http://thinking-forth.sourceforge.net/ has a pdf version (although it is
going through final proofing at present to ensure it is as close as
possible to the original prinbted version - well done guys). I think that
the other one that is worthwhile is John Matthews "Engineering Applications
in Forth"
As you seem to be sticking with Forth, for a while at least, then can I
suggest that you download a copy of my "Forth Coding Standard". This will
give you a useful style guide to start with but feel free to adapt it for
your own style if you wish to.
> And all you guys here at c.l.f. - another serendipitous find like forth
> itself, I was pleasantly surprised to see pretty much who's who in
> forth pretty much here.
...and we are good friends most of the time too ;>
> *** Where is Chuck Moore by the way - I would have thought he would be
> present here to if not intermittently given the presence of everyone
> else here....
He's busy continuing to push the boundaries of Forth even further and
completing commercial work. Whatever he is working on will filter down,
usually through Jeff Fox, in time when he is able to talk about it.
> Well back to the day job for now - no doubts I shall be back ;)
> Cheers Rob
Welcome anytime.
--
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Elizabeth D. Rather
news:cs458f$iar$1$8300...@news.demon.co.uk...
...
> > Eliz Rather: Your book arrived in the mail today. It's great,
> > complements Starting Forth quite well especially with regardst to the
> > newer aspects of forth as it is today.
>
> Complete the set and get a copy of Thinking Forth as well.
> http://thinking-forth.sourceforge.net/ has a pdf version (although it is
> going through final proofing at present to ensure it is as close as
> possible to the original prinbted version - well done guys). I think that
> the other one that is worthwhile is John Matthews "Engineering
Applications
> in Forth"
To *really* complete the set, get the Forth Programmer's Handbook, a
reference manual available as paper from our web site, or as a pdf with our
free SwiftForth evaluation version (also on the web site), and with all our
products.
> As you seem to be sticking with Forth, for a while at least, then can I
> suggest that you download a copy of my "Forth Coding Standard". This will
> give you a useful style guide to start with but feel free to adapt it for
> your own style if you wish to.
There is also a style guide in the back of Forth Application Techniques. It
includes two somewhat different approaches to source style, FORTH, Inc.'s
and the one adopted by the Open Firmware group. There are no absolutes
about style, the important thing is to adopt a style that you feel gives
readable results (even if you're the only one reading your code) and stick
with it consistently.
I'll also observe that for beginners it may be useful to adopt a somewhat
more vertical style than shown in my books, with a word or phrase per line
followed by a comment showing the stack effect of that word or phrase. As
you get more experienced, that becomes less necessary, and can give way to a
more horizontal style and comments devoted to explaining what's going on
logically.
Richard Owlett
I stand corrected. I've received the following:
"Thank you for your note. Please be assured that we read all the
mail that is received. Regardless of tone, user feedback is very
important to us and we keep all their ideas in mind as we work to
improve Google Groups. We appreciate your comments and have passed
on your comp.lang.forth and comp.dsp search suggestions to the
appropriate team."
[ I had mentioned the gripes I'd seen about Google news groups in some
threads. ]
Stephen Pelc
>What's really scary is what optimizing c compilers can do with code
>these days... they're pretty impressive already on IA32's - I can't
>speak with any experience on this but they must be VERY SCARY on risc
>machines with tons of registers and where perhaps compiler scheduling
>of instructions is more important than pentiums.
>
>How do the native forth compilers fare on riscs?
It depends on the benchmarks. Comparing VFX Forth for ARM against
gcc 2.2xx (95?) a few years ago gave about the same speeds. Comparing
gcc 3.4.x against last week's VFX for ARM on a Philips LPC2106 at
60 MHz gave gcc a 20% advantage on the Dhrystone benchmark (the
only one for which I have a comparison). The Forth code was
originally from Marcel Hendrix, uses a lot of locals, and
VFX could be more aggressive in its locals handling.
More Forthification of the Dhrystone code will help, and we
should recover the difference soon. The basic Dhrystone code
we use is derived from the benchmark code in BENCHMRK.FTH
available on our website. We will post the embedded version,
XBENCH32.FTH, when we've had a chance to perform a few more
ports.
Marcel Hendrix
> Comparing
> gcc 3.4.x against last week's VFX for ARM on a Philips LPC2106 at
> 60 MHz gave gcc a 20% advantage on the Dhrystone benchmark (the
> only one for which I have a comparison). The Forth code was
> originally from Marcel Hendrix, uses a lot of locals, and
> VFX could be more aggressive in its locals handling.
> More Forthification of the Dhrystone code will help, and we
> should recover the difference soon. The basic Dhrystone code
> we use is derived from the benchmark code in BENCHMRK.FTH
> available on our website. We will post the embedded version,
> XBENCH32.FTH, when we've had a chance to perform a few more
> ports.
There is a famous "bug" (related to COMPARE) in the Dhrystone that is copied
in benchmrk.frt. I just recently found it / noticed it. At least it did
affect iForth to an astonishing degree.
-marcel
m-coughlin
> Good day all. I have just begun learning forth just as a
> pastime and I have just realised there is actually very
> little material out there for the uninitiated. I have to say
> what little I have found has been pretty good - and am
> currently thumbing thru' Leo Brodie's Starting Forth.
>
> I am not sure however if I am doing it mm... right?
You shouldn't have to ask if you are doing it right, even
when you are just starting out. But as you say, there is
actually very little material out there for the uninitiated. You
are lucky to be able to read Leo Brodie's book since it has been
out of print for around a decade. I find it very strange that
Forth was used for the best book ever written about programming
but Forth programmers or vendors are not able to do the same
today. There is plenty of material for learning about Forth for
the initiated and by asking about anything you don't understand
on comp.lang.forth you will find the answers you need.
[snip]
> Incidentally MPE ltd were very kind to let me test-drive their
> evaluation version of VFX Forth Windows. I have to say I am
> totally gobsmacked. I did not know forth compilers could
> optimize like that.
Forth is a general purpose computer language and can be used
for any application. Then there is also the idea that with
properly written Forth there is no need for an optimizing compiler.
--
Michael Coughlin m-cou...@comcast.net Cambridge, MA USA
Coos Haak
<>
> Forth is a general purpose computer language and can be used
> for any application.
Yes, I agree
> Then there is also the idea that with
> properly written Forth there is no need for an optimizing compiler.
We don't need P XII's in the 21st century.
We don't need aeroplanes in the 20th century
We don't need steam engines in the 19th century.
We don't need coinage in the 12th century
We don't need houses in the 4th millenium BC.
--
Coos
Anton Ertl
>How do the native forth compilers fare on riscs?
PPC: Take a look at PowerMops or D; should be somewhat like VFX, but
with more registers available.
ARM: VFX is available there.
MIPS: RAFTS was a little better, but never released.
>PS Off topic, but this google groups online newsreader is a load of
>b0ll0x...
I have recently added a section about reading and posting to
comp.lang.forth to the FAQ:
http://www.complang.tuwien.ac.at/forth/faq/faq-general-6.html
For the general critique, here it is:
6.1. How can I read and post to comp.lang.forth?
The usual way is to use a newsreader and an NNTP server. If your
internet provider does not offer you access to a good NNTP server, you
might consider switching providers. There is also a free
(registration required) NNTP server: news.individual.net.
Once you have access to an NNTP server, you can use a wide variety of
newsreaders. You should consider using one that has passed the GNKSA
<http://www.gnksa.org/gnksa-evaluations.html> test, as such
newsreaders can help you to avoid a number of errors when posting
(even if you don't want to post right now, you probably don't want to
have to change the newsreader if you ever decide to post).
Even with a good newsreader, you should make test postings to a test
group (e.g., misc.test) before posting to discussion groups like
comp.lang.forth. Also, check your test postings; not with your
newsreader, as it tends to hide its own errors; try the "Show
original" button of Google groups <http://groups.google.com/> or use
telnet <http://www.complang.tuwien.ac.at/anton/mail-news-
errors.html#line-breaks>.
Not only your newsreader should be well-behaved, you should be as
well. Most people will do ok if they read the newsgroup they want to
post to for a while before posting (note that different newsgroups can
have different cultures). If you want to learn more, read the
Netiquette <http://rfc.net/rfc1855.html>, news.newusers.answers, about
smart questions <http://www.catb.org/~esr/faqs/smart-questions.html>,
or about avoiding common mistakes
<http://www.complang.tuwien.ac.at/anton/mail-news-errors.html>.
As a poor alternative to an NNTP server, you can also use Google
Groups.
Bruce McFarling
Coos Haak wrote:
> We don't need aeroplanes in the 20th century
Certainly not, airplanes will serve quite nicely.
However, sometime in the 21st century we will discover
the need a bit more material efficiency in the way we
do things. Dispensing with a need is quite often the
most materially efficient way of satisfying it.
robert spyke
<m-cou...@comcast.net> wrote:
[snippety-snip]
>Rob Spykerman wrote:
>
>> I am not sure however if I am doing it mm... right?
>
> You shouldn't have to ask if you are doing it right, even
>when you are just starting out.
As 7 of 9 would probably reply, 'Explain?'
> I find it very strange that
>Forth was used for the best book ever written about programming
>but Forth programmers or vendors are not able to do the same
>today.
I find it strange that apparently there is so much embedded forth
around yet there's so little material around perhaps because of the
_'fashion'_ of the moment.
To be honest, there's not a lot available for low-level programming
either. In the past where one could get a book for say, oh, say a Z80
or a 6502 in a bookstore, these days, it's hard enough finding a
book for x86 assembly, what with all the Java and C++ stuff around. In
fact in most borders where I am, C++ books already outnumber C books
which seems to be the sign of the times.
Which is a bit of a pain because what I REALLY am looking for is a
good book on learning how to use x87 instructions or SSE3 (for that
matter the whole gamut of SIMD instructions these new processors
have).
> Forth is a general purpose computer language and can be used
>for any application. Then there is also the idea that with
>properly written Forth there is no need for an optimizing compiler.
Again, as 7 of 9 would say, 'Explain!'
I think this would depend.
This is relative. Speed that is. How much you need. With computers at
gigahertz speed one could argue code need not be optimized purely for
speed but convenience hence oop and scripting languages like python,
perl which could yield acceptable performance.
However, if it is speed and speed alone, here are my ideas... ( and
look, you wouldn't like your perl interpreter compiled by a crappy
compiler would you? )
Firstly I would say that even with the best written forth code (ie
pure forth no assembly except primitives), all that stack maneuvering
costs CPU cycles.
A compiler which can spit code that juggles more of these maneuvers in
registers will be obviously generating better code than one that keeps
pushing and popping off a stack in memory exclusively.
For example at present, in my recent explorations, my understanding of
looping with do loops in forth is that it's VERY expensive because of
the counter having to exist on the return stack. I guess it could be a
language necessity. But if a compiler was smart enough to perhaps use
a register as a counter, that's again a step up in efficiency. Of
course, you could avoid 'do' loops altogether too - I have yet to look
at the begin until looping code on the compilers I use to see if this
is any better.
Then it's choosing the right instructions depending on the context.
ie, I reckon in most chips to compare with x, if x = 0 it's probably
faster to:
or r1, r1
rather than a
cmp r1, # 0
(because the #0 which is presumably word length has to be fetched from
memory - of course if it's a risc, you'll probably have to do register
compares so it may not matter then).
Then to zero a register,
xor r1, r1 is probably again better than
mv 0, r1
(depending again on the context, if flags can be ignored etc)
I am sure there are tons of other examples a real compiler writer can
give you.
And then there is the matter of choosing the right order of
instructions.
This is of some importance on pentiums even with the out of ordering,
but what about other risc machines where instruction scheduling is so
critical for optimal performance - all those rules you need to
remember, that even hand assembly is difficult - arguably these days
optimizing c compilers generate better code on average than average
assembly language programmers.
No, I argue if you are going to compile something, you should be able
to compile it optimally....
Even Chuck Moore optimized colorforth.... (ie tail call optimisation
for one)
Cheers
Rob
Howard Lee Harkness
> m-coughlin <m-cou...@comcast.net> wrote:
>> Forth is a general purpose computer language and can be used
>>for any application. Then there is also the idea that with
>>properly written Forth there is no need for an optimizing compiler.
>Again, as 7 of 9 would say, 'Explain!'
Forth is the "assembly language" of the Forth machine. In assembly language,
the only optimizations possible have to do with choosing the right algorythms
and implementing them correctly.
Having actually programmed on a Forth machine (RTX2000), I think I can
confidently claim that the only possible optimization has to come from proper
algorithm choice. I was greatly humbled by a programmer from Rockwell that took
my program, made a few choice changes of algorythm, and made my program run
about 10 time faster. I don't believe that current compiler technology is
capable of choosing the right algorythms for you.
m-coughlin
>
> On Thu, 13 Jan 2005 13:27:46 -0500, m-coughlin
> <m-cou...@comcast.net> wrote:
>
> [snippety-snip]
>
> >Rob Spykerman wrote:
> >
> >> I am not sure however if I am doing it mm... right?
> >
> > You shouldn't have to ask if you are doing it right, even
> >when you are just starting out.
>
> As 7 of 9 would probably reply, 'Explain?'
>
> > I find it very strange that
> >Forth was used for the best book ever written about
> >programming but Forth programmers or vendors are not able
> >to do the same today.
The explanation follows my statement immediately. If Forth
had continued to be used to write good books on programming (as
it was in 1981 to 1987), then you could just read about the
right way of doing things when you were starting out.
> I find it strange that apparently there is so much embedded
> forth around yet there's so little material around perhaps
> because of the _'fashion'_ of the moment.
There is very little of embedded Forth around. One of the
main uses of Forth is programming embedded systems but Forth's
market share of programming embedded systems is very low. It is
clear to me that this is due to the difficulty new programmers
have in finding out about Forth and learning to use it. Perhaps
the criticism I will receive for such an opinion will result in
an improvement of the situation.
> To be honest, there's not a lot available for low-level
> programming either. In the past where one could get a book for
> say, oh, say a Z80 or a 6502 in a bookstore, these days, it's
> hard enough finding a book for x86 assembly, what with all the
> Java and C++ stuff around. In fact in most borders where I am,
> C++ books already outnumber C books which seems to be the sign
> of the times.
>
> Which is a bit of a pain because what I REALLY am looking for
> is a good book on learning how to use x87 instructions or SSE3
> (for that matter the whole gamut of SIMD instructions these new
> processors have).
In the past the limited power of home computers made it
necessary to learn and use assembly language in order to get
then to do anything worth buying. Nowadays, the increased power
of computers has made it necessary to find much better ways of
programming. Low level programming textbooks are still
available, but not usually in bookstores. The CPU manufacturers
provide these books free for the asking and there are many
tutorials available on the web for more elementary instruction.
m-coughlin
>
> On Thu, 13 Jan 2005 13:27:46 -0500, m-coughlin
> <m-cou...@comcast.net> wrote:
>
> [snippety-snip]
>
> > used for any application. Then there is also the idea that
> > with properly written Forth there is no need for an
> > optimizing compiler.
>
> Again, as 7 of 9 would say, 'Explain!'
Forth is neither a compiler nor an interpreter. It is its
own thing. An optimizing compiler is needed for languages like
Fortran and C. Forth does things differently. Is there such a
thing as an optimizing assembler? I haven't heard of that yet.
Maybe Forth should be in the same category.
> I think this would depend.
>
> This is relative. Speed that is. How much you need. With
> computers at gigahertz speed one could argue code need not be
> optimized purely for speed but convenience hence oop and
> scripting languages like python, perl which could yield
> acceptable performance.
>
> However, if it is speed and speed alone, here are my ideas...
> ( and look, you wouldn't like your perl interpreter compiled
> by a crappy compiler would you? )
>
> Firstly I would say that even with the best written forth code
> (ie pure forth no assembly except primitives), all that stack
> maneuvering costs CPU cycles.
The best written Forth code needs to include assembly
language primitives. There has been an attempt lately to change
Forth source code style to make it portable. Forth is inherently
a way to write non-portable code. A change like this makes Forth
into something that is not Forth. It is like the attempts to
write a universal portable assembly language. I think the
efforts to make Forth a portable compiled language are
interesting and it would be a great improvement if it was called
something other than "Forth". A nice distinctive name would show
up well in Google searches.
> A compiler which can spit code that juggles more of these
> maneuvers in registers will be obviously generating better
> code than one that keeps pushing and popping off a stack in
> memory exclusively.
>
> For example at present, in my recent explorations, my
> understanding of looping with do loops in forth is that
> it's VERY expensive because of the counter having to exist
> on the return stack. I guess it could be a language necessity.
> But if a compiler was smart enough to perhaps use a register
> as a counter, that's again a step up in efficiency. Of course,
> you could avoid 'do' loops altogether too - I have yet to look
> at the begin until looping code on the compilers I use to see
> if this is any better.
Such considerations have been extensively explored and many
different low level coding variations have been used in
different versions of Forth. These have not been documented for
beginners who are just starting out learning about Forth. In
fact, they have not even been well documented for experienced
Forth programmers who usually reverse engineer any code they
need to understand better. Now that you have brought up the
topic, I expect you will receive some information on the
varieties of low level Forth implementations. Once again, this
is not a topic for beginners, but perhaps it should be.
Albert van der Horst
robert spyke <robspyke_nospam@nos_spam_iprimus.com.au_nospam> wrote:
>
>Which is a bit of a pain because what I REALLY am looking for is a
>good book on learning how to use x87 instructions or SSE3 (for that
>matter the whole gamut of SIMD instructions these new processors
>have).
A free and autoritive source for Intel processors is Intel.
Download the Pentium architecture manuals. They contain a
surprising amount of tutorial material.
<SNIP>
>This is of some importance on pentiums even with the out of ordering,
>but what about other risc machines where instruction scheduling is so
>critical for optimal performance - all those rules you need to
>remember, that even hand assembly is difficult - arguably these days
>optimizing c compilers generate better code on average than average
>assembly language programmers.
>
>No, I argue if you are going to compile something, you should be able
>to compile it optimally....
Well. Eh. Lets say that only a few knowledgeable people here at
c.l.f. dare to touch the subject.
>
>Even Chuck Moore optimized colorforth.... (ie tail call optimisation
>for one)
Hardly. He keeps things simple, then Intel processors are fast.
He doesn't much in the direction of instruction scheduling in
his Forth. (I have been reading those assembler sources rather
thoroughly.).
He does a O(n) search to look up a word. This is theoretically
inferior compared to hashing and whatnot. But n is small (ca.
1000) and the lookup is simple (finding a 32 bit value in an
array.)
>
>Cheers
>
>Rob
Groetjes Albert.
--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.
Paul E. Bennett
> There is very little of embedded Forth around.
Just because it is not very publicly apparent which embedded systems are
programmed in Forth does not mean that there are very few. There may be
more surprises than you think out there. I suppose we will all have to
remain uncertain about the proportions. ;>
Elizabeth D. Rather
message news:5bjlu0pm9mf9abv8m...@4ax.com...
> ...
> I find it strange that apparently there is so much embedded forth
> around yet there's so little material around perhaps because of the
> _'fashion'_ of the moment.
>
> To be honest, there's not a lot available for low-level programming
> either. In the past where one could get a book for say, oh, say a Z80
> or a 6502 in a bookstore, these days, it's hard enough finding a
> book for x86 assembly, what with all the Java and C++ stuff around. In
> fact in most borders where I am, C++ books already outnumber C books
> which seems to be the sign of the times.
>
> Which is a bit of a pain because what I REALLY am looking for is a
> good book on learning how to use x87 instructions or SSE3 (for that
> matter the whole gamut of SIMD instructions these new processors
> have).
Well, our primary business for >30 years has been providing Forth
development systems and programming services for embedded systems. This is
a field that doesn't get much publicity or books written about it, and I
agree that it's too bad, since some studies I've seen indicate that there
are lots more microprocessors in use than desktop computers (any reasonably
new car has over 50, for example).
Our customers are writing firmware for everything from "smart cards" to
satellites, with many kinds of control systems in between. The thing is,
folks in the private sector don't usually have the time or incentive to
write books and magazine articles, so the whole field doesn't get publicized
in a way that makes it clear what's happening. Mike Coughlin is in
academia, and for him if it isn't in the MIT bookstore it doesn't exist. As
a result, he's pretty out of touch with real-world computing (particularly
the state of the art in the Forth community -- he's working on some
impressions from 20 years ago).
> > Forth is a general purpose computer language and can be used
> >for any application. Then there is also the idea that with
> >properly written Forth there is no need for an optimizing compiler.
>
> Again, as 7 of 9 would say, 'Explain!'
I actually disagree with that. We find an optimizing compiler to be very
helpful, and have them in all our Forth products.
> This is relative. Speed that is. How much you need. With computers at
> gigahertz speed one could argue code need not be optimized purely for
> speed but convenience hence oop and scripting languages like python,
> perl which could yield acceptable performance.
All true, but in the embedded world, where you may be dealing with 8051s and
AVRs and MSP430s, you need all the performance you can get.
> However, if it is speed and speed alone, here are my ideas... ( and
> look, you wouldn't like your perl interpreter compiled by a crappy
> compiler would you? )
>
> Firstly I would say that even with the best written forth code (ie
> pure forth no assembly except primitives), all that stack maneuvering
> costs CPU cycles.
It's not that clear. If you're trying to write modular code (which saves
memory and can greatly improve reliability) the cost of subroutine calls in
other languages can be quite steep. Unless all your local variables are in
registers (which is often not possible, particularly again on low-end
microcontrollers) you spend about as many cycles fetching and storing as you
would on stack manipulation. Finally, there's the possibility of putting
your stacks in on-board RAM on some chips, which helps a lot.
> A compiler which can spit code that juggles more of these maneuvers in
> registers will be obviously generating better code than one that keeps
> pushing and popping off a stack in memory exclusively.
Well, where possible we always keep the top stack item in a register as well
as the stack pointer, and also preserve several registers that can be used
as scratch without saving & restoring. Usually you aren't dealing with more
than the top few things, so it really isn't that costly.
> For example at present, in my recent explorations, my understanding of
> looping with do loops in forth is that it's VERY expensive because of
> the counter having to exist on the return stack. I guess it could be a
> language necessity. But if a compiler was smart enough to perhaps use
> a register as a counter, that's again a step up in efficiency. Of
> course, you could avoid 'do' loops altogether too - I have yet to look
> at the begin until looping code on the compilers I use to see if this
> is any better.
Do loops are somewhat more expensive than begin-type ("indefinite") loops,
but you also get the loop counter -- depending on what you're doing, if you
have to simulate a loop counter manually in an indefinite loop, it's slower
than the do loop. The return stack pointer is almost always in a register,
and that code is pretty tight. They're not nearly as bad as you seem to
think. If you need to do something a known number of times or need access
to a loop counter, you're better off using a do...loop.
But in embedded systems code speed isn't usually the most important issue.
Your performance is mainly going to depend on I/O, and memory may be
limited. And I completely agree with Harkness' comment that ultimately it's
the algorithm (or system design) that really matters. Let me tell you a
true story (which old timers here have heard, but you haven't):
Some years ago American Airlines asked us to re-write the program managing
their baggage handling system at LAX. It was written in assembly language,
and was too hard to maintain. Our program had to run on the same hardware
and present an identical user interface to the operators. It was a very
complex system, and it took us several months to do it. Part of the
acceptance test was the original requirement of handling 1000 bags/hour on
each line, a requirement which the assembler program had never achieved (it
could only do 800 bags/line). Our program, which was completely redesigned
on the inside, only the user interface was the same, passed 1200 bags on its
first time trial. Now, this was in the days *before* we were doing
optimizing compilers, and there's no way our code was itself running faster
than assembler -- but we had a far more efficient overall system design, and
that made all the difference.
John Doty
> Our customers are writing firmware for everything from "smart cards" to
> satellites,
There's very little Forth in satellites these days. Worse, Forth has
lost the respect of the community that builds them: I've heard very
little positive, and much negative, about Forth in this community over
the last 10 years.
> with many kinds of control systems in between. The thing is,
> folks in the private sector don't usually have the time or incentive to
> write books and magazine articles, so the whole field doesn't get publicized
> in a way that makes it clear what's happening.
Not true. People in academia write lots in areas like robotics. Forth
appears to be in steep decline there, too.
> Mike Coughlin is in
> academia, and for him if it isn't in the MIT bookstore it doesn't exist.
Nah, Mike's a Hahvahd guy: he wouldn't be caught dead at the Coop in
Kendall Square :-)
> As
> a result, he's pretty out of touch with real-world computing (particularly
> the state of the art in the Forth community -- he's working on some
> impressions from 20 years ago).
It is very strange for *you* to make this claim. Mike has a far broader
perspective than you. Forth is a tiny corner of a broad world about
which you know very little.
The Forth Mike knows about is the Forth that invited astronomers to use
it, before the mainstream Forths became so complex and obfuscated that
only specialists find them usable.
-jpd
Elizabeth D. Rather
news:41EC84AE...@whispertel.LoseTheH.net...
> Elizabeth D. Rather wrote:
>
> > Our customers are writing firmware for everything from "smart cards" to
> > satellites,
>
> There's very little Forth in satellites these days. Worse, Forth has
> lost the respect of the community that builds them: I've heard very
> little positive, and much negative, about Forth in this community over
> the last 10 years.
Well, we have several customers who are either working on satellite systems
now or have completed projects within the last few years, at Aerospace,
Lockheed Martin, and some lesser-known contractors. And I assume the folks
at Johns Hopkins APL are still using it.
...
> > Mike Coughlin is in
> > academia, and for him if it isn't in the MIT bookstore it doesn't exist.
>
> Nah, Mike's a Hahvahd guy: he wouldn't be caught dead at the Coop in
> Kendall Square :-)
That's the library he's mentioned in the past, I think.
> > As
> > a result, he's pretty out of touch with real-world computing
(particularly
> > the state of the art in the Forth community -- he's working on some
> > impressions from 20 years ago).
>
> It is very strange for *you* to make this claim. Mike has a far broader
> perspective than you. Forth is a tiny corner of a broad world about
> which you know very little.
I do know quite a lot about the Forth world, and Mike makes a lot of
extremely ill-informed statements about it. My statement was that he's out
of touch with the state of art in the Forth community -- I stand by that.
He hasn't read the books that are available today, nor used contemporary
Forth systems, nor even followed closely what their capabilities are.
> The Forth Mike knows about is the Forth that invited astronomers to use
> it, before the mainstream Forths became so complex and obfuscated that
> only specialists find them usable.
Hmm, he seems unaware of the group at the Smithsonian Astrophysical
Observatory that is currently using Forth (and has been for years), or Bob
Ghertz at the University of Minnesota and his colleagues.
Actually, the feedback we get from our customers is that our current
products are far simpler and easier for the user than the products of 20
years ago. I remember Chuck's axiom about the conservation of complexity;
we have put a lot of effort into making our systems be easy to learn and
use.
robert spykerman
<era...@forth.com> wrote:
>"robert spyke" <robspyke_nospam@nos_spam_iprimus.com.au_nospam> wrote in
[snip]
>Well, our primary business for >30 years has been providing Forth
>development systems and programming services for embedded systems. This is
>a field that doesn't get much publicity or books written about it, and I
>agree that it's too bad, since some studies I've seen indicate that there
>are lots more microprocessors in use than desktop computers (any reasonably
>new car has over 50, for example).
Yeah, and there are some weird lunatics (hand raised) that actually
want to learn forth - mainly because it looks intensely mad and fun
and is so interactive. It's close enough to the machine, in fact, much
nicer than C to interface with asm, and since I'm looking to bone up
on x86 asm as well, it's perfect.
I have to admit I have never had so much fun in ages. The last time I
remember having that much fun was with an apple II, you know,
]CALL -151
*300: A9 C0 8D etc....
*300G
That sort of madness...
>I actually disagree with that. We find an optimizing compiler to be very
>helpful, and have them in all our Forth products.
I would agree.... Algorithms being similar, I find it extremely
difficult to write better asm than an optimizing c compiler (but I'm
not a great asm programmer). On some compilers, it's easy to see
what's being stuck on the stack and should be in the registers and
it's also easy to see what jumps can be eliminated for pipeline
efficiency that sort of thing - I have to say that now apart from the
PIV and PIII.
I've also seen code on PowerPC's (briefly - Macs) generated by forth
compilers which, given the number of registers, looked like a little
hand optimisation (ie more stuff in registers) would have gone a long
way. Which one specifically I cannot recall.
I know I don't have any real PPC asm experience but when you've got 32
registers and perhaps if half of them are reserved, you've still got
16! However I am also aware that there are diminishing returns - it
can get very complicated trying to juggle more than 1 or 2 stack items
in registers - you may end up eating more cycles moving stuff round
than leaving them in memory - I don't know. That's where I believe
optimizing compilers can come in - where a processor was not designed
for a stack intensive language like forth, an optimizing compiler can
certainly help.
>Well, where possible we always keep the top stack item in a register as well
>as the stack pointer, and also preserve several registers that can be used
>as scratch without saving & restoring. Usually you aren't dealing with more
>than the top few things, so it really isn't that costly.
I'm glad there are compilers like Swift and VFX - that's my point
exactly - we need compilers like these for machines that are not
exclusively designed for forth in mind.
>Do loops are somewhat more expensive than begin-type ("indefinite") loops,
>but you also get the loop counter -- depending on what you're doing, if you
>have to simulate a loop counter manually in an indefinite loop, it's slower
>than the do loop. The return stack pointer is almost always in a register,
>and that code is pretty tight. They're not nearly as bad as you seem to
>think. If you need to do something a known number of times or need access
>to a loop counter, you're better off using a do...loop.
Or a low level rewrite :) I've noticed a 30% - 100% gain in speed
doing so depending on the complexity - but then agian I may not be
writing optimal code at a higher level.
What I am really beginning to like about forth is it's ability to let
you go as low as you like and interactively debug the stuff and code
the stuff you don't want to code in a higher level language - which
you can write yourself even, all within the same environment with none
of that compile/asm/link cycle c has go undergo.
>>But in embedded systems code speed isn't usually the most important issue.
>Your performance is mainly going to depend on I/O, and memory may be
>limited. And I completely agree with Harkness' comment that ultimately it's
>the algorithm (or system design) that really matters. Let me tell you a
>true story (which old timers here have heard, but you haven't):
[snip]
Let me tell you another story about where I work we have software
running exclusively on x86 windoze pc's and for reasons best known to
IT (I don't work in IT - I don't do computers for a living!) put in
this JAVA application to access a database of very high resolution
images - which we have to look at very frequently.
God knows why. Didn't NEED to be in Java I reckon, but sure I'm not an
IT guy. Suffice to say it crawls... It may be badly written as well
for it needs restarting frequently.
I can't see why it could not have been done with Delphi... or to keep
with the KISS rule...
I can't see any reason why it couldn't have been a CGI app residing on
another server which one could access with a browser (it would then
theoretically be more portable even, you wouldn't even need java).
But such is fashion.. I guess..
But again, I'll say, Forth reminds me of the bygone days of an Apple
][ + and messing with 6502 code in the monitor. Which in my books is a
definite winner.
Maybe that's where you should target your customer base. There's lots
of people like me around you know? I have to admit, most will
initially go, 'You what? Forth?' but once they give it a try...
Cheers
Rob
robert spykerman
<m-cou...@comcast.net> wrote:
>robert spyke wrote:
>>
> Forth is neither a compiler nor an interpreter. It is its
>own thing. An optimizing compiler is needed for languages like
>Fortran and C. Forth does things differently. Is there such a
>thing as an optimizing assembler? I haven't heard of that yet.
>Maybe Forth should be in the same category.
I have to say, I was just thinking to myself what a wonderful
assembler forth is... I am almost tempted to say it's easier to write
assembly in forth than in a classical assembler because of the turn
around time, and also because realistically, it's rather impractical
to write large blocks of assembly in forth - so you've got to break
down and factor, which makes you plan a little more and not get too
caught up in rats nests.
I might get spanked for saying that but I say this with the following
caveat
1. I only mess with computers for fun. (ie not for a living)
2. I actually WANT to learn forth
3. I want to learn x86 assembly too
2 and 3 aren't particularly mutually exclusive in Forth I guess...
But I can see what you're saying about forth being it's own thing.
I would still argue an optimizing compiler is needed for Forth - if
it's embedded forth, to optimize for size perhaps, if constraints are
limited
Iff otherwise, it's likely to be for a desktop and AFAIK, none of the
major deskstops CPU's are stack CPU's, and hence optimisation is
desirable, if not, necessary, to compete with other languages like C -
algoritms being equal ... or should I say equivalent.... for example.
C compilers are VERY scary sometimes - the mainstream ones... Sure,
calls are expensive and all that but I think it's extremely hard to
beat them at assembly code generation if your c code is optimal. Only
when it does something silly that a human can see a better obvious
solution... Most know many tricks... I've learnt quite a bit from c
compiler output.....
Anyways back to the day job. Mmm.. that reminds me... have been
meaning to write up some words for statistics... Has anyone done this
yet? Might do that later.
Cheers
Rob
Stan Barr
>development systems and programming services for embedded systems. This is
>a field that doesn't get much publicity or books written about it, and I
>agree that it's too bad, since some studies I've seen indicate that there
>are lots more microprocessors in use than desktop computers (any reasonably
>new car has over 50, for example).
A recent magazine article stated that the second largest selling processor
in 2004 was the ARC with nearly 100 million sold in 2004, that must beat
the number of desktop units sold. I wonder, how many were programmmed in
Forth? It looks quite an interesting processor.
--
Cheers,
Stan Barr stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)
The future was never like this!
Marc Olschok
>[...]
> ][ + and messing with 6502 code in the monitor. Which in my books is a
> definite winner.
In fact there was a Forth (written by William Graves) for the Apple II
which made the Apple even more palatable in the old days.
Marc
Paul E. Bennett
[%X]
> .... I remember Chuck's axiom about the conservation of complexity;
That sounds like an interesting one. I don't recall seeing it written
anywhere. Is there a reference for it?
John Doty
> "John Doty" <j...@whispertel.LoseTheH.net> wrote in message
> news:41EC84AE...@whispertel.LoseTheH.net...
>
>>Elizabeth D. Rather wrote:
>>
>>
>>>Our customers are writing firmware for everything from "smart cards" to
>>>satellites,
>>
>>There's very little Forth in satellites these days. Worse, Forth has
>>lost the respect of the community that builds them: I've heard very
>>little positive, and much negative, about Forth in this community over
>>the last 10 years.
>
>
> Well, we have several customers who are either working on satellite systems
> now or have completed projects within the last few years, at Aerospace,
> Lockheed Martin, and some lesser-known contractors. And I assume the folks
> at Johns Hopkins APL are still using it.
Sure. The space program is a museum of obsolete technologies. When I
redesigned the HETE measurement chains for Chandra, the R&QA folks made
me change the NPN transistors to 2N930's. I'm not sure when that spec
was registered, but it's listed in my 1962 GE Transistor Manual. Why
taking a silicon chip cooked in a relatively modern process, sticking it
in a brittle, obsolete package, and procuring it to a vague, sloppy spec
makes these guys believe it'll make your system more reliable I cannot say.
So, yes, there are still a few small things happening in Forth in space,
and there will continue to be for some time. That doesn't change the
fact that its reputation is in steep decline.
> I do know quite a lot about the Forth world,
*ANS* Forth world.
> and Mike makes a lot of
> extremely ill-informed statements about it.
Mike's statements are about Forth, not ANS Forth.
> My statement was that he's out
> of touch with the state of art in the Forth community -- I stand by that.
*ANS* Forth community.
> He hasn't read the books that are available today, nor used contemporary
> Forth systems, nor even followed closely what their capabilities are.
Could it be that *ANS* Forth isn't what he is interested in?
> Actually, the feedback we get from our customers is that our current
> products are far simpler and easier for the user than the products of 20
> years ago.
Comparing your products to your products says nothing about the state of
Forth in general. Your customers are also not representative of the
applications community in general. Mike is an excellent case of someone
who has used and appreciated Forth, but has been ill served by ANS
Forth. Behind him there are many, many more who have simply given up on
Forth. You know nothing of these people.
> I remember Chuck's axiom about the conservation of complexity;
> we have put a lot of effort into making our systems be easy to learn and
> use.
You haven't done your homework here. All you know is ANS Forth: you know
almost nothing of alternate techniques. You have no right to complain of
Mike's ignorance when your own ignorance is so much more comprehensive
and willful. You've hidden from the broader computing world for 30
years. "Easy to learn and use" for an ANS Forth specialist is nothing
like "easy to learn and use" for the rest of us.
It would be really nice to see Forth rise from the ashes and become a
viable option for my projects again. But every time you post, I get
discouraged: you are working as hard as you possibly can to marginalize
Forth further.
-jpd
Elizabeth D. Rather
> Elizabeth D. Rather wrote:
>
> [%X]
>
> > .... I remember Chuck's axiom about the conservation of complexity;
>
> That sounds like an interesting one. I don't recall seeing it written
> anywhere. Is there a reference for it?
It goes something like this:
Any given problem has a certain intrinsic level of complexity. In the
solution of the problem, this complexity will be conserved: if you dive in
with too little advance thought, your solution may become very complex by
the time it's done. On the other hand, if you invest more in thought,
design, and preparation, you may be able to achieve a very simple solution
(the complexity hasn't gone away, it's become embodied in the sophistication
of the design).
In connection with our recent discussion, that investment certainly can take
the form of prototyping. When I was working with Chuck, he'd typically go
through the following process:
1. Read the spec. Assert confidently that it really isn't as complicated as
that, and write a very clever program that solves the essence of the
problem.
2. Enter a phase in which the customer repeatedly points out aspects of the
spec that have been ignored or omitted; in fixing these, the code gets more
and more complicated.
3. At some point, a full understanding of the problem emerges. All the
previous code is thrown out and a new program emerges which represents a
simple, elegant solution to the *whole* problem.
Stephen Pelc
<robspyke_nospam@nos_spam_iprimus.com.au_nospam> wrote:
>No, I argue if you are going to compile something, you should be able
>to compile it optimally....
Before you do that, you have to be able to compile it
correctly *in all cases*.
Especially with current implementations of the i32
instruction set and P4 memory system, it is quite
possible to improve code performance for one algorithm
and ruin it on another. This leads to testing on a
range of benchmarks, which in turn leads to arguments
about which benchmarks are relevant.
Paul E. Bennett
Thanks Liz. That certainly falls into the lines that I was thinking it
might.
On the subject of prototypes, these need not always be code prototypes.
nocnick
dark ages.
Closed up in monasteries with eager monks transcribing page for page and
trying to keep the flame alive.
Forth for sure is one of the things you have to close your eyes to see its
brightness, gee, I'm afraid I'm carried away by all the wisdom I read
here...
;)
Gerhard
<kind of kiddin'?>
m-coughlin
>
> Elizabeth D. Rather wrote:
>
> > Our customers are writing firmware for everything from "smart
> > cards" to satellites,
>
> There's very little Forth in satellites these days. Worse,
> Forth has lost the respect of the community that builds them:
> I've heard very little positive, and much negative, about
> Forth in this community over the last 10 years.
>
> > with many kinds of control systems in between. The thing
> > is, folks in the private sector don't usually have the
> > time or incentive to write books and magazine articles,
> > so the whole field doesn't get publicized in a way that
> > makes it clear what's happening.
>
> Not true. People in academia write lots in areas like robotics.
> Forth appears to be in steep decline there, too.
>
> > Mike Coughlin is in academia, and for him if it isn't in
> > the MIT bookstore it doesn't exist.
>
> Nah, Mike's a Hahvahd guy: he wouldn't be caught dead at the
> Coop in Kendall Square :-)
My ambition is to be a renaissance man whose interests
cannot be neatly pigeonholed. Lets say for the sake of argument
that I am a Forth hobbyist, not a professional. As part of my
computer hobby, I look for people who could profitably use Forth
but do not, and pay particular attention to their reasons for
not using it or not even knowing it exists. Did anybody besides
me notice this thread was started by someone new to Forth who
mentioned he did not have an easy time finding what he wanted to learn?
Incidentally I am neither a Hahvahd guy nor an MIT guy. As
far as those institutions are concerned, I am just someone who
walks in off the street to use the facilities they provide to
the public to learn about science and technology. And they
provide many resources for this purpose. In ancient times I saw
Forth textbooks for sale in both the MIT and the Harvard U. bookstores.
> > As a result, he's pretty out of touch with real-world
> > computing (particularly the state of the art in the Forth
> > community -- he's working on some impressions from 20 years
> > ago).
>
> It is very strange for *you* to make this claim. Mike has a
> far broader perspective than you. Forth is a tiny corner of a
> broad world about which you know very little.
>
> The Forth Mike knows about is the Forth that invited
> astronomers to use it, before the mainstream Forths became so
> complex and obfuscated that only specialists find them usable.
I'm going to try to avoid getting too involved in new Forth,
old Forth, and mainstream obfuscation. Let's leave that to
another day. There is a larger picture that should be seen from
the lack
of new Forth texts at the MIT bookstore and, much more
important, from the MIT, Harvard and other college libraries. It
is a sign that no professor is assigning Forth to his students
and few academic researchers think they need to know about Forth
for current work. This has nothing to do with weather I think
ANS Forth is better or worse than the Forth of twenty years ago
(altho the Forth texts of twenty years ago are in the college
libraries). I think it is a sign that Forth is only of interest
to the generation of programmers who are about to retire. Now
there is nothing to prevent someone in touch with the real-world
to change this situation and maybe that will happen real-soon-now.
Richard Owlett
> My ambition is to be a renaissance man whose interests
> cannot be neatly pigeonholed. Lets say for the sake of argument
> that ...
Full of sound and ....
Macbeth in "Macbeth" Act 5, Scene 5
m-coughlin
>
> Elizabeth D. Rather wrote:
> > "John Doty" <j...@whispertel.LoseTheH.net> wrote in message
> > news:41EC84AE...@whispertel.LoseTheH.net...
> >
> >>Elizabeth D. Rather wrote:
> >>
[snip]
> > I do know quite a lot about the Forth world,
>
> *ANS* Forth world.
>
> > and Mike makes a lot of extremely ill-informed statements
> > about it.
>
> Mike's statements are about Forth, not ANS Forth.
>
> > My statement was that he's out of touch with the state
> > of art in the Forth community -- I stand by that.
>
> *ANS* Forth community.
>
> > He hasn't read the books that are available today, nor used
> > contemporary Forth systems, nor even followed closely what
> > their capabilities are.
>
> Could it be that *ANS* Forth isn't what he is interested in?
>
> > Actually, the feedback we get from our customers is that our
> > current products are far simpler and easier for the user than
> > the products of 20 years ago.
>
> Comparing your products to your products says nothing about the
> state of Forth in general. Your customers are also not
> representative of the applications community in general. Mike
> is an excellent case of someone who has used and appreciated
> Forth, but has been ill served by ANS Forth. Behind him there
> are many, many more who have simply given up on Forth. You
> know nothing of these people.
While I try to be perfectly clear, my intentions are not
always met. I've noticed by looking over the shoulder of several
very active Forth programmers, that not only do they do things
very differently but they each think their ways of working are
much better than the ways of other Forth programmers. Since I
have not written my own Forth version and used Forth so much
that my personal system has become a conditioned reflex, I think
I might be able to comment on the good and bad points of other
people's Forth methods without bias. Of course I am frequently contradicted.
I do not know much about the latest products from Elizabeth
and Forth, Inc. I would be very interested in attending the next
marketing presentation Forth Inc. makes in the Boston area. But
I would rather learn more about the many small versions of Forth
that are constantly being written. The next big improvement to
Forth could be done with a small public domain system just as
easily as with a big system supported and sold by a software
company. After all Forth was invented by just one man working on
his own.
It is difficult to look out of our own little rut and see
the big picture of the whole computer industry. Forth can be
used for all of computer science; so far it has only been used
for a small part. Lets not get so involved with the differences
between ANS Forth and the other kinds that we don't worry why
there are so many programmers who use C and its relatives
instead of the much better ways to program that every version of
Forth has.
Bill Spight
> Any given problem has a certain intrinsic level of complexity. In the
> solution of the problem, this complexity will be conserved:
Alexander's cutting of the Gordian knot provides a counterexample.
OC, some may not see that as a solution. ;-)
Best regards,
Bill
Bernd Paysan
Or it was the intrinsic complexity that a knot can only connect two ropes,
and therefore the cutting of the knot is the simplest solution to
disconnect the two ropes (IMHO, it would be even simpler to cut one of the
ropes going to the knot, not the big knot itself).
On the other hand, Alexander's cutting of the Gordian knot proofs that he
tends to violence as "solution".
Problems have intrinsic complexity that you can't avoid. Solutions have both
essential complexity (that of the problem), which you can't avoid, and
accidental complexity (of the solution) that you can avoid.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Albert van der Horst
Bill Spight <bsp...@pacbell.net> wrote:
>Dear Elizabeth,
>
>> Any given problem has a certain intrinsic level of complexity. In the
>> solution of the problem, this complexity will be conserved:
>
>Alexander's cutting of the Gordian knot provides a counterexample.
Not at all. It was an example where the complexity was absent,
from the point of a ruthless ruler.
>OC, some may not see that as a solution. ;-)
I do.
>
>Best regards,
>
>Bill
Albert van der Horst
<robert.sp...@gmail.com> wrote:
>
>Albert van der Horst wrote:
>
>> If you are serious... Bernd Paysan has mentioned this before.
>> There is no good open source OCR program. There is a gocr, but it is
>> crap. Now there is a killer. I know pretty well how it should be
>> structured, I have put some thoughts into it. Bernd Paysan has made
>> some remarks too. With the recent success of a community effort to
>get
>> Thinking Forth availability, we just might ...
>
>You are right, that is an interesting project. However way beyond my
>means at present ;) I've yet to prove to myself I can write practical
>code in forth - hey I have YET to learn it properly.
You overestimate the project. And probably you underestimate the
support you can get. And overlook that in a project you
don't have to do, know, understand everything.
The first go would be like this.
You build a test file. This means printing a page of simple
English text into a graphical image in a fixed font.
You find horizontal separators with no black,
presumably separating lines.
Within a line, you find vertical separators with no black,
presumably separating characters.
You pass the rectangles to me.
I find out which rectangles contain the same characters.
A caesar cipher results.
I pass the caesar cipher to Bernd Paysan.
Bernd cracks the caesar cipher using an English dictionary
and his Markov chains.
Once we have ocr-ed our first page, a dozen beople jump on board.
Adding a simple backtrack mechanism makes this very powerful.
Backtrack is Bernd saying: "I want r and n here, not m.
Can you make that two blocks instead of one?".
After inspecting the rectangles you gave me, I can assure
Bernd that it is reasonable to consider those like r and n.
<SNIP>
>
>Cheers
>
>Rob
>
P.S. May I suggest Enid Blyton, Five on Kirrin England again,
Chapter George makes a hard choice. The page starting with 'Oh Quentin..
and ending with the indignated remark of (Georg(in)a's father
that he wouldn't waste his talents on working a "new atom bomb"..
Always start with children books.
Michael Park
Albert van der Horst wrote:
> I find out which rectangles contain the same characters.
> A caesar cipher results.
Interesting idea, but it's not a Caesar cipher.
Albert van der Horst
>> I find out which rectangles contain the same characters.
>> A caesar cipher results.
>
>Interesting idea, but it's not a Caesar cipher.
Of course. It is one of the codes easily cracked, but it is
called replacement cipher, or some such, not Caesar cipher.
Anyway, I'm sure Bernd can handle it, if he wants to start
on this project.
--
Groetjes Albert
Bernd Paysan
> Of course. It is one of the codes easily cracked, but it is
> called replacement cipher, or some such, not Caesar cipher.
> Anyway, I'm sure Bernd can handle it, if he wants to start
> on this project.
Actually, I think that the separation of text into single letters and trying
to match them (the classical OCR approach) is the problem, not the
solution. I'd rather have a simplified strokes protocol and try to match
that than single identified letters. For all lower case letters, you
basically have three classes:
[bdfhklt][iacemnorsuvwxz][gjpqy] This gives the "picture" of the word (the i
dot is small enough to be filtered out). Searching for the first word above
("actually") gives the following list (using /usr/share/dict/words as
starting point, with 45k words):
actually
ardently
intently
modestly
mutually
radially
reliably
ritually
robustly
silently
unkindly
valuably
For short words, this is even easier. Take "the":
flu
the
If we now count strokes, we can exclude even more words. "a" has a
noticeable stroke in the middle, as well as s, so from the first letter, we
can reduce the above list to
actually
ardently
silently
which already have an obvious similar picture. We notice the same obvious
middle horizontal stroke on the next a, and the missing middle stroke on
the l following it, which makes it obvious that we have an "actually" here,
and nothing else. Same with "flu" vs. "the": both the l/h and u/e have
sufficient differences in the strokes to see which is the word we'll have
there.
Note that grepping for a word with characters, as I did now to illustrate
the principle, is only an illustration, not the real thing. The middle
class "[iacemnorsuvwxz]" would not have i (one vertical stroke) and
"m" (three vertical strokes) together.
C. G. Montgomery
> ...
> If we now count strokes, we can exclude even more words. "a" has a
> noticeable stroke in the middle, as well as s, so from the first letter,
> we can reduce the above list to
This is how a Chinese-English dictionary is arranged. After learning a
bit about how how Chinese characters are written, even someone like me
who knows essentially no Chinese can find a character by looking it up
under the number of strokes used to write it.
cgm
Anton Ertl
>
> On 13 Jan 05 at group /comp/lang/forth in article
> <2005Jan1...@mips.complang.tuwien.ac.at>
> <an...@mips.complang.tuwien.ac.at> (Anton Ertl) wrote:
>
>>For the general critique, here it is:
>>
>> 6.1. How can I read and post to comp.lang.forth?
>>
>> The usual way is to use a newsreader and an NNTP server. If your
>
>Please change all "an NNTP" to "a NNTP"
When you pronounce "NNTP Server", it starts with a vowel. That's why
I write "an NNTP Server", and I believe that is correct.
Anyway, thanks for the feedback.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.complang.tuwien.ac.at/forth/ansforth/forth200x.html
Bruce McFarling
Anton Ertl wrote:
> >Please change all "an NNTP" to "a NNTP"
> When you pronounce "NNTP Server", it starts with a vowel. That's why
> I write "an NNTP Server", and I believe that is correct.
> Anyway, thanks for the feedback.
This is a localism that the author must believe is a
universal rule. Because of the confusion between
"an" and "en" in some but not all English language
accents, it is not uncommon to stress the "a",
pause, then spell out. What you cite is the general
rule, and I get the vague impression its used
consistantly for abbreviations, acronyms and normal
words in the British Isles. But I seem to dimly recall
that back in the American midwest that I heard the
"always use 'a' before abbreviations" rule from
somewhere.
Oddly enough, in this case you may be hoist on your
own petard, as it could have been the heavy German
immigration of the latter 1700's and early 1800's
that helped flatten American english vowels and
led to the, "was that 'an NNTP' or 'NNNTP'?"
problem.
IOW, I18N always complicates things.
Richard Owlett
As a native "Upstate New York American English" speaker, "a NNTP" would
be correct. I believe it would also also be preferred in Mid-west (
specifically SW corner of rural ( cows, hogs, poultry out number homo sap.))
CAVEAT: my accent can be localized to within less than 20 miles.
Michael Park
If you pronounce NNTP "en-en-tee-pee", then "an NNTP" is correct.
If you say "nuh-nuh-tup" or somesuch, then use "a NNTP".
I'm pretty sure most people use the first pronunciation, so
I'm with Anton.
http://alt-usage-english.org/excerpts/fxaanbef.html
Albert van der Horst
Wolfgang Allinger <a...@business.kbbs.org> wrote:
>
> On 13 Jan 05 at group /comp/lang/forth in article
> <2005Jan1...@mips.complang.tuwien.ac.at>
> <an...@mips.complang.tuwien.ac.at> (Anton Ertl) wrote:
>
>>For the general critique, here it is:
>>
>> 6.1. How can I read and post to comp.lang.forth?
>>
>> The usual way is to use a newsreader and an NNTP server. If your
>
>Please change all "an NNTP" to "a NNTP"
Please change the subject line. This has nothing to do with OCR.
<SNIP>
>Wolfgang
Albert van der Horst
Bernd Paysan <bernd....@gmx.de> wrote:
>Albert van der Horst wrote:
>> Of course. It is one of the codes easily cracked, but it is
>> called replacement cipher, or some such, not Caesar cipher.
>> Anyway, I'm sure Bernd can handle it, if he wants to start
>> on this project.
>
>Actually, I think that the separation of text into single letters and trying
>to match them (the classical OCR approach) is the problem, not the
>solution.
That is not what I propose. I want the text separated -- preliminary --
in boxes that probably contains characters, then separate them in
equivalence classes that are "similar". Based on the confidence all
levels have in a solution, this division is reconsidered, which
may lead to reexamination of the original color high resolution
image, or zooming in and taking a better picture. Or just to an
alternative that is equally likely by one layer, and vastly more
probable by another.
>I'd rather have a simplified strokes protocol and try to match
>that than single identified letters. For all lower case letters, you
>basically have three classes:
>
>[bdfhklt][iacemnorsuvwxz][gjpqy] This gives the "picture" of the word (the i
>dot is small enough to be filtered out). Searching for the first word above
>("actually") gives the following list (using /usr/share/dict/words as
>starting point, with 45k words):
I have no problem with starting out with three equivalence classes.
Actually this solves a problem that I saw: the middle layer doing
too much work up front, without it knowing whether it is any good.
But there will be a time that you have to come back to the
middle layer and say:
"I have subdivided your classes into this character set. Where do you find
anomalies?"
"I have this t and that t. Do you find it reasonable that this is
the same character?"
"I have this n and you put it in the f-class. I would rather have
it in the n-class. What do you think?"
In the end we must be able to recognize "atcually" being mis-spelled
and the only italic word in the text. And a blood stain half over the
t.
<EXAMPLE SNIPPED>
>--
>Bernd Paysan
>"If you want it done right, you have to do it yourself"
>http://www.jwdt.com/~paysan/
--
Jerry Avins
...
> When you pronounce "NNTP Server", it starts with a vowel. That's why
> I write "an NNTP Server", and I believe that is correct.
I believe so too.
jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Elizabeth D Rather
"Wolfgang Allinger" <all...@gmx.de> wrote in message
news:9QyxL6t67...@gmx.de...
>
> On 14 Feb 05 at group /comp/lang/forth in article
> <ibxek...@spenarnc.xs4all.nl>
> <alb...@spenarnc.xs4all.nl> (Albert van der Horst) wrote:
>
>>Wolfgang Allinger <a...@business.kbbs.org> wrote:
>>> <an...@mips.complang.tuwien.ac.at> (Anton Ertl) wrote:
>>>
>>>>For the general critique, here it is:
>>>Please change all "an NNTP" to "a NNTP"
>
>>Please change the subject line. This has nothing to do with OCR.
>
>
> thread and therefor is not good practice.
Then perhaps it's time to either start a new thread or refrain from posting
an irrelevant message in the current one.
John A. Peters
>>
>>>Please change the subject line. This has nothing to do with OCR.
>>
>>
>> I've been told, that changing subject lines too often will tear the
>> thread and therefor is not good practice.
>
> Then perhaps it's time to either start a new thread or refrain from
> posting an irrelevant message in the current one.
>
> Cheers,
> Elizabeth
I make a motion:
On other forums the problem of posts drifting off topic is handled by a
volunteer
who is active and knowledgeable in the subject being discussed in the
thread.
That person keeps the thread on the subject that matches the subject line by
moving off topic subject matter to a new thread.
As he does so, the volunteer notifies the readers by posting a message in
the place previously occupied by the off-subject post.
Typically that message states something like -
"The message posted by so-and-so has been moved to new-thread-name."
I make a motion that Elizabeth start a new thread and move the
off topic message(s) and post a link at the old location that points to the
new
thread.
Is thee a second to the motion?
I think we will find all will be happy at the improvement.
John A. Peters
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005
Howard Lee Harkness
>I make a motion that Elizabeth start a new thread and move the
>off topic message(s) and post a link at the old location that points to the
>new thread.
>Is thee a second to the motion?
I move that *you* do all the work.
Speaking as the moderator of another newsgroup, there are some things which just
don't have enough return value for time spent.
--
Howard Lee Harkness, Texas Licensed Insurance Agent
http://www.hlhins.com
John A. Peters
Subject: I see your move and raise you...
> "John A. Peters" <jape...@pacbell.net> wrote:
>
>>I make a motion that Elizabeth start a new thread and move the
>>off topic message(s) and post a link at the old location that points to
>>the
>>new thread.
>
>>Is there a second to the motion?
>
> I move that *you* do all the work.
>
> Speaking as the moderator of another newsgroup, there are some things
> which just
> don't have enough return value for time spent.
I amend my motion:
WHEREAS:
1) It shall be ok to start a new thread and move
off topic message(s) there & post a link at the
old location to point to the new thread.
2) The above 'work' shall be encouraged,
and can be performed by any one who has the
time and energy to do it, along with enough
knowledge of the subject matter in the thread
to be a reasonable judge of the off/on topic.
3) When the above work is performed it will be
appreciated by the rest of us in the CLF group
as we will be able to judge a thread by it's subject line.
Submitted in earnest, and looking for
a second to the motion by:
andr...@littlepinkcloud.invalid
> WHEREAS:
> 1) It shall be ok to start a new thread and move
> off topic message(s) there & post a link at the
> old location to point to the new thread.
It's impossible. This is Usenet, not some BBS.
The only way you _might_ be able to do it is with forged cancels or
supersedes, but a) this is likely to get your account cancelled, and
b) it won't work because many news providers don't honour cancels
anyway.
Andrew.