Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #135300 > unrolled thread

E.P E. E.EXACT

Back to article view | Back to comp.lang.forth

Contents

  E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-05 18:02 +0000
    Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-06 08:13 -0500
      Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-06 14:00 +0000
        Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-06 10:45 -0500
          Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-06 15:58 +0000
            Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-06 17:20 +0000
          Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-06 21:05 +0200
            Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-06 20:38 +0000
            Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-06 18:44 -0500
            Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-07 11:03 +1000
              Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-07 10:11 +0000
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-08 14:39 +1000
                  Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-08 06:32 +0000
                    Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-09 04:50 +1000
                      Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-10 20:01 +1000
                        Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-10 18:06 +0000
                      Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-10 17:24 +0000
                        Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-11 14:01 +1000
                    Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-10 22:10 -0500
                      Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-11 04:56 +0000
                        Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-11 22:16 -0500
                          Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-12 05:47 -0500
                          Re: E.P E. E.EXACT peter <peter.noreply@tin.it> - 2026-08-12 18:03 +0200
                            Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-12 11:48 -0500
                  Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-08 09:14 +0200
                    Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-08 09:40 +0000
                      Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-08 15:26 +0200
                        Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-10 16:43 +0000
                    Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-09 13:43 +1000
                      Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-09 07:19 +0200
                        Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-10 19:15 +1000
                          Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-10 13:17 +0200
                            Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-10 22:59 +1000
                              Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-10 23:54 +1000
                              Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-10 20:42 +0200
                                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-11 17:10 +1000
                                  Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-12 14:04 +1000
                        Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 16:43 +0200
                          Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-22 15:47 +0000
                            Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 18:27 +0200
                              Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-22 16:40 +0000
                                Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 19:42 +0200
                                  Re: E.P E. E.EXACT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-22 18:03 +0000
                                    Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 22:56 +0200
                          Re: E.P E. E.EXACT marcel hendrix <mhx@iae.nl> - 2026-08-23 00:50 +0200
                            Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-23 12:25 +1000
                  Re: E.P E. E.EXACT Hans Bezemer <the.beez.speaks@gmail.com> - 2026-08-09 14:52 +0200
              Re: E.P E. E.EXACT Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-07 07:50 -0500
                Re: E.P E. E.EXACT dxf <dxforth@gmail.com> - 2026-08-08 12:33 +1000
                  Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 17:01 +0200
            Re: E.P E. E.EXACT albert@spenarnc.xs4all.nl - 2026-08-22 16:15 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#135390

albert@spenarnc.xs4all.nl writes:
>In article <2026Aug22.174706@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@spenarnc.xs4all.nl writes:
>>>All floating point numbers are rubbish from a certain point on,
>>
>>Wrong.
>
>I'm talking about the interpretation of an fp.
>
>1.23E5 has an uncertainty of
>0.01E5
>0.02E5
>0.005E5
>and one should keep that in mind.

1.23E5 can be represented exactly as FP number, because it has an
integer value in the range that's covered by FP numbers.  There is no
uncertainty there, except in your head.

If you want to say that an engineer who writes 1.23E5 wants to express
that this number has only two significant digits, that may be the
case, but has nothing to do with FP.

I don't work with significant digits notation, but my impression was
that 1.23E5 would indicate 3 significant digits, i.e., that all shown
mantissa digits are significant.

- 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 2026 CFP: http://www.euroforth.org/ef26/cfp.html

[toc] | [prev] | [next] | [standalone]

#135393

In article <2026Aug22.184005@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl writes:
>>In article <2026Aug22.174706@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>albert@spenarnc.xs4all.nl writes:
>>>>All floating point numbers are rubbish from a certain point on,
>>>
>>>Wrong.
>>
>>I'm talking about the interpretation of an fp.
>>
>>1.23E5 has an uncertainty of
>>0.01E5
>>0.02E5
>>0.005E5
>>and one should keep that in mind.
>
>1.23E5 can be represented exactly as FP number, because it has an
>integer value in the range that's covered by FP numbers.  There is no
>uncertainty there, except in your head.

I am a physicist. Floating point numbers represent some physical quantity.

>
>If you want to say that an engineer who writes 1.23E5 wants to express
>that this number has only two significant digits, that may be the
>case, but has nothing to do with FP.

It is relevant because it works through with all subsequent calculations.

>
>I don't work with significant digits notation, but my impression was
>that 1.23E5 would indicate 3 significant digits, i.e., that all shown
>mantissa digits are significant.

I use the conventions used for a drawing of parts to be machined.
E.g. for a lathe.

>
>- anton
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#135394

albert@spenarnc.xs4all.nl writes:
>I am a physicist. Floating point numbers represent some physical quantity.

