On Sunday, October 1, 2023 at 5:41:31 AM UTC+2, Hugh Aguilar wrote:
> On Saturday, September 30, 2023 at 2:39:46 PM UTC-7, Hans Bezemer wrote:
> > On Thursday, September 28, 2023 at 5:32:29 AM UTC+2, Hugh Aguilar wrote:
> > > On Monday, September 25, 2023 at 3:37:20 AM UTC-7, Hans Bezemer wrote:
> > > https://groups.google.com/g/comp.lang.forth/c/GOPs3a_OtJk/m/DQBjLUJ0BwAJ
> > > I'm surprised that Hans Bezemer would provide a link to that thread.
> > > In it I was pointing out that he doesn't know what Harvard Architecture is,
> > > but he teaches the subject in his instructional videos.
> > > I would expect him to be ashamed of this and not want it mentioned.
> > > He thinks that segmented memory is Harvard Architecture! That is dumb!
> > ... use generally accepted definitions and
> > concepts. That doesn't leave an impression of a raving lunatic
> Hans Bezemer doesn't know what Harvard Architecture is. That is dumb!
> He is ashamed of his failure to understand the accepted definition and
> concept of Harvard Architecture --- this is why he resorts to ad hominem
> attacks against me.

What's dumb is that you use your own definition. That's not how science works.
What's dumb is that you think that the most elaborate algorithm is the best
choice in all situations. What's dumb is that you don't do your research. What's
dumb is seeking validation through narcicism. It doesn't work, Hugh.

Hans Bezemer

On 1/10/2023 5:47 pm, Hans Bezemer wrote:
> On Sunday, October 1, 2023 at 5:41:31 AM UTC+2, Hugh Aguilar wrote:
>> On Saturday, September 30, 2023 at 2:39:46 PM UTC-7, Hans Bezemer wrote:
>>> On Thursday, September 28, 2023 at 5:32:29 AM UTC+2, Hugh Aguilar wrote:
>>>> On Monday, September 25, 2023 at 3:37:20 AM UTC-7, Hans Bezemer wrote:
>>>> https://groups.google.com/g/comp.lang.forth/c/GOPs3a_OtJk/m/DQBjLUJ0BwAJ
>>>> I'm surprised that Hans Bezemer would provide a link to that thread.
>>>> In it I was pointing out that he doesn't know what Harvard Architecture is,
>>>> but he teaches the subject in his instructional videos.
>>>> I would expect him to be ashamed of this and not want it mentioned.
>>>> He thinks that segmented memory is Harvard Architecture! That is dumb!
>>> ... use generally accepted definitions and
>>> concepts. That doesn't leave an impression of a raving lunatic
>> Hans Bezemer doesn't know what Harvard Architecture is. That is dumb!
>> He is ashamed of his failure to understand the accepted definition and
>> concept of Harvard Architecture --- this is why he resorts to ad hominem
>> attacks against me.
>
> What's dumb is that you use your own definition. That's not how science works.
> What's dumb is that you think that the most elaborate algorithm is the best
> choice in all situations. What's dumb is that you don't do your research. What's
> dumb is seeking validation through narcicism. It doesn't work, Hugh.

They don't make narcissists like they used to - a person who could pull
miracles from thin air despite all the odds and critics. Today it's a
blame game - a long list of reasons as to why stuff didn't get done.

On Sunday, October 1, 2023 at 6:59:36 AM UTC+2, dxf wrote:
> On 1/10/2023 2:29 pm, Hugh Aguilar wrote:
> >
> > My other point that I was making is that ANS-Forth is badly designed
> > because single and double precision numbers are mixed together
> > on the same stack --- this results in very convoluted stack juggling.
> > The obvious solution is to have a separate stack for double precision
> > numbers. This was obvious in 1994.
> Not obvious to anyone AFAIK. Hopefully you patented it before sharing.

