Here's a simple check to see what your Forth system does when M*/ is
given arguments which will overflow a double length result. The standard
states that this is an ambiguous condition.

: ipow ( n u -- d ) 1 s>d rot 0 ?DO 2 pick 1 m*/ LOOP rot drop ;

65 21 ipow d.
117809547936177440979200839996337890625 ok \ result ok (64-bit system)

65 22 ipow d.
Floating point exception (core dumped) \ kForth-64 (since last commit)

65 raised to the power of 22 will overflow the double number result on a
64-bit system and crash on kForth-64. Prior to my recent patch it would overflow silently and print an incorrect result.


In kForth, a SIGFPE handler may be installed as shown in the example sigfpe.4th.

include sigfpe
\ ...
65 22 ipow d.
Floating point exception
Line 16: VM Error(-258): Return stack corrupt
65 22 ipow d.
ok \ returns to the Forth prompt


To be clear there is no floating point operation involved in IPOW as
defined above, but the exception generated for integer division overflow
for a double length number divided by a single length number generates
SIGFPE on linux.

--
Krishna

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

Good to have a choice. The now standardised big integer
wrap-around behaviour in Forth can indeed cause difficulties.

The other way is to use a small bignum library eg libtommath.
(afaik Python uses fat GMP)

MicroPython v1.19.1 on 2022-11-05; win32 [GCC 6.3.0] version
Use Ctrl-D to exit, Ctrl-E for paste mode

pow(65,21)

117809547936177440979200839996337890625

pow(65,22)

7657620615851533663648054599761962890625

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

On 7/10/24 06:55, minforth wrote:

Good to have a choice. The now standardised big integer
wrap-around behaviour in Forth can indeed cause difficulties.

The Forth 2012 standard for M*/ states an ambiguous condition for a
quotient outside of the range of a double-precision signed number:

8.6.1.1820

M*/ ( d1 n1 +n2 – – d2 )
Multiply d1 by n1 producing the triple-cell intermediate result t.
Divide t by +n2 givingthe double-cell quotient d2 . An ambiguous
condition exists if +n2 is zero or negative, or the quotient lies
outside of the range of a double-precision signed integer.

--
Krishna

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

Why n2 has to be positive is beyond me anyhow.

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

On Sat, 13 Jul 2024 2:03:54 +0000, dxf wrote:

[..]

How many applications have you written requiring a negative divisor?

I note that in the 68 occurrences of M*/ inside about 1900 files,
32 appear as ".. 1 M*/ ..".

-marcel

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

On Sat, 13 Jul 2024 2:03:54 +0000, dxf wrote:

How many applications have you written requiring a negative divisor?

What a silly question.

Even in simple Newtonian physics it is not always possible to define
a reference system that avoids negative values. Let alone in
electrical networks.

The "explanation" that +n2 is there to compensate for the performance
loss of some (old?) CPUs sounds strange in a standard document.

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

On Sat, 13 Jul 2024 8:15:26 +0000, minforth wrote:

Even in simple Newtonian physics it is not always possible to define
a reference system that avoids negative values. Let alone in
electrical networks.

I have never felt the need to use M*/ when solving electrical
networks. Maybe when I finally get to Katzenelson.

-marcel

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

On 7/13/24 02:15, mhx wrote:

On Sat, 13 Jul 2024 2:03:54 +0000, dxf wrote:

[..]

How many applications have you written requiring a negative divisor?

I note that in the 68 occurrences of M*/ inside about 1900 files,
32 appear as ".. 1 M*/ ..".

The use of 1 M*/ just points to a missing factor of M*/ being omitted
from the standard. In kForth, we provide the missing factor:

DS* ( d n -- t )

where t is a signed triple length product. Therefore, 1 M*/ can be
replaced by

DS* drop

and the division can be avoided.

If you need an overflow check, it may be a bit more complicated, though.

--
Krishna

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