On Friday, September 29, 2023 at 3:03:48 AM UTC-5, dxf wrote:
> On 29/09/2023 2:26 pm, S Jack wrote:
> > On Thursday, September 28, 2023 at 7:41:59 PM UTC-5, dxf wrote:
> >> On 29/09/2023 2:07 am, S Jack wrote:
> >>> On Thursday, September 28, 2023 at 8:09:18 AM UTC-5, dxf wrote:
> >>>> On 28/09/2023 12:04 am, S Jack wrote:
> >>>> But Fig is directly responsible for where Forth is today. Washing
> >>>> its hands of fig-Forth (it had served its purpose we were told),
> >>>> Fig found itself a new role - to facilitate and develop a Forth
> >>>> Standard through the FST (Forth Standards Team). FST gave us
> >>>> Forth-79 and Forth-83. Forth-83 was in turn the basis document
> >>>> of ANS-Forth.
> >>>
> >>> A bad thing?
> >> Apparently. Folks who wanted a language got the beginnings of one
> >> and told to fill the rest out for themselves. Meanwhile Standard
> >> Teams and their helpers indulge themselves looking for wording that
> >> eliminates ambiguity - important in a language whose basis is concept
> >> rather than code.
> >
> > Same size as Pascal, Pl1, assembly, ... etc. Anything more is application.
> In that case there ought to be countless Forth newcomers busily writing
> applications :)

On Friday, September 29, 2023 at 3:03:48 AM UTC-5, dxf wrote:
> On 29/09/2023 2:26 pm, S Jack wrote:
> > On Thursday, September 28, 2023 at 7:41:59 PM UTC-5, dxf wrote:
> >> On 29/09/2023 2:07 am, S Jack wrote:
> >>> On Thursday, September 28, 2023 at 8:09:18 AM UTC-5, dxf wrote:
> >>>> On 28/09/2023 12:04 am, S Jack wrote:
> >>>> But Fig is directly responsible for where Forth is today. Washing
> >>>> its hands of fig-Forth (it had served its purpose we were told),
> >>>> Fig found itself a new role - to facilitate and develop a Forth
> >>>> Standard through the FST (Forth Standards Team). FST gave us
> >>>> Forth-79 and Forth-83. Forth-83 was in turn the basis document
> >>>> of ANS-Forth.
> >>>
> >>> A bad thing?
> >> Apparently. Folks who wanted a language got the beginnings of one
> >> and told to fill the rest out for themselves. Meanwhile Standard
> >> Teams and their helpers indulge themselves looking for wording that
> >> eliminates ambiguity - important in a language whose basis is concept
> >> rather than code.
> >
> > Same size as Pascal, Pl1, assembly, ... etc. Anything more is application.
> In that case there ought to be countless Forth newcomers busily writing
> applications :)

Spoon-fed provides quantity but I much prefer the flavor of
free-range.

--
me

(sorry about that last miss-fire, what designer puts the post button where one is to start typing.)

On Thursday, September 28, 2023 at 2:14:06 PM UTC-7, S Jack wrote:
> Converting one Forth from and to standard forth is just a sed file.
> It's not completely straight forward as sometimes order matters.

You are assuming that all Forth designs are the same as ANS-Forth
except with different names for words or having more words (such as
having BOUNDS be a primitive rather than use OVER + SWAP).
This isn't true though.

ANS-Forth is very much based on Charles Moore's Forth for the
PDP-11 written in the 1970s. The PDP-11 had a shortage of registers
and most of the ANS-Forth design decisions assume a shortage of
registers, although this was no longer an issue in 1994 (it wasn't
an issue in 1983 either, as we already had the MC68000).

For example, a big part of why ANS-Forth code is hard to read
is that single and double-precision numbers are jumbled together
on the same data-stack. A better design is to have a separate stack
for double-precision numbers.
S>D would remove a signed number from the single stack, then
push an equivalent signed double to the double stack.
U>D would be like S>D except for unsigned singles.
M* would multiply two numbers on the single stack
(and remove them), then push the product to the double stack.
UM/MOD would unsigned divide a double on the double stack
by a number on the single stack, then push the remainder and quotient
to the single stack.
SAFE-UM/MOD would unsigned divide a double on the double stack
by a number on the single stack, then push the double-precision
remainder and quotient to the double stack.
etc.