I don't know if a separate stack helps much - but I do support more distinction
between single and double numbers. In the standard there are a few core words
that do require a double word input or output. They do stand out like a pig in a
dog show IMHO. In 4tH no such words exist. They're confined to double word
libraries (yes, even <# # #> are single words in 4tH - with a double word equivalent).

I hardly ever used double words. I once did a few IBAN programs which required
triple words - but that's about it. However, once I tackled floating point - yes, there
I needed the extended precision of double words - and that's where they came in.

Nowadays, with 64bit becoming the norm I don't know why one would want or
need double words for ordinary integer programs. The range is so huge that
double numbers are hardly ever needed to get the job done. Even "Brody math"
(fixed point calculation) has become a viable option for many applications. I've
even experimented with the concept in my "integer only" uBasic.

https://sourceforge.net/p/forth-4th/code/HEAD/tree/trunk/4th.src/apps/basic/fraction.bas

Hans Bezemer

On 2/10/2023 12:33 am, Hans Bezemer wrote:
> ...
> Nowadays, with 64bit becoming the norm I don't know why one would want or
> need double words for ordinary integer programs. The range is so huge that
> double numbers are hardly ever needed to get the job done.

I'd have thought 'a u' strings would be more common than double numbers.
My programming is 16-bits. Even there doubles don't figure prominently.
Perhaps the nearest thing to a 'double number' app I've written is this:

https://pastebin.com/2SXTZ1Fq

Is it readable? TBH I'm not even sure what folks are looking for when
they use the term. I can glance at a program and get a sense of whether
it's well written - but without studying it I wouldn't lay claim to be
able to read it.

On Sunday, October 1, 2023 at 3:33:13 PM UTC+2, Hans Bezemer wrote:
[..]
> Nowadays, with 64bit becoming the norm I don't know why one would want or
> need double words for ordinary integer programs. The range is so huge that
> double numbers are hardly ever needed to get the job done.

A double number does not have enough bits to convert an extended precision
float (80-bits). ISTR it was not enough to convert a 64bit float, either.

-marcel

On Saturday, September 30, 2023 at 11:47:45 PM UTC-7, Hans Bezemer wrote:
> On Sunday, October 1, 2023 at 5:41:31 AM UTC+2, Hugh Aguilar wrote:
> > On Saturday, September 30, 2023 at 2:39:46 PM UTC-7, Hans Bezemer wrote:
> > > On Thursday, September 28, 2023 at 5:32:29 AM UTC+2, Hugh Aguilar wrote:
> > > > On Monday, September 25, 2023 at 3:37:20 AM UTC-7, Hans Bezemer wrote:
> > > > https://groups.google.com/g/comp.lang.forth/c/GOPs3a_OtJk/m/DQBjLUJ0BwAJ
> > > > I'm surprised that Hans Bezemer would provide a link to that thread..
> > > > In it I was pointing out that he doesn't know what Harvard Architecture is,
> > > > but he teaches the subject in his instructional videos.
> > > > I would expect him to be ashamed of this and not want it mentioned.
> > > > He thinks that segmented memory is Harvard Architecture! That is dumb!
> > > ... use generally accepted definitions and
> > > concepts. That doesn't leave an impression of a raving lunatic
> > Hans Bezemer doesn't know what Harvard Architecture is. That is dumb!
> > He is ashamed of his failure to understand the accepted definition and
> > concept of Harvard Architecture --- this is why he resorts to ad hominem
> > attacks against me.

> What's dumb is that you use your own definition. That's not how science works.

The problem with comp.lang.forth is cult behavior.
Hans Bezemer has been making those instructional videos for decades
in which he says that his 4TH for the x86 is Harvard Architecture.
He is making the entire Forth community appear to be abysmally ignorant!
Nobody on comp.lang.forth ever tells him that he is not using the accepted
definition of Harvard Architecture --- that he doesn't understand the concept.
This is cult behavior! Hans is relying on political correctness --- on c.l.f.
that mostly means attacking me with insults --- so long has he continues
to be politically correct by c.l.f. standards, he gets to continue to post
these hilariously stupid instructional videos and nobody on c.l.f. will
point out that he is making the Forth community look stupid.
This cult behavior on c.l.f. is why the whole world thinks that the Forth
community is stupid --- Hans is indirectly supporting the C community.

> What's dumb is that you think that the most elaborate algorithm is the best
> choice in all situations.

I think Hans is referring to the fact that my STRING-STACK.4TH uses
COW (copy-on-write). This allows stack-juggling of the string-stack
to be done by moving pointers rather than entire strings. The string doesn't
get copied unless it is written to. For example, in DUP$ .$ the DUP$ doesn't
copy the string because .$ is a consumer (it prints out the string and then drops
it from the string-stack) so it just uses the pointer to the string that is on the
string-stack then drops that pointer leaving the pointer that DUP$ copied.

I never said that the "that the most elaborate algorithm is the best choice
in all situations." I did say that my STRING-STACK.4TH is far superior to
any of the pathetic attempts at writing a string-stack that the self-proclaimed
Forth experts (including Hans Bezemer) have made since the time when
Forth was invented in the 1970s and the need for a string-stack became apparent.

> What's dumb is that you don't do your research.

I admit that I didn't do any research on the subject of Forth string-stacks
prior to writing STRING-STACK.4TH. What would I research??? This was one
of the many cases in which I wrote software that had never been done before..
I had never heard of COW (copy-on-write) at that time, so I invented it myself.
Only later on c.l.f. somebody told me that what I had was COW, so I looked
up COW on Wikipedia and realized that this was true --- I wasn't surprised
that this technique had already been invented and had a name (COW)
because it is a pretty obvious technique (I figured out the concept with
about ten minutes of thought before I began writing code, then it took
me weeks of work to get STRING-STACK.4TH to where it is now).

Another example of me writing software that had never been done before
is when I wrote the MFX assembler for the MiniForth. I did not research
the subject of out-of-ordering although I was vaguely aware of the concept
from programming the Pentium that does out-of-ordering at runtime.
John Hart didn't even about the concept of out-of-ordering, so he
never told me to do out-of-ordering --- I just saw the need myself.
I figured out the algorithm for out-of-ordering myself. My assembler
did the out-of-ordering at compile-time, so it was easier to do than on the
Pentium in which it is done by the processor at run-time. OTOH, the MiniForth
has five fields to out-of-order, whereas the Pentium only has two pipelines
(U and V) to out-of-order. The MiniForth was not similar to the Pentium
so researching the Pentium wouldn't have helped me. There was nothing
similar to the MiniForth that I could have researched. This is why I never
do any research --- I'm always writing code for which nothing similar
has ever been written.

> What's dumb is seeking validation through narcicism. It doesn't work, Hugh.

I still don't know what Hans is talking about.
The concept of "validation" implies an external authority that does the
validating --- for comp.lang.forth this mostly means the Forth-200x
committee --- I don't recognize any external authority being above me,
so I'm not seeking validation. Juergen Pintaske thinks that I need
validation from some association of plumbers in England to work
as a plumber in America. Born parasites such as Juergen Pintaske
are very focused on the concept of validation from an external
authority because they don't have any pride of accomplishment due to
not having any accomplishments --- they can only attach themselves
like parasites to somebody who does have accomplishments.

Stephen Pelc says that anybody can implement a better string-stack
than I did, although he doesn't have any working code (he has a
vague story about how some anonymous African implemented a
far superior string-stack 30 years ago, but there is no evidence
to indicate that he or the African know what COW is).
I'm not getting any validation from the Forth-200x committee!
Peter Knaggs banned me from the Forth-200x mailing list saying that
I know nothing about Forth and have nothing to offer on the subject.
Later on Peter Knaggs went to EuroForth with an article intended to
educate the Forth community on the subject of linked lists:
https://groups.google.com/g/comp.lang.forth/c/cMa8wV3OiY0/m/INBDVBh0BgAJ
Peter Knaggs failed to write any working code, and his article was a
jumble of nonsense. He doesn't know what inheritance is. He thinks
that a linked list and an array are the same thing. He knows as much
about linked lists as Hans Bezemer knows about Harvard Architecture,
which is nothing --- but he wants to be teacher! --- this is why the
Forth community has a reputation for stupidity in the real world.