Floating-point numbers represent whatever the programmer who uses them
intends them to represent, and it does not matter whether you are a
physicist.  I have read about people who have used FP for financial
calculations (I would scale money amounts to cents, tenths of cents,
or so to avoid the typical inexactness of values like 0.1e in the
common case, though), and others who have used them for integer
calculations beyond 32-bit numbers.

- 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 2026 CFP: http://www.euroforth.org/ef26/cfp.html

[toc] | [prev] | [next] | [standalone]

#135395

In article <2026Aug22.200338@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl writes:
>>I am a physicist. Floating point numbers represent some physical quantity.
>
>Floating-point numbers represent whatever the programmer who uses them
>intends them to represent, and it does not matter whether you are a
>physicist.  I have read about people who have used FP for financial
>calculations (I would scale money amounts to cents, tenths of cents,
>or so to avoid the typical inexactness of values like 0.1e in the
>common case, though), and others who have used them for integer
>calculations beyond 32-bit numbers.

Financial people should not use inexact numbers. If you are counting
cents, integers are entirely appropriate and there is no inexactness to avoid.

>
>- anton
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#135397

On 8/22/2026 4:43 PM, albert@spenarnc.xs4all.nl wrote:
> In article <11592lt$65r8$1@dont-email.me>, marcel hendrix  <mhx@iae.nl> wrote:
>> On 8/9/2026 5:43 AM, dxf wrote:
>> [..]
>>> Under VFX and DX-Forth 'decimal places' requires F.R ( F. only does
>>> 'significant digits' with trailing zeros truncated).  If one asks for
>>> 200 decimal places it obeys - up to the limit of the HOLD buffer.
>>
>> Is there a use case for that behavior or is it just a feature?
>>
>> I would expect F.R to print the number with more than what PLACES
>> is set to, in order to prevent saving and restoring a user variable.
>> In such a case more than 20 places would be a bit unusual, and one
>> would need to make sure the extra digits are not total rubbish.
> 
> Why?
> All floating point numbers are rubbish from a certain point on,
> and you have to keep track of that yourself.
> 
> 1E2
>   OK
>   100 F.R
>   9.9999999999999999982652765240231929055880755186080932617187500000000000000000000000000000000000000000E1  OK
> 
> Only BASIC programmers don't realize that all fp numbers are inexact,
> e.g. sin(1^100) may make sense in mathematics, but not the FORTRAN
>     X= SIN(1E100)

Sorry, I don't see what point you are making here.

That ' 1E2 100 F.R ' is would definitely not be my intention.

FORTH> help f.r
F.R                 "f-dot-r"                                   IFORTH
      ( n -- ) ( F: r -- )
      Display the floating point number r using the conversion rules as
      for F., right aligned in a field n characters wide. If the number
      of characters required to display r is greater than n, all digits
      are displayed with no leading spaces in a field as wide as
      necessary.
      When the fieldwidth is too small, F.R and its variants try to
      squeeze the number in by switching to exponential notation. When
      that doesn't help, they print a field of asterisks. The switch to
      exponential notation happens when |r| > 10^PRECISION . When |r| <
      10^-PRECISION , "0.00.." is printed.
  2 set-precision  ok
1e2 57  f.r                                                    100.00 ok
1e2 1   f.r * ok
1e2 2   f.r ** ok
1e2 3   f.r *** ok
1e2 4   f.r **** ok
1e2 5   f.r ***** ok
1e2 15  f.r          100.00 ok
1e2  5  f.r ***** ok
1e2 10  f.r     100.00 ok
1e2  6  f.r 100.00 ok
12 set-precision  ok
1e2  6  f.r ****** ok
1e2 16  f.r 100.000000000000 ok
1e2 20  f.r     100.000000000000 ok

-marcel

[toc] | [prev] | [next] | [standalone]

#135398