Your SED file isn't going to convert code from a Forth that is
designed intelligently to run under ANS-Forth.

Note also that SAFE-UM/MOD can't be written in ANS-Forth,
despite the fact that it is used internally by # for pictured numbers.
ANS-Forth provides UM/MOD (6.1.2370) but says:
"An ambiguous condition exists if [the denominator] is zero or if
the quotient lies outside the range of a single-cell unsigned integer."
What are you supposed to do if your quotient overflows, which will
happen if you have a small denominator?
What are you supposed to do if your remainder overflows, which will
happen if you have a large denominator?
The ANS-Forth document routinely uses the term "ambiguous condition"
that means: "up Shit Creek in a wire boat with a cardboard paddle."

ANS-Forth is really worthless from a technical standpoint.
ANS-Forth was a marketing gimmick from Elizabeth Rather.

On 30/09/2023 10:32 am, Hugh Aguilar wrote:
> On Thursday, September 28, 2023 at 2:14:06 PM UTC-7, S Jack wrote:
>> Converting one Forth from and to standard forth is just a sed file.
>> It's not completely straight forward as sometimes order matters.
>
> You are assuming that all Forth designs are the same as ANS-Forth
> except with different names for words or having more words (such as
> having BOUNDS be a primitive rather than use OVER + SWAP).
> This isn't true though.
>
> ANS-Forth is very much based on Charles Moore's Forth for the
> PDP-11 written in the 1970s. The PDP-11 had a shortage of registers
> and most of the ANS-Forth design decisions assume a shortage of
> registers, although this was no longer an issue in 1994 (it wasn't
> an issue in 1983 either, as we already had the MC68000).
>
> For example, a big part of why ANS-Forth code is hard to read
> is that single and double-precision numbers are jumbled together
> on the same data-stack. A better design is to have a separate stack
> for double-precision numbers.
> S>D would remove a signed number from the single stack, then
> push an equivalent signed double to the double stack.
> U>D would be like S>D except for unsigned singles.
> M* would multiply two numbers on the single stack
> (and remove them), then push the product to the double stack.
> UM/MOD would unsigned divide a double on the double stack
> by a number on the single stack, then push the remainder and quotient
> to the single stack.
> SAFE-UM/MOD would unsigned divide a double on the double stack
> by a number on the single stack, then push the double-precision
> remainder and quotient to the double stack.
> etc.
>
> Your SED file isn't going to convert code from a Forth that is
> designed intelligently to run under ANS-Forth.
>
> Note also that SAFE-UM/MOD can't be written in ANS-Forth,
> despite the fact that it is used internally by # for pictured numbers.
> ANS-Forth provides UM/MOD (6.1.2370) but says:
> "An ambiguous condition exists if [the denominator] is zero or if
> the quotient lies outside the range of a single-cell unsigned integer."
> What are you supposed to do if your quotient overflows, which will
> happen if you have a small denominator?
> What are you supposed to do if your remainder overflows, which will
> happen if you have a large denominator?
> The ANS-Forth document routinely uses the term "ambiguous condition"
> that means: "up Shit Creek in a wire boat with a cardboard paddle."
>
> ANS-Forth is really worthless from a technical standpoint.
> ANS-Forth was a marketing gimmick from Elizabeth Rather.

Intel ought be ashamed of itself for supporting such flawed operators.

In article <c2cbeb05-8191-4cd5-a015-825bf8624a15n@googlegroups.com>,
Hugh Aguilar <hughaguilar96@gmail.com> wrote:
<SNIP>
>Note also that SAFE-UM/MOD can't be written in ANS-Forth,
>despite the fact that it is used internally by # for pictured numbers.
>ANS-Forth provides UM/MOD (6.1.2370) but says:
>"An ambiguous condition exists if [the denominator] is zero or if
>the quotient lies outside the range of a single-cell unsigned integer."
>What are you supposed to do if your quotient overflows, which will
>happen if you have a small denominator?
>What are you supposed to do if your remainder overflows, which will
>happen if you have a large denominator?
>The ANS-Forth document routinely uses the term "ambiguous condition"
>that means: "up Shit Creek in a wire boat with a cardboard paddle."
>
>ANS-Forth is really worthless from a technical standpoint.
>ANS-Forth was a marketing gimmick from Elizabeth Rather.