On Sunday, October 1, 2023 at 6:33:13 AM UTC-7, Hans Bezemer wrote:
> Nowadays, with 64bit becoming the norm I don't know why one would want or
> need double words for ordinary integer programs. The range is so huge that
> double numbers are hardly ever needed to get the job done. Even "Brody math"
> (fixed point calculation) has become a viable option for many applications. I've
> even experimented with the concept in my "integer only" uBasic.

When I was trying to hoist a Forth standard I said that it should assume a
64-bit processor, but it should also assume a 32-bit address space.
The data-stack would contain 64-bit numbers with unity fixed at 2^32.
The integer part can be a pointer. IIRC, I called these: "pseudo-floats."
They are similar to floats in that they have an integer part and a fractional
part, but they have a limited range (floats have a truly gigantic range).
The pseudo-floats should be about twice the speed of x87 floats.
For many applications this limited range would not be a problem.
My own interest is in CAD/CAM (generating gcode for CNC machines),
and these pseudo-floats have adequate range for that.

Ilya Tarasov was very unimpressed by my idea. He needs the gigantic
range of floats for his programs dealing with nuclear physics.
He doesn't care about anything so mundane as CAD/CAM and CNC.
He didn't seem to understand that I was NOT saying that this Forth
standard would work for 100% of all Forth programs (they way that
Elizabeth Rather says that ANS-Forth works for 100% of all Forth
programs, from 8-bit microcontrollers up to 64-bit desktop computers).
I don't claim that my standard is for microcontrollers at all.
As for desktop-computers, it is only for modern computers that have
a 64-bit processor, not for retro computers with 16-bit or 32-bit processors.
As for desktop-computers with 64-bit processors, I would be happy
if it worked for 95% of the programs --- these would mostly be
programs for mundane applications such as CAD/CAM --- if users
are writing advanced-level code for a nuclear reactor then they
are already past my level so they shouldn't expect me to provide
anything more than a basis to work from (I could provide a
code-library for double-precision IEEE-754 as an extension but
I would need help with a lot of the transcendentals because that
kind of math is really above my level).

I think that a Forth standard that is adequate for 95% of the
Forth programs written on desktop computers is a reasonable goal.
The ANS-Forth committee claimed that ANS-Forth would be
adequate for 100% of all Forth programs from 8-bit microcontrollers
up to 64-bit desktop work-stations. In actuality, ANS-Forth was not
useful at all for microcontrollers and was marginally useful (some
non-standard extensions needed ) for maybe 10% of desktop programs.
ANS-Forth was mostly useless due to having abundant ambiguities
and general stupidity of design --- it is not the basis for anything.

On 2/10/2023 3:05 am, Marcel Hendrix wrote:
> On Sunday, October 1, 2023 at 3:33:13 PM UTC+2, Hans Bezemer wrote:
> [..]
>> Nowadays, with 64bit becoming the norm I don't know why one would want or
>> need double words for ordinary integer programs. The range is so huge that
>> double numbers are hardly ever needed to get the job done.
>
> A double number does not have enough bits to convert an extended precision
> float (80-bits). ISTR it was not enough to convert a 64bit float, either.

Can you be more specific? In representing 80-bit floats I didn't use doubles
at all.

On 2/10/2023 3:12 am, Hugh Aguilar wrote:
> On Saturday, September 30, 2023 at 11:47:45 PM UTC-7, Hans Bezemer wrote:
>> What's dumb is seeking validation through narcicism. It doesn't work, Hugh.
>
> I still don't know what Hans is talking about.
> The concept of "validation" implies an external authority that does the
> validating

Testra gave you a bad reference [allegedly]. Lack of validation. When
nobody ran with the Novice pack - lack of validation. Humans are forever
seeking validation - from peers, bosses, subordinates - it hardly matters.