On 23/08/2026 8:50 am, marcel hendrix wrote:
> On 8/22/2026 4:43 PM, albert@spenarnc.xs4all.nl wrote:
>> In article <11592lt$65r8$1@dont-email.me>, marcel hendrix  <mhx@iae.nl> wrote:
>>> On 8/9/2026 5:43 AM, dxf wrote:
>>> [..]
>>>> Under VFX and DX-Forth 'decimal places' requires F.R ( F. only does
>>>> 'significant digits' with trailing zeros truncated).  If one asks for
>>>> 200 decimal places it obeys - up to the limit of the HOLD buffer.
>>>
>>> Is there a use case for that behavior or is it just a feature?
>>>
>>> I would expect F.R to print the number with more than what PLACES
>>> is set to, in order to prevent saving and restoring a user variable.
>>> In such a case more than 20 places would be a bit unusual, and one
>>> would need to make sure the extra digits are not total rubbish.
>>
>> Why?
>> All floating point numbers are rubbish from a certain point on,
>> and you have to keep track of that yourself.
>>
>> 1E2
>>   OK
>>   100 F.R
>>   9.9999999999999999982652765240231929055880755186080932617187500000000000000000000000000000000000000000E1  OK
>>
>> Only BASIC programmers don't realize that all fp numbers are inexact,
>> e.g. sin(1^100) may make sense in mathematics, but not the FORTRAN
>>     X= SIN(1E100)
> 
> Sorry, I don't see what point you are making here.
> 
> That ' 1E2 100 F.R ' is would definitely not be my intention.
> 
> FORTH> help f.r
> F.R                 "f-dot-r"                                   IFORTH
>      ( n -- ) ( F: r -- )
>      Display the floating point number r using the conversion rules as
>      for F., right aligned in a field n characters wide. If the number
>      of characters required to display r is greater than n, all digits
>      are displayed with no leading spaces in a field as wide as
>      necessary.
>      When the fieldwidth is too small, F.R and its variants try to
>      squeeze the number in by switching to exponential notation. When
>      that doesn't help, they print a field of asterisks. The switch to
>      exponential notation happens when |r| > 10^PRECISION . When |r| <
>      10^-PRECISION , "0.00.." is printed.
>  2 set-precision  ok
> 1e2 57  f.r                                                    100.00 ok
> 1e2 1   f.r * ok
> 1e2 2   f.r ** ok
> 1e2 3   f.r *** ok
> 1e2 4   f.r **** ok
> 1e2 5   f.r ***** ok
> 1e2 15  f.r          100.00 ok
> 1e2  5  f.r ***** ok
> 1e2 10  f.r     100.00 ok
> 1e2  6  f.r 100.00 ok
> 12 set-precision  ok
> 1e2  6  f.r ****** ok
> 1e2 16  f.r 100.000000000000 ok
> 1e2 20  f.r     100.000000000000 ok

I would consider that more an application than a kernel function due to
the number of variables.

[toc] | [prev] | [next] | [standalone]

#135323

On 08-08-2026 06:39, dxf wrote:
In 4tH, several packages are available. For if you want a small one -- 
or a fully ANS compliant one.

Also, two different FP packages are available, one with a shared stack - 
and one with a separate stack. Out of the box, six different 
combinations are supported:

\ Show F. output

8 set-precision

     2 s>f        3 s>f f/ f. cr
20000 s>f        3 s>f f/ f. cr
s" 2e-4" s>float 3 s>f f/ f. cr
1 s>f                     f. cr
10000 s>f                 f. cr
s" 2e-4" s>float          f. cr

FP0 (shared stack, native ZEN fpout package )

Doesn't support SET-PRECISION, without that:

0.6666666666666666666
6666.666666666666666
0.00006666666666666666666
1
10000
0.0002

FP1 (shared stack, native ZEN fpout package)

0.6666666666666666666
6666.666666666666666
0.00006666666666666666666
1
10000
0.0002

FP2 (shared stack, DXF fpout package)

0.66666667
6666.6667
0.000066666667
1.
10000.
0.0002

FP3 (separate stack, native Brad Eckert fpout package)

0.6666666
6666.6666
0.0000666
1.0000000
10000.000
0.0002000

FP4 (separate stack, DXF fpout package)

0.66666667
6666.6667
0.000066666667
1.
10000.
0.0002

FP5 (separate stack, "Simple Floating Point Output" package (unknown))

0.6667
6666.6667
0.0001
1.0000
10000.0000
0.0002

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#135313

On 8/6/26 20:03, dxf wrote:
> On 7/08/2026 5:05 am, marcel hendrix wrote:
>> On 8/6/2026 5:45 PM, Krishna Myneni wrote:
>>> On 8/6/26 09:00, Anton Ertl wrote:
>>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> [..]
>>> E. is useful for finding the shortest decimal input which will convert to the internal representation for a given decimal floating point input. I wonder if there is a more direct way to arrive at that, rather than the iterative procedure.[..]
>>
>> HEX string input and output when the provider and consumer can not communicate in binary, or when the binary formats are not standard IEEE.
>> As FE. and friends are currently 'ambiguous' when BASE is not DECIMAL, it could be done without adding new words. However, >FLOAT might be a problem.
> 
> AFAICS E.EXACT E. are for academics only.  E.P just tells me the minimal
> and ambiguous functions ANS suggested were never going to be enough.  If
> the user can specify a level of precision then 'exact' was never the goal.
> 
> 
Your statement suggests that engineers never need to do numerical 
analysis -- nothing could be further from the truth.