Ambiguous means that the system is not obliged to detect the
condition. However a high quality system exists
exist that detects and flags ambiguous conditions.
For example gforth does that for a substantantial part of
ambiguous conditions.

Groetje 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 -

Hugh Aguilar <hughaguilar96@gmail.com> writes:
>SAFE-UM/MOD would unsigned divide a double on the double stack
>by a number on the single stack, then push the double-precision
>remainder and quotient to the double stack.
>etc.
....
>Note also that SAFE-UM/MOD can't be written in ANS-Forth,
>despite the fact that it is used internally by # for pictured numbers.

Gforth has:

: ud/mod ( ud1 u2 -- urem udquot ) \ gforth
\G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
\G quotient @i{udquot} and a single remainder @i{urem}.
over 0= if nip u/mod 0 exit then
dup >r u/mod r> swap >r um/mod r> ;

The first line is just an optimization for the common case where ud1
actually fits into a single cell, and you can delete it.

With a single-cell divisor, the remainder is guaranteed to fit into a
single cell.

>ANS-Forth provides UM/MOD (6.1.2370) but says:
>"An ambiguous condition exists if [the denominator] is zero or if=20
>the quotient lies outside the range of a single-cell unsigned integer."
>What are you supposed to do if your quotient overflows, which will
>happen if you have a small denominator?

UD/MOD first divides the upper cell of ud1 by u2, then the remainder
of that division and the lower cell by u2. Both divisions do not
overflow. Of course, division by 0 is still an ambiguous condition;
you can check for that before performing the division.

>What are you supposed to do if your remainder overflows, which will
>happen if you have a large denominator?

The remainder is always less than the denominator. Therefore, with a
single denominator, the remainder cannot overflow.

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 30/09/2023 7:46 pm, albert wrote:
> In article <c2cbeb05-8191-4cd5-a015-825bf8624a15n@googlegroups.com>,
> Hugh Aguilar <hughaguilar96@gmail.com> wrote:
> <SNIP>
>> Note also that SAFE-UM/MOD can't be written in ANS-Forth,
>> despite the fact that it is used internally by # for pictured numbers.
>> ANS-Forth provides UM/MOD (6.1.2370) but says:
>> "An ambiguous condition exists if [the denominator] is zero or if
>> the quotient lies outside the range of a single-cell unsigned integer."
>> What are you supposed to do if your quotient overflows, which will
>> happen if you have a small denominator?
>> What are you supposed to do if your remainder overflows, which will
>> happen if you have a large denominator?
>> The ANS-Forth document routinely uses the term "ambiguous condition"
>> that means: "up Shit Creek in a wire boat with a cardboard paddle."
>>
>> ANS-Forth is really worthless from a technical standpoint.
>> ANS-Forth was a marketing gimmick from Elizabeth Rather.
>
> Ambiguous means that the system is not obliged to detect the
> condition. However a high quality system exists
> exist that detects and flags ambiguous conditions.
> For example gforth does that for a substantantial part of
> ambiguous conditions.