On Sunday, October 1, 2023 at 6:23:41 PM UTC-7, dxf wrote:
> On 2/10/2023 3:12 am, Hugh Aguilar wrote:
> > On Saturday, September 30, 2023 at 11:47:45 PM UTC-7, Hans Bezemer wrote:
> >> What's dumb is seeking validation through narcicism. It doesn't work, Hugh.
> >
> > I still don't know what Hans is talking about.
> > The concept of "validation" implies an external authority that does the
> > validating
> Testra gave you a bad reference [allegedly]. Lack of validation. When
> nobody ran with the Novice pack - lack of validation. Humans are forever
> seeking validation - from peers, bosses, subordinates - it hardly matters..

Go away.

In article <588ebab4-e980-487d-94b4-5aaf356d81b2n@googlegroups.com>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>On Sunday, October 1, 2023 at 6:59:36 AM UTC+2, dxf wrote:
>> On 1/10/2023 2:29 pm, Hugh Aguilar wrote:
>> >
>> > My other point that I was making is that ANS-Forth is badly designed
>> > because single and double precision numbers are mixed together
>> > on the same stack --- this results in very convoluted stack juggling.
>> > The obvious solution is to have a separate stack for double precision
>> > numbers. This was obvious in 1994.
>> Not obvious to anyone AFAIK. Hopefully you patented it before sharing.
>
>I don't know if a separate stack helps much - but I do support more distinction
>between single and double numbers. In the standard there are a few core words
>that do require a double word input or output. They do stand out like a pig in a
>dog show IMHO. In 4tH no such words exist. They're confined to double word
>libraries (yes, even <# # #> are single words in 4tH - with a double word
>equivalent).

It is not a good idea to have meaning of words changed.
In competition with jonesforth (loosely based on ciforth) I made
yourforth intended to be as simple as possible.
I have introduced the <% % %> to be single equivalents, and
leave the possibility to load <# # #> lateron.

>
>I hardly ever used double words. I once did a few IBAN programs which required
>triple words - but that's about it. However, once I tackled floating point
>- yes, there
>I needed the extended precision of double words - and that's where they came in.
>
>Nowadays, with 64bit becoming the norm I don't know why one would want or
>need double words for ordinary integer programs. The range is so huge that
>double numbers are hardly ever needed to get the job done. Even "Brody math"
>(fixed point calculation) has become a viable option for many applications. I've
>even experimented with the concept in my "integer only" uBasic.
>
>https://sourceforge.net/p/forth-4th/code/HEAD/tree/trunk/4th.src/apps/basic/fraction.bas

Double precision comes in handy for math problems like projecteuler.net.
>
>Hans Bezemer
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Monday, October 2, 2023 at 11:48:30 AM UTC+2, none albert wrote:
> >In 4tH no such words exist. They're confined to double word
> >libraries (yes, even <# # #> are single words in 4tH - with a double word
> >equivalent).
> It is not a good idea to have meaning of words changed.
> In competition with jonesforth (loosely based on ciforth) I made
> yourforth intended to be as simple as possible.
> I have introduced the <% % %> to be single equivalents, and
> leave the possibility to load <# # #> lateron.

You know - I may even agree with you. However, you have to view that
decision in the light there were NO double words in 4tH at all. So I
decided to do it anyways and make S>D and D>S dummies so the resulting
code was almost always portable.

And like I said - double words have always been library stuff on 4tH. Plus
they are only used in very specific situations (like float). So it has never really
bitten me actually. The FPIN and FPOUT libs use <D# D# #D> words from the
DBLSHARP library.

So, in short - while I subscribe to your idea that it's not a good idea to redefine
(standard) words this one produced the least of my problems in my experience.

I've made other choices (compared to ANS-Forth) in regard to BEGIN..WHILE..REPEAT,
booleans, string, I/O and DO..LOOP that caused far more headaches when trying
to port a program to or from ANS-Forth.

So, where <#, # and #> are concerned - I'm pretty happy with them.

Hans Bezemer

On Sunday, October 1, 2023 at 6:12:13 PM UTC+2, Hugh Aguilar wrote:
> I think Hans is referring to the fact that my STRING-STACK.4TH uses
> COW (copy-on-write). This allows stack-juggling of the string-stack
> to be done by moving pointers rather than entire strings.
So what? That's not rocket science. You make a dynamic string from my
DSTRINGT package, put the address on a user stack (STACK). Add some stack
juggling words - done. Yes, you got no fancy COW.

> I never said that the "that the most elaborate algorithm is the best choice
> in all situations." I did say that my STRING-STACK.4TH is far superior to
> any of the pathetic attempts at writing a string-stack that the self-proclaimed
> Forth experts (including Hans Bezemer) have made since the time when
> Forth was invented in the 1970s and the need for a string-stack became apparent.

Technically, let's assume STRING-STACK.4TH is superior to any other solution. But
you've got to import NOVICE, LIST and STRING-STACK to get it working. And what do
I got then? A string stack. What does it do? It stores a few strings. Let's assume it's
much faster (which I doubt, considering the massive amount of code it takes). How
much time is that gonna shave off the user experience:

$ time pp4th -x foosblbd.4pp
Student
Scientist
Student
Student
Scientist
Student
Student
Scientist
Student
Scientist

real 0m0,035s
user 0m0,021s
sys 0m0,005s

... and that's including compilation and execution. So - explain to me: what is the
endusers net benefit to this MASSIVE amount of extra code? Note the ENTIRE
preprocessor itself is a little over 20K source.

That, Hugh is the reason why I think this is well deserved:

