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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)