Why? Does the programmer need to be told the horse in his charge has bolted?

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:
> > On Wednesday, June 16, 2021 at 8:27:07 PM UTC+2, Rod Pemberton wrote:
> > > In other words, Hugh must always see himself as the "King of the Hill",
> > > as royalty, as perfect, and in total control, in regards to all things
> > > Forth. All conflict with Hugh shall be repressed, suppressed, and
> > > oppressed, for Hugh is the King! All hail mighty Hugh!
> > That's true. I can remember a discussion where it was something about
> > "experts". 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!
> > The point that makes him *really* mad is that I neither care about labels nor
> > value being the "biggest ape on the hill". The only metric I find useful is what I
> > can do with what I got upstairs.
> Hans also has an instructional video teaching the subject of implementing
> a string stack, which he doesn't know how to do. His video provided a
> graphical illustration of swapping two strings --- one string gets copied
> into a pad somewhere, then the other string gets copied to where it was,
> then the string in the pad gets copied to where that string was.
> That was an hilarious video! Hans doesn't know what COW (copy-on-write)
> is, or know that it is much faster to just swap the pointers to the strings
> rather than swap the entire strings.
> Hans doesn't have any knowledge "upstairs" --- just a lot of hot air --- what he
> does with what he has upstairs is make hilariously stupid instructional videos.
> > Since he is wired completely differently (he is actually *begging* for validation)
> > it intensely irritates him when somebody is not racing him or giving him kudos
> > for work he finds extremely important and valuable.
> Hans is still not making any sense.
> If I wanted "validation" I would have stayed on the Forth-200x mailing list
> so my super-duper expert status would be validated by the Forth-200x
> committee. Being on the Forth-200x mailing list is essentially the same
> as having reference letters from Stephen Pelc, Anton Ertl, Bernd Paysan,
> Peter Knaggs, etc., that can be used as validation of Forth expertise.
> The whole point of being on the Forth-200x mailing list is so that,
> in the unlikely case that a job in Forth is offered, the candidate can explain
> that he is not just a mere Forth programmer, but he sets the standard for
> the entire Forth community. All Forth programmers rely on the Forth-200x
> experts to do their thinking for them! The Forth-200x committee considers
> them to be the elite whose opinion on Forth is valuable. Woo hoo!
> > It is what it is.. What I do value Hugh for is that he's actually written Forth code -
> > so that alone IMHO justifies him being here
> There was this thread:
> https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/os5OYTOeBAAJ
> Hans said:
>
> On Sunday, February 26, 2023 at 7:37:35 AM UTC-7, Hans Bezemer wrote:
> > But maybe now you understand why I don't care about you, Hugh. Or anything
> > you say about me. Or make me stop what I'm doing. To me, you're just a nobody
> > with a crazy opinion I don't care for.
> >
> > Hans Bezemer
> >
> > BTW, I can rip your NOVICE package till the last byte.
>
> Hans Bezemer appreciates the fact that I have posted Forth source-code
> so he can rip it off (because he can't write Forth source-code himself),
> but he will still continue to fling insults at me while he is ripping off my code.
>
> Hans is a typical maintenance programmer --- they are all alike --- they
> require somebody to write the code, then they rip it off and claim
> that they wrote it themselves. Testra employed a string of maintenance
> programmers after I left who claimed to be instant experts in MFX,
> but all of them failed to learn to program in MFX --- maybe Testra will
> hire Hans Bezemer next, as he seems to be their type.

Hugh, I'm always thankful when you dedicate an entire episode of your
famous rants to me. I know this is very therapeutic for you and I sincerily
hope it contributes to your mental health in anyway.

I know this thread has been hard for you. There are still some cognative
dissonance issues to settle. I know you're convinced to be a very
inventive, clever programmer - but the cold hard truth you slowly start
to accept is that no matter how liberal your license is - if nobody wants
to rip your code, I'd better be a pleasant hobby - and not a profession.
Because that would be delusional.

If I may give you a little advise - use a bit of humor in your roasts! You'll
be much better apppreciated. And use generally accepted definitions and
concepts. That doesn't leave an impression of a raving lunatic - I know
you want to avoid that, so that'll need a little more exercise. But all in all -
funnier than Lilly Singh, so you're on the right track.

I think it's time for your medication now.

Hans Bezemer

On 1/10/2023 8:39 am, 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:
>>> On Wednesday, June 16, 2021 at 8:27:07 PM UTC+2, Rod Pemberton wrote:
>>>> In other words, Hugh must always see himself as the "King of the Hill",
>>>> as royalty, as perfect, and in total control, in regards to all things
>>>> Forth. All conflict with Hugh shall be repressed, suppressed, and
>>>> oppressed, for Hugh is the King! All hail mighty Hugh!
>>> That's true. I can remember a discussion where it was something about
>>> "experts". 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!
>>> The point that makes him *really* mad is that I neither care about labels nor
>>> value being the "biggest ape on the hill". The only metric I find useful is what I
>>> can do with what I got upstairs.
>> Hans also has an instructional video teaching the subject of implementing
>> a string stack, which he doesn't know how to do. His video provided a
>> graphical illustration of swapping two strings --- one string gets copied
>> into a pad somewhere, then the other string gets copied to where it was,
>> then the string in the pad gets copied to where that string was.
>> That was an hilarious video! Hans doesn't know what COW (copy-on-write)
>> is, or know that it is much faster to just swap the pointers to the strings
>> rather than swap the entire strings.
>> Hans doesn't have any knowledge "upstairs" --- just a lot of hot air --- what he
>> does with what he has upstairs is make hilariously stupid instructional videos.
>>> Since he is wired completely differently (he is actually *begging* for validation)
>>> it intensely irritates him when somebody is not racing him or giving him kudos
>>> for work he finds extremely important and valuable.
>> Hans is still not making any sense.
>> If I wanted "validation" I would have stayed on the Forth-200x mailing list
>> so my super-duper expert status would be validated by the Forth-200x
>> committee. Being on the Forth-200x mailing list is essentially the same
>> as having reference letters from Stephen Pelc, Anton Ertl, Bernd Paysan,
>> Peter Knaggs, etc., that can be used as validation of Forth expertise.
>> The whole point of being on the Forth-200x mailing list is so that,
>> in the unlikely case that a job in Forth is offered, the candidate can explain
>> that he is not just a mere Forth programmer, but he sets the standard for
>> the entire Forth community. All Forth programmers rely on the Forth-200x
>> experts to do their thinking for them! The Forth-200x committee considers
>> them to be the elite whose opinion on Forth is valuable. Woo hoo!
>>> It is what it is.. What I do value Hugh for is that he's actually written Forth code -
>>> so that alone IMHO justifies him being here
>> There was this thread:
>> https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/os5OYTOeBAAJ
>> Hans said:
>>
>> On Sunday, February 26, 2023 at 7:37:35 AM UTC-7, Hans Bezemer wrote:
>>> But maybe now you understand why I don't care about you, Hugh. Or anything
>>> you say about me. Or make me stop what I'm doing. To me, you're just a nobody
>>> with a crazy opinion I don't care for.
>>>
>>> Hans Bezemer
>>>
>>> BTW, I can rip your NOVICE package till the last byte.
>>
>> Hans Bezemer appreciates the fact that I have posted Forth source-code
>> so he can rip it off (because he can't write Forth source-code himself),
>> but he will still continue to fling insults at me while he is ripping off my code.
>>
>> Hans is a typical maintenance programmer --- they are all alike --- they
>> require somebody to write the code, then they rip it off and claim
>> that they wrote it themselves. Testra employed a string of maintenance
>> programmers after I left who claimed to be instant experts in MFX,
>> but all of them failed to learn to program in MFX --- maybe Testra will
>> hire Hans Bezemer next, as he seems to be their type.
>
> Hugh, I'm always thankful when you dedicate an entire episode of your
> famous rants to me. I know this is very therapeutic for you and I sincerily
> hope it contributes to your mental health in anyway.
>
> I know this thread has been hard for you. There are still some cognative
> dissonance issues to settle. I know you're convinced to be a very
> inventive, clever programmer - but the cold hard truth you slowly start
> to accept is that no matter how liberal your license is - if nobody wants
> to rip your code, I'd better be a pleasant hobby - and not a profession.
> Because that would be delusional.

Well, licenses in a hobby situation are rather delusional too. Hobbies
are supposed to be about fun - not ownership.

On Saturday, September 30, 2023 at 3:18:24 AM UTC-7, Anton Ertl wrote:
> Hugh Aguilar <hughag...@gmail.com> writes:
> >SAFE-UM/MOD would unsigned divide a double on the double stack
> >by a number on the single stack, then push the double-precision
> >remainder and quotient to the double stack.
> >etc.
> ...
> >Note also that SAFE-UM/MOD can't be written in ANS-Forth,
> >despite the fact that it is used internally by # for pictured numbers.

> Gforth has:
>
> : ud/mod ( ud1 u2 -- urem udquot ) \ gforth

I don't care what you have in gForth. I'll just write my own
mixed-precision division in assembly-language for whatever
Forth I may be using.

My point was that ANS-Forth is a steaming pile of crap.
It was the technical failure of ANS-Forth that killed Forth in 1994.

> With a single-cell divisor, the remainder is guaranteed to fit into a
> single cell.

Yes, I realized this after I posted that message.

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. This requires another register
to be dedicated as the double-stack pointer. Charles Moore didn't
do this because the PDP-11 had a shortage of registers. ANS-Forth
appears to be designed specifically for the PDP-11's limitations,
although the PDP-11 was over a decade obsolete in 1994.

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.

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.

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