"What's dumb is that you think that the most elaborate algorithm is the best
choice in all situations".

Hans Bezemer

https://sourceforge.net/p/forth-4th/code/HEAD/tree/trunk/4th.src/lib/dstringt.4th
https://sourceforge.net/p/forth-4th/code/HEAD/tree/trunk/4th.src/lib/stack.4th

On Monday, October 2, 2023 at 3:30:14 AM UTC-7, Hans Bezemer wrote:
> I subscribe to your idea that it's not a good idea to redefine
> (standard) words
> ...
> So, where <#, # and #> are concerned - I'm pretty happy with them.

ANS-Forth was designed for the PDP-11.
As I mentioned before, the lack of a double-stack was due to
Charles Moore not having an available register to use as the
double-stack pointer.
Another weakness of the PDP-11 is that it only addressed 64KB
of memory, that had to contain the compiler, the RTOS, and the
application program. This is why PolyForth for the 8086 used only
64KB (all segment registers set the same) --- PolyForth for the 8086
was just a line-by-line port of Charles Moore's PDP-11 Forth.

The assumption of having only 64KB total is why ANS-Forth lacks
a circular buffer for strings (UR/Forth had this). There wasn't enough
memory available, so <# #> used a static buffer for strings. This is stupid!
If you have a string from <# #> you have to manually store it somewhere
before you can do another <# #> or it will get over-written. Also, you
can't nest <# #> within each other. Anybody who claims to be "pretty happy"
with <# #> in the post-PDP-11 era (after 1982) is utterly incompetent.
Anybody who says that it is not a good idea to redefine ANS-Forth words
is a disgusting little sycophant of Elizabeth Rather --- not a Forth programmer!

In the novice-package I rewrote almost all of the ANS-Forth standard words.
I have a circular buffer for strings that WORD and <# #> etc. use. The user can
also generate his own strings concatenating many strings together. The buffer
is pretty big (because post-PDP-11 computers have a lot of memory) so it takes
a while for it to circle around and over-write strings --- it is not for permanent
storage of strings, but it holds strings long enough for multiple strings to be
generated and concatenated in various ways. Later on I wrote STRING-STACK.4TH
that is does pattern-matching, string-extraction and string construction.
STRING-STACK.4TH largely obsoletes the circular string-buffer.

Note that in the waning days of the PDP-11 there was a version with
bank-switching, but this was clunky in the usual clunky way of bank-switching
and was not competitive with the i8086 or MC68000 --- too little to late!

Note also that it was Raimond Dragomir who helped me get the
nesting of buffer-string generation to work smoothly --- I had that
feature, but in a clunky way --- he improved my code.
I'm willing to give Raimond Dragomir credit for his contribution to the
novice-package because he is not a typical maintenance programmer
who makes one minor contribution and then tries to take credit for
the entire package claiming to be far superior to the original programmer.
He is the only person on c.l.f. who is honorable in this way.

On Monday, October 2, 2023 at 4:18:15 AM UTC-7, Hans Bezemer wrote:
> Let's assume [STRING-STACK.4TH] is much faster [than Hans' string-stack
> that moves entire strings around]
> (which I doubt, considering the massive amount of code it takes).
> ...
> That, Hugh is the reason why I think this is well deserved:
> "What's dumb is that you think that the most elaborate algorithm is the best
> choice in all situations".

I think that Hans Bezemer should get a job at Testra!
He and John Hart think alike!
Testra would finally have found the "team player" that they have always wanted!

John Hart wrote a simulator for microprocessor code. He was using the
8086 SCASB instruction with REPZ to search his table for matching opcodes.
I said that a binary search would be faster. He said no, using the same
kind of thinking that Hans Bezemer uses. To paraphrase:
"I doubt that a binary search would be faster than a sequential search
considering the massive amount of code that it takes. You always want to
use the most elaborate algorithm --- this is beyond my comprehension!"

This was discussed in this thread:
https://groups.google.com/g/comp.lang.forth/c/s-6k_wdyrlE/m/tgZJ37jFAwAJ
Actually, "discussed" isn't the correct word because John Hart never
defended his use of a sequential search instead of a binary search.

On Saturday, May 13, 2023 at 1:43:34 PM UTC-7, Hugh Aguilar wrote:
> On Friday, May 12, 2023 at 3:53:36 PM UTC-7, John Hart wrote:
> > Something more compact and efficient than a CASE statement was
> > needed for defining logic equations in the FPGA4th system.
> > The solution was a set of words to build a look up table.
> >
> > key MAP[ n \ begins the process of building the table.
> > a b MAP \ associates a with b
> > c d MAP \ associates c with d
> > e ]MAP \ ends the look up table process
> > note: n specifies the key size (2^n) 0 = 1 byte, 1 = 2 bytes, 2 = 4 bytes
> >
> > At runtime, if the key = a, b is returned, if the key isn't found, e is returned
> >
> > Two more words to complete the set.
> > a ]: starts compilation of code associated with a
> > ;[ ends compilation
> >
> > : ALU { a b cmd - - c } \ example
> > cmd MAP[ 1
> > O ]: a b + ;[ MAP \ add
> > 1 ]: a b - ;[ MAP \ sub
> > 2 ]: a b AND ;[ MAP \ and
> > 3 ]: a b OR ;[ MAP \ or
> > ]: 0 ;[ ]MAP
> > EXECUTE
> > ;
> >
> > jrh
> Way back in 1994 you told me that you had a super-fast jump-table look-up
> that could be used for simulating a processor. You recommended that I use
> this to simulate the MiniForth. You were using a sequential look-up!!!
> I pointed out that a binary search would be much faster. You said that what
> you had was "super fast" because the 8086 has an instruction that does
> a sequential search on a 16-bit number. That was dumb! A binary search is
> still going to be faster, except possibly for a very small array of numbers.
>
> My FAST-SWITCH> (a jump table) and SLOW-SWITCH> (a sorted array and
> a binary search) is posted here:
> https://groups.google.com/g/comp.lang.forth/c/HwxAddZ54mg/m/Fmg5xT08AAAJ
> I'm far ahead of you.
> Your MAP[ mentioned above is what you had in 1994. It wasn't any good then either.
>
> What is your point in posting on comp.lang.forth???
> You don't have anything to offer.

On Monday, October 2, 2023 at 6:41:09 PM UTC+2, Hugh Aguilar wrote:
> On Monday, October 2, 2023 at 3:30:14 AM UTC-7, Hans Bezemer wrote:
> Also, you
> can't nest <# #> within each other. Anybody who claims to be "pretty happy"
> with <# #> in the post-PDP-11 era (after 1982) is utterly incompetent.

That, Hugh is the reason why I think this is well deserved: "What's dumb is
that you think that the most elaborate algorithm is the best choice in all situations".

As a matter of fact, that whole thing bugged me once. In all those years

> Anybody who says that it is not a good idea to redefine ANS-Forth words
> is a disgusting little sycophant of Elizabeth Rather --- not a Forth programmer!

You know you will have to support that proposition with some proper arguments.
First, you will have to define what a Forth programmer is. I don't think you will
come up with a widely accepted definition - unless it's an extensional one like:

"The only Forth programmer is Hugh". But I don't think you can get away with
that one - only if it were for the simple reason that the guy who invented it wasn't
called Hugh.

Second, I guess in order to be a "little sycophant of Elizabeth Rather"
you will have to prove some kind of relationship to Elizabeth Rather and quite
a number of other people - which are largely unknown to you. So I guess you
won't meet any juridical standards here. Sorry, that argument is moot as well.

Remains that it may or may not be a good idea to redefine ANS-Forth words.

Well, it depends. There is always a trade-off. On one hand, you might get the
behavior you want - which is nice. On the other hand, porting code is not that
easy. As a guy who added half a novel to his manual to point out all the differences
I think I have some experience in that regard - and hence are better equipped to
point out the advantages and disadvantages than most others.

Hans Bezemer

On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
> John Hart wrote a simulator for microprocessor code. He was using the
> 8086 SCASB instruction with REPZ to search his table for matching opcodes..
> I said that a binary search would be faster. He said no, using the same
> kind of thinking that Hans Bezemer uses. To paraphrase:
> "I doubt that a binary search would be faster than a sequential search
> considering the massive amount of code that it takes. You always want to
> use the most elaborate algorithm --- this is beyond my comprehension!"

It depends on the number of opcodes you have to search. I spend a chapter
in my manual explaining it. The fastest is of course direct access - where the
thing to search is an index to a table.

If you can't do that, CASE..ENDCASE may be your friend. I found a binary search
paying off after about 100 entries - but not before. So a sequential search can
be faster in some cases. Just test it. "Meten is weten".

In the uBasic/4tH interpreter I used just about any technique in the book to speed
it up.

Hans Bezemer

On 02/10/2023 18:33, Hans Bezemer wrote:
> On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
>> John Hart wrote a simulator for microprocessor code. He was using the
>> 8086 SCASB instruction with REPZ to search his table for matching opcodes.
>> I said that a binary search would be faster. He said no, using the same
>> kind of thinking that Hans Bezemer uses. To paraphrase:
>> "I doubt that a binary search would be faster than a sequential search
>> considering the massive amount of code that it takes. You always want to
>> use the most elaborate algorithm --- this is beyond my comprehension!"
>
> It depends on the number of opcodes you have to search. I spend a chapter
> in my manual explaining it. The fastest is of course direct access - where the
> thing to search is an index to a table.

>
> If you can't do that, CASE..ENDCASE may be your friend. I found a binary search
> paying off after about 100 entries - but not before. So a sequential search can
> be faster in some cases. Just test it. "Meten is weten".
>

A binary search tree (BST) should be faster than a binary search because
when searching, getting to the next node for comparison of keys is
simpler. A BST, at node i only has to calculate 2*i to go left or 2*i+1
to go right.

An example can be seen at:
https://github.com/gerryjackson/Forth-switch/blob/master/lib/bst.fth

--
Gerry

On 3/10/2023 3:41 am, Hugh Aguilar wrote:
> On Monday, October 2, 2023 at 3:30:14 AM UTC-7, Hans Bezemer wrote:
>> I subscribe to your idea that it's not a good idea to redefine
>> (standard) words
>> ...
>> So, where <#, # and #> are concerned - I'm pretty happy with them.
>
> ANS-Forth was designed for the PDP-11.
> As I mentioned before, the lack of a double-stack was due to
> Charles Moore not having an available register to use as the
> double-stack pointer.

Do you have a reference for that beyond "It's obvious"? Have you
done a cost/benefit analysis? You've blown the smoke-rings, now
let's have the data.

> Another weakness of the PDP-11 is that it only addressed 64KB
> of memory, that had to contain the compiler, the RTOS, and the
> application program. This is why PolyForth for the 8086 used only
> 64KB (all segment registers set the same) --- PolyForth for the 8086
> was just a line-by-line port of Charles Moore's PDP-11 Forth.

Forth Inc ported to many machines. They claim to have had the first
high-level language running on the 8086 when the part was still buggy.
When did you release your first forth for the PC?

On Monday, October 2, 2023 at 10:33:55 AM UTC-7, Hans Bezemer wrote:
> On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
> > John Hart wrote a simulator for microprocessor code. He was using the
> > 8086 SCASB instruction with REPZ to search his table for matching opcodes.
> > I said that a binary search would be faster. He said no, using the same
> > kind of thinking that Hans Bezemer uses. To paraphrase:
> > "I doubt that a binary search would be faster than a sequential search
> > considering the massive amount of code that it takes. You always want to
> > use the most elaborate algorithm --- this is beyond my comprehension!"
> It depends on the number of opcodes you have to search. I spend a chapter
> in my manual explaining it. The fastest is of course direct access - where the
> thing to search is an index to a table.
>
> If you can't do that, CASE..ENDCASE may be your friend. I found a binary search
> paying off after about 100 entries - but not before. So a sequential search can
> be faster in some cases. Just test it. "Meten is weten".
>
> In the uBasic/4tH interpreter I used just about any technique in the book to speed
> it up.
>
> Hans Bezemer

I meant SCASW not SCASB --- these were 16-bit opcodes --- not even John Hart
is so incompetent that he would use a sequential search for 8-bit opcodes
in which the sparse jump-table is only 256 words.

"The fastest is of course direct access -
where the thing to search is an index to a table."

Thank you very much, Captain Obvious!

In my novice-package I have FAST-SWITCH> that uses a sparse jump-table
and SLOW-SWITCH> that uses a compacted jump-table with a
binary-search look-up.
Now, thanks to our Forth instructor Hans, we know what the names imply!
In that thread mentioned previously I provided the documentation for
my <SWITCH code:
https://groups.google.com/g/comp.lang.forth/c/s-6k_wdyrlE/m/tgZJ37jFAwAJ

In article <f0710b94-647c-4563-b613-696e8038e1f6n@googlegroups.com>,
Hugh Aguilar <hughaguilar96@gmail.com> wrote:
>On Monday, October 2, 2023 at 10:33:55 AM UTC-7, Hans Bezemer wrote:
>> On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
>> > John Hart wrote a simulator for microprocessor code. He was using the
>> > 8086 SCASB instruction with REPZ to search his table for matching opcodes.
>> > I said that a binary search would be faster. He said no, using the same
>> > kind of thinking that Hans Bezemer uses. To paraphrase:
>> > "I doubt that a binary search would be faster than a sequential search
>> > considering the massive amount of code that it takes. You always want to
>> > use the most elaborate algorithm --- this is beyond my comprehension!"
>> It depends on the number of opcodes you have to search. I spend a chapter
>> in my manual explaining it. The fastest is of course direct access -
>where the
>> thing to search is an index to a table.
>>
>> If you can't do that, CASE..ENDCASE may be your friend. I found a
>binary search
>> paying off after about 100 entries - but not before. So a sequential
>search can
>> be faster in some cases. Just test it. "Meten is weten".
>>
>> In the uBasic/4tH interpreter I used just about any technique in the
>book to speed
>> it up.
>>
>> Hans Bezemer
>
>I meant SCASW not SCASB --- these were 16-bit opcodes --- not even John Hart
>is so incompetent that he would use a sequential search for 8-bit opcodes
>in which the sparse jump-table is only 256 words.

In an assembler it is worth it using hash codes.
There are tools to generate a perfect hash... if you are after speed.

Groetjes Albert

>Hugh
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Tuesday, October 3, 2023 at 9:20:51 AM UTC+2, Hugh Aguilar wrote:

> In my novice-package I have FAST-SWITCH> that uses a sparse jump-table
> and SLOW-SWITCH> that uses a compacted jump-table with a
> binary-search look-up.
> Now, thanks to our Forth instructor Hans, we know what the names imply!
> In that thread mentioned previously I provided the documentation for
> my <SWITCH code:

Well, you don't need massive libs to do all that. You can do it just as well with
a page of code. I mean - you can even program a binary search recursive. I even
like it better when tables are exposed - rather than hidden behind an ugly
CASE..ENDCASE variant.

---8<---
_binarySearch Param(3) ' value, start index, end index
Local(1) ' The middle of the array

If c@ < b@ Then ' Ok, signal we didn't find it
Return (-1)
Else
d@ = SHL(b@ + c@, -1) ' Prevent overflow (LOL!)
If a@ < @(d@) Then Return (FUNC(_binarySearch (a@, b@, d@-1)))
If a@ > @(d@) Then Return (FUNC(_binarySearch (a@, d@+1, c@)))
If a@ = @(d@) Then Return (d@) ' We found it, return index!
EndIf
---8<---

As a matter of fact - I only introduced that CASE construct when I found out there are
situations where this is the fastest way to go. I *actually* did some timings - and
when doing a string table of less than 25 elements, sequential search is on average
faster. After that - sure, binary search rulez.

I haven't found a situation where sequential search beats CASE..ENDCASE in case
of integers. Up to a hundred elements, CASE..ENDCASE wins head down. And yes,
afterwards it's binary search all the way.

And yes, direct access is faster. However, it's not always obvious how you can use
that technique. E.g. this is a table that answers such a question rather than to compute it:

offset delimiters \ precalculated responses
0 c, 0 c, 0 c, 1 c, 0 c, 1 c, 0 c, 0 c, \ 32 - 39
1 c, 1 c, 1 c, 1 c, 1 c, 1 c, 0 c, 1 c, \ 40 - 47
0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, \ 48 - 55
0 c, 0 c, 0 c, 1 c, 1 c, 1 c, 1 c, 0 c, \ 56 - 63
0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, \ 64 - 71
0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, \ 72 - 79
0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, \ 80 - 87
0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 1 c, \ 88 - 94
\ EQUALS +-*^/%=;(),<>#

I even got a lightning fast integer factorial function that is based on the same technique.
I don't need a Hug(h|e) SWITCH library to do all that for me.

Hans Bezemer

On Tuesday, October 3, 2023 at 2:01:05 AM UTC-7, none albert wrote:
> In an assembler it is worth it using hash codes.
> There are tools to generate a perfect hash... if you are after speed.

I'm talking about the simulator that looks up opcodes.
Albert van der Horst says "assembler" --- he may be confused
about what the topic of discussion is. I'm not talking about
the symbol table --- try to be more alert!

People are always telling me what I should do,
although they have done nothing.

A binary search, as I have in SLOW-SWITCH>, has predictable speed.
It is easy to calculate the worst-case speed (the maximum number
of comparisons), and the worst-case is not much worse than the
best-case. Consistency is more important than average speed
in a simulator because you may want to simulate the target processor
running at a certain Mhz., and simulate each instruction's speed
consistent to how many clock-cycles it takes on the target processor.
A hash-table could be used in a simulator, but it would be difficult
to predict the worst-case speed (a collision followed by a long
sequential search).

The hallmark of a script kiddie is to always say:
"there are tools available to generate perfect code..."
These tools might be generating a pile of crap. How do you know?
To get a good hash function there has to be an exploitable
bit-pattern in the values that you are running through your hash function.
In a simulator, these values are 32-bit opcodes. There may not be an
exploitable bit-pattern. If there is, it is going to be different for
every target processor. My novice-package is general-purpose code.
My SLOW-SWITCH> should work reasonably well on any target processor
so I'm happy with it --- of course, Elizabeth Rather hated the concept
of general-purpose code and said that a custom-written solution
is always better (certainly it is always more time-consuming and
error-prone to write).

As a practical matter, I don't care that much anyway. I am only interested
in 16-bit target processors, so I use FAST-SWITCH> every time --- the limit
for FAST-SWITCH> is 64K so it works for 16-bit opcodes and the table
is small enough (256KB) to easily fit on a modern desktop computer.

> First gain is a cat spinning. - the Wise from Antrim -

I still have no idea what this means.
It seems like pseudo-intellectual nonsense --- roughly comparable to
the nonsense that DXforth spouts --- the problem with comp.lang.forth
is too much cat-spinning and not enough code-writing.

In article <9176e0ac-11b5-4048-b3e6-c671ea59467bn@googlegroups.com>,
Hugh Aguilar <hughaguilar96@gmail.com> wrote:
>On Tuesday, October 3, 2023 at 2:01:05 AM UTC-7, none albert wrote:
>> In an assembler it is worth it using hash codes.
>> There are tools to generate a perfect hash... if you are after speed.
>
>I'm talking about the simulator that looks up opcodes.
>Albert van der Horst says "assembler" --- he may be confused
>about what the topic of discussion is. I'm not talking about
>the symbol table --- try to be more alert!
>
>People are always telling me what I should do,
>although they have done nothing.
>
>A binary search, as I have in SLOW-SWITCH>, has predictable speed.
>It is easy to calculate the worst-case speed (the maximum number
>of comparisons), and the worst-case is not much worse than the
>best-case. Consistency is more important than average speed
>in a simulator because you may want to simulate the target processor
>running at a certain Mhz., and simulate each instruction's speed
>consistent to how many clock-cycles it takes on the target processor.
>A hash-table could be used in a simulator, but it would be difficult
>to predict the worst-case speed (a collision followed by a long
>sequential search).

You are not paying attention. A perfect hash is O(1) time.

<Senseless insults snipped>

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Tuesday, 3 October 2023 at 5:20:51 pm UTC+10, Hugh Aguilar wrote:
> On Monday, October 2, 2023 at 10:33:55 AM UTC-7, Hans Bezemer wrote:
> > On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
> > > John Hart wrote a simulator for microprocessor code. He was using the

> > Hans Bezemer
> I meant SCASW not SCASB --- these were 16-bit opcodes --- not even John Hart
> is so incompetent that he would use a sequential search for 8-bit opcodes
> in which the sparse jump-table is only 256 words.
> "The fastest is of course direct access -
> where the thing to search is an index to a table."
> Thank you very much, Captain Obvious!

Hugh, for my home computer like chip I originally aimed to use 8 bit codes as the upper bits of the address space, which is ok in simple tasks. I am expanded this to multiple 8 bit spaces, and 16 bits etc and other sophisticated schemes into something new. But, I prefered 10 and 20 bits.