--
Krishna

[toc] | [prev] | [next] | [standalone]

#135314

On 7/08/2026 10:50 pm, Krishna Myneni wrote:
> On 8/6/26 20:03, dxf wrote:
>> On 7/08/2026 5:05 am, marcel hendrix wrote:
>>> On 8/6/2026 5:45 PM, Krishna Myneni wrote:
>>>> On 8/6/26 09:00, Anton Ertl wrote:
>>>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>> [..]
>>>> E. is useful for finding the shortest decimal input which will convert to the internal representation for a given decimal floating point input. I wonder if there is a more direct way to arrive at that, rather than the iterative procedure.[..]
>>>
>>> HEX string input and output when the provider and consumer can not communicate in binary, or when the binary formats are not standard IEEE.
>>> As FE. and friends are currently 'ambiguous' when BASE is not DECIMAL, it could be done without adding new words. However, >FLOAT might be a problem.
>>
>> AFAICS E.EXACT E. are for academics only.  E.P just tells me the minimal
>> and ambiguous functions ANS suggested were never going to be enough.  If
>> the user can specify a level of precision then 'exact' was never the goal.
>>
>>
> Your statement suggests that engineers never need to do numerical analysis -- nothing could be further from the truth.

To my knowledge engineers don't operate at the limits of the systems and
tools they use.  They can't afford to.

[toc] | [prev] | [next] | [standalone]

#135384

In article <6a76958f$1@news.ausics.net>, dxf  <dxforth@gmail.com> wrote:
>On 7/08/2026 10:50 pm, Krishna Myneni wrote:
>> On 8/6/26 20:03, dxf wrote:
>>> On 7/08/2026 5:05 am, marcel hendrix wrote:
>>>> On 8/6/2026 5:45 PM, Krishna Myneni wrote:
>>>>> On 8/6/26 09:00, Anton Ertl wrote:
>>>>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>>> [..]
>>>>> E. is useful for finding the shortest decimal input which will convert to the internal representation for a given
>decimal floating point input. I wonder if there is a more direct way to arrive at that, rather than the iterative
>procedure.[..]
>>>>
>>>> HEX string input and output when the provider and consumer can not communicate in binary, or when the binary formats
>are not standard IEEE.
>>>> As FE. and friends are currently 'ambiguous' when BASE is not DECIMAL, it could be done without adding new words.
>However, >FLOAT might be a problem.
>>>
>>> AFAICS E.EXACT E. are for academics only.  E.P just tells me the minimal
>>> and ambiguous functions ANS suggested were never going to be enough.  If
>>> the user can specify a level of precision then 'exact' was never the goal.
>>>
>>>
>> Your statement suggests that engineers never need to do numerical analysis -- nothing could be further from the truth.
>
>To my knowledge engineers don't operate at the limits of the systems and
>tools they use.  They can't afford to.
>

Example of the contrary:

I had to solve a bug^H^H^Hdefect in a simulation program for electronic
tubes at Philips Matlab. They used interpolation with a 6th degree polynomial.
The electric charge of an electron is ca. 1E-19 Coulomb.
A 6th power does an fp underflow, not signalled by the IBM FORTRAN compiler.
(Chuck Moore use fixed point, always being aware of the magnitude of things.)

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#135382

In article <1152lu4$3788$1@dont-email.me>, marcel hendrix  <mhx@iae.nl> wrote:
>On 8/6/2026 5:45 PM, Krishna Myneni wrote:
>> On 8/6/26 09:00, Anton Ertl wrote:
>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>[..]
>> E. is useful for finding the shortest decimal input which will convert
>> to the internal representation for a given decimal floating point input.
>> I wonder if there is a more direct way to arrive at that, rather than
>> the iterative procedure.[..]
>
>HEX string input and output when the provider and consumer can not
>communicate in binary, or when the binary formats are not standard IEEE.
>As FE. and friends are currently 'ambiguous' when BASE is not DECIMAL,
>it could be done without adding new words. However, >FLOAT might be a
>problem.

It is better to change the exponent sign. I use &_ for base unequal to 10
that gets you to base 64 .

It don't like this behaviour:

Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
12E0  ok
F. 12.  ok
HEX  ok
12E0  ok
. 12E0  ok

>
>-marcel
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.forth

csiph-web