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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#135338

On 8/10/26 23:56, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> On 8/8/26 01:32, Anton Ertl wrote:
>>> F. specifies a required ".", but that's missing here.
>>>
>> The only indication in the standard that a trailing "." appears is the
>> example in the appendix; otherwise, my reading of the standard is
>> ambiguous on the trailing decimal point.
> 
> The standard specifies:
> 
> | 12.6.2.1427 F.
> | [...]
> | [-] <digits>.<digits0>
> 
> If they intended the "." to be optional, they would have specified that as
> 
> [-] <digits>[.<digits0>]
> 
>> It should be explicitly stated
>> if the trailing decimal point was the intent.
> 
> It is.
> 

Actually, F. in its present functionality in kForth works for me, 
despite it being non-standard. It provides 6 significant digits of 
output and switches between fixed point and scientific notation to 
produce the shortest output with 6 significant digits. This output is 
useful to me most of the time. The trailing decimal point seems like a 
good idea when it's output is in fixed point format.

When I need control over the number of significant digits displayed, I 
use SET-PRECISION and FS. and when I need fixed point output with a 
fixed number of decimal places, right-justified within a field of 
specified width, I use F.RD (defined in source in strings.4th). These 
three words, "F." "FS." and "F.RD", in their present functionality, have 
met all of my needs up to now.

FS. can print an arbitrary number of digits.

Example:

pad 8 erase
  ok
1 pad !
  ok
800 set-precision
  ok
pad f@ fs.  \ ignore spaces and line breaks in output below
   4.
   940 656 458 412 465 441 765 687 928 682
   213 723 650 598 026 143 247 644 255 856
   825 006 755 072 702 087 518 652 998 363
   616 359 923 797 965 646 954 457 177 309
   266 567 103 559 397 963 987 747 960 107
   818 781 263 007 131 903 114 045 278 458
   171 678 489 821 036 887 186 360 569 987
   307 230 500 063 874 091 535 649 843 873
   124 733 972 731 696 151 400 317 153 853
   980 741 262 385 655 911 710 266 585 566
   867 681 870 395 603 106 249 319 452 715
   914 924 553 293 054 565 444 011 274 801
   297 099 995 419 319 894 090 804 165 633
   245 247 571 478 690 147 267 801 593 552
   386 115 501 348 035 264 934 720 193 790
   268 107 107 491 703 332 226 844 753 335
   720 832 431 936 092 382 893 458 368 060
   106 011 506 169 809 753 078 342 277 318
   329 247 904 982 524 730 776 375 927 247
   874 656 084 778 203 734 469 699 533 647
   017 972 677 717 585 125 660 551 199 131
   504 891 101 451 037 862 738 167 250 955
   837 389 733 598 993 664 809 941 164 205
   702 637 090 279 242 767 544 565 229 087
   538 682 506 419 718 265 533 447 265 625
   000 000 000 000 000 000 000 000 000 000
   000 000 000 000 000 000 0
e-324  ok

There are 751 significant digits, representing 2^-1074. The bit pattern 
is an IEEE double precision *subnormal* number interpreted as 
2^-52*(2^emin), where emin = -1022 is the minimum power of 2 exponent. 
2^-52 is the significand, which is the 1 stored in the lsb of the 
binary64 floating point number.

Wolfram alpha can be used to verify all of the digits printed above.

We should be able to do this arithmetic with the big arithmetic package, 
but I get a segfault because the output buffer is too small, I think. It 
should be fixable.

--
Krishna

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

#135340

On 8/11/26 22:16, Krishna Myneni wrote:
...
> 
> FS. can print an arbitrary number of digits.
> 
> Example:
> 
> pad 8 erase
>   ok
> 1 pad !
>   ok
> 800 set-precision
>   ok
> pad f@ fs.  \ ignore spaces and line breaks in output below
>    4.
>    940 656 458 412 465 441 765 687 928 682
>    213 723 650 598 026 143 247 644 255 856
>    825 006 755 072 702 087 518 652 998 363
>    616 359 923 797 965 646 954 457 177 309
>    266 567 103 559 397 963 987 747 960 107
>    818 781 263 007 131 903 114 045 278 458
>    171 678 489 821 036 887 186 360 569 987
>    307 230 500 063 874 091 535 649 843 873
>    124 733 972 731 696 151 400 317 153 853
>    980 741 262 385 655 911 710 266 585 566
>    867 681 870 395 603 106 249 319 452 715
>    914 924 553 293 054 565 444 011 274 801
>    297 099 995 419 319 894 090 804 165 633
>    245 247 571 478 690 147 267 801 593 552
>    386 115 501 348 035 264 934 720 193 790
>    268 107 107 491 703 332 226 844 753 335
>    720 832 431 936 092 382 893 458 368 060
>    106 011 506 169 809 753 078 342 277 318
>    329 247 904 982 524 730 776 375 927 247
>    874 656 084 778 203 734 469 699 533 647
>    017 972 677 717 585 125 660 551 199 131
>    504 891 101 451 037 862 738 167 250 955
>    837 389 733 598 993 664 809 941 164 205
>    702 637 090 279 242 767 544 565 229 087
>    538 682 506 419 718 265 533 447 265 625
>    000 000 000 000 000 000 000 000 000 000
>    000 000 000 000 000 000 0
> e-324  ok
> 
> There are 751 significant digits, representing 2^-1074. The bit pattern 
> is an IEEE double precision *subnormal* number interpreted as 
> 2^-52*(2^emin), where emin = -1022 is the minimum power of 2 exponent. 
> 2^-52 is the significand, which is the 1 stored in the lsb of the 
> binary64 floating point number.
> 
> Wolfram alpha can be used to verify all of the digits printed above.
> 
> We should be able to do this arithmetic with the big arithmetic package, 
> but I get a segfault because the output buffer is too small, I think. It 
> should be fixable.
> 

Yep, it was a limited output buffer size (256 chars, hardcoded in the 
original version of big.4th). I increased the buffer size, replacing 
references to it in the words that used it with a named constant. This 
fixed the seg fault. The big number arithmetic words can be used to 
print the digits of 2^-1074 as follows.

 From FSL Big Number Arithmetic module
(revised + additional words in big-extras.4th by KM):

5 1074 big_s^n big.  \ 5^1074 = 10^1074/2^1074 = (2^-1074)*10^1074
   4
   940 656 458 412 465 441 765 687 928 682
   213 723 650 598 026 143 247 644 255 856
   825 006 755 072 702 087 518 652 998 363
   616 359 923 797 965 646 954 457 177 309
   266 567 103 559 397 963 987 747 960 107
   818 781 263 007 131 903 114 045 278 458
   171 678 489 821 036 887 186 360 569 987
   307 230 500 063 874 091 535 649 843 873
   124 733 972 731 696 151 400 317 153 853
   980 741 262 385 655 911 710 266 585 566
   867 681 870 395 603 106 249 319 452 715
   914 924 553 293 054 565 444 011 274 801
   297 099 995 419 319 894 090 804 165 633
   245 247 571 478 690 147 267 801 593 552
   386 115 501 348 035 264 934 720 193 790
   268 107 107 491 703 332 226 844 753 335
   720 832 431 936 092 382 893 458 368 060
   106 011 506 169 809 753 078 342 277 318
   329 247 904 982 524 730 776 375 927 247
   874 656 084 778 203 734 469 699 533 647
   017 972 677 717 585 125 660 551 199 131
   504 891 101 451 037 862 738 167 250 955
   837 389 733 598 993 664 809 941 164 205
   702 637 090 279 242 767 544 565 229 087
   538 682 506 419 718 265 533 447 265 625  ok


For comparison, here is the Wolfram alpha output.

 From Wolfram alpha, 2^-1074

   4.
   940 656 458 412 465 441 765 687 928 682
   213 723 650 598 026 143 247 644 255 856
   825 006 755 072 702 087 518 652 998 363
   616 359 923 797 965 646 954 457 177 309
   266 567 103 559 397 963 987 747 960 107
   818 781 263 007 131 903 114 045 278 458
   171 678 489 821 036 887 186 360 569 987
   307 230 500 063 874 091 535 649 843 873
   124 733 972 731 696 151 400 317 153 853
   980 741 262 385 655 911 710 266 585 566
   867 681 870 395 603 106 249 319 452 715
   914 924 553 293 054 565 444 011 274 801
   297 099 995 419 319 894 090 804 165 633
   245 247 571 478 690 147 267 801 593 552
   386 115 501 348 035 264 934 720 193 790
   268 107 107 491 703 332 226 844 753 335
   720 832 431 936 092 382 893 458 368 060
   106 011 506 169 809 753 078 342 277 318
   329 247 904 982 524 730 776 375 927 247
   874 656 084 778 203 734 469 699 533 647
   017 972 677 717 585 125 660 551 199 131
   504 891 101 451 037 862 738 167 250 955
   837 389 733 598 993 664 809 941 164 205
   702 637 090 279 242 767 544 565 229 087
   538 682 506 419 718 265 533 447 265 625
   × 10^-324

--
KM

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

#135341

On Tue, 11 Aug 2026 22:16:56 -0500
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

> On 8/10/26 23:56, Anton Ertl wrote:
> > Krishna Myneni <krishna.myneni@ccreweb.org> writes:
> >> On 8/8/26 01:32, Anton Ertl wrote:
> >>> F. specifies a required ".", but that's missing here.
> >>>
> >> The only indication in the standard that a trailing "." appears is the
> >> example in the appendix; otherwise, my reading of the standard is
> >> ambiguous on the trailing decimal point.
> > 
> > The standard specifies:
> > 
> > | 12.6.2.1427 F.
> > | [...]
> > | [-] <digits>.<digits0>
> > 
> > If they intended the "." to be optional, they would have specified that as
> > 
> > [-] <digits>[.<digits0>]
> > 
> >> It should be explicitly stated
> >> if the trailing decimal point was the intent.
> > 
> > It is.
> > 
> 
> Actually, F. in its present functionality in kForth works for me, 
> despite it being non-standard. It provides 6 significant digits of 
> output and switches between fixed point and scientific notation to 
> produce the shortest output with 6 significant digits. This output is 
> useful to me most of the time. The trailing decimal point seems like a 
> good idea when it's output is in fixed point format.

This is how I just implemented Anton's E. in my system. Precision fixed
at 6 digits, print both F. and FS. to memory and take the shortest 
to print out. I found that to be a useful tool to use interactively.

Peter

> 
> When I need control over the number of significant digits displayed, I 
> use SET-PRECISION and FS. and when I need fixed point output with a 
> fixed number of decimal places, right-justified within a field of 
> specified width, I use F.RD (defined in source in strings.4th). These 
> three words, "F." "FS." and "F.RD", in their present functionality, have 
> met all of my needs up to now.
> 
> FS. can print an arbitrary number of digits.
> 
> Example:
> 
> pad 8 erase
>   ok
> 1 pad !
>   ok
> 800 set-precision
>   ok
> pad f@ fs.  \ ignore spaces and line breaks in output below
>    4.
>    940 656 458 412 465 441 765 687 928 682
>    213 723 650 598 026 143 247 644 255 856
>    825 006 755 072 702 087 518 652 998 363
>    616 359 923 797 965 646 954 457 177 309
>    266 567 103 559 397 963 987 747 960 107
>    818 781 263 007 131 903 114 045 278 458
>    171 678 489 821 036 887 186 360 569 987
>    307 230 500 063 874 091 535 649 843 873
>    124 733 972 731 696 151 400 317 153 853
>    980 741 262 385 655 911 710 266 585 566
>    867 681 870 395 603 106 249 319 452 715
>    914 924 553 293 054 565 444 011 274 801
>    297 099 995 419 319 894 090 804 165 633
>    245 247 571 478 690 147 267 801 593 552
>    386 115 501 348 035 264 934 720 193 790
>    268 107 107 491 703 332 226 844 753 335
>    720 832 431 936 092 382 893 458 368 060
>    106 011 506 169 809 753 078 342 277 318
>    329 247 904 982 524 730 776 375 927 247
>    874 656 084 778 203 734 469 699 533 647
>    017 972 677 717 585 125 660 551 199 131
>    504 891 101 451 037 862 738 167 250 955
>    837 389 733 598 993 664 809 941 164 205
>    702 637 090 279 242 767 544 565 229 087
>    538 682 506 419 718 265 533 447 265 625
>    000 000 000 000 000 000 000 000 000 000
>    000 000 000 000 000 000 0
> e-324  ok
> 
> There are 751 significant digits, representing 2^-1074. The bit pattern 
> is an IEEE double precision *subnormal* number interpreted as 
> 2^-52*(2^emin), where emin = -1022 is the minimum power of 2 exponent. 
> 2^-52 is the significand, which is the 1 stored in the lsb of the 
> binary64 floating point number.
> 
> Wolfram alpha can be used to verify all of the digits printed above.
> 
> We should be able to do this arithmetic with the big arithmetic package, 
> but I get a segfault because the output buffer is too small, I think. It 
> should be fixable.
> 
> --
> Krishna
> 
> 
> 
> 
> 

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

#135342

On 8/12/26 11:03, peter wrote:
> On Tue, 11 Aug 2026 22:16:56 -0500
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
...
>> Actually, F. in its present functionality in kForth works for me,
>> despite it being non-standard. It provides 6 significant digits of
>> output and switches between fixed point and scientific notation to
>> produce the shortest output with 6 significant digits. This output is
>> useful to me most of the time. The trailing decimal point seems like a
>> good idea when it's output is in fixed point format.
> 
> This is how I just implemented Anton's E. in my system. Precision fixed
> at 6 digits, print both F. and FS. to memory and take the shortest
> to print out. I found that to be a useful tool to use interactively.
> 

That sounds fairly easy to implement provided there are internal words 
to output F. and FS. to strings. I suppose one can use REPRESENT to 
implement such words.

Given my implementation of F. which is fixed at 6 significant digits, 
the rationale becomes stronger for a corresponding word such as E. which 
uses PRECISION for the number of significant digits and selects fixed 
point *or* the exponential notation format in which the decimal point 
precedes the decimal digits seems like a good alternative when more (or 
less) significant digits and compact output are desired.

--
Krishna

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

#135317

On 8/8/2026 6:39 AM, dxf wrote:
> 8 set-precision
> 
> 2e   3e f/ f.
> 2e4  3e f/ f.
> 2e-4 3e f/ f.
> 1e         f.
> 1e4        f.
> 1e-4       f.

iForth version 6.9.109, generated 18:39:31, September 27, 2021.

8 set-precision
2e   3e f/ f. 0.66666667
2e4  3e f/ f. 6666.66666667
2e-4 3e f/ f. 0.00006667
1e         f. 1.00000000
1e4        f. 10000.00000000
1e-4       f. 0.00010000

2 set-precision
2e   3e f/ f. 0.67
2e4  3e f/ f. 6666.67
2e-4 3e f/ f. 0.00
1e         f. 1.00
1e4        f. 10000.00
1e-4       f. 0.00
5001e-4    f. 0.50

200 set-precision
2e   3e f/ f. 0.6666666666666666667
2e4  3e f/ f. 6666.6666666666666665186
2e-4 3e f/ f. 0.0000666666666666667
1e         f. 1.0000000000000000000
1e4        f. 10000.0000000000000000000
1e-4       f. 0.0001000000000000000
5001e-4    f. 0.5001000000000000000

What I miss: right-alignment in fixed field, adding +/-/space, 
suppressing trailing zeros, sane behavior when field too small,
engineering/SPICE units, unit arithmetic, HEX/binary output.
My FP programs almost always define a new variant of FP output.

-marcel

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

#135318

marcel hendrix <mhx@iae.nl> writes:
>On 8/8/2026 6:39 AM, dxf wrote:
>> 8 set-precision
>> 
>> 2e   3e f/ f.
>> 2e4  3e f/ f.
>> 2e-4 3e f/ f.
>> 1e         f.
>> 1e4        f.
>> 1e-4       f.
>
>iForth version 6.9.109, generated 18:39:31, September 27, 2021.
>
>8 set-precision
>2e   3e f/ f. 0.66666667
>2e4  3e f/ f. 6666.66666667

12 significant digits here.

>2e-4 3e f/ f. 0.00006667

Only 4 significant digits here.

>2 set-precision
>2e   3e f/ f. 0.67
>2e4  3e f/ f. 6666.67

6 significant digits here.

>2e-4 3e f/ f. 0.00

No significant digits here.

>1e         f. 1.00
>1e4        f. 10000.00
>1e-4       f. 0.00

No significant digits here.

>5001e-4    f. 0.50
>
>200 set-precision
>2e   3e f/ f. 0.6666666666666666667
>2e4  3e f/ f. 6666.6666666666666665186
>2e-4 3e f/ f. 0.0000666666666666667

All show much less than 200 significant digits.

But I guess that, if the users of your system (and the other systems
that do not satisfy the "significant digits" specification) do not
complain, maybe the significan digits are not needed.


>1e         f. 1.0000000000000000000
>1e4        f. 10000.0000000000000000000
>1e-4       f. 0.0001000000000000000
>5001e-4    f. 0.5001000000000000000
>
>What I miss: right-alignment in fixed field, adding +/-/space, 
>suppressing trailing zeros, sane behavior when field too small,

Gforth has f.rdp, which gives you much of that:

|'f.rdp' ( rf +nr +nd +np -  ) gforth-0.6 "f-dot-rdp"
|   Print float rf formatted.  The total width of the output is nr.  For
|fixed-point notation, the number of digits after the decimal point is
|+nd and the minimum number of significant digits is np.  'Set-precision'
|has no effect on 'f.rdp'.  Fixed-point notation is used if the number of
|siginicant digits would be at least np and if the number of digits
|before the decimal point would fit.  If fixed-point notation is not
|used, exponential notation is used, and if that does not fit, asterisks
|are printed.  We recommend using nr>=7 to avoid the risk of numbers not
|fitting at all.  We recommend nr>=np+5 to avoid cases where 'f.rdp'
|switches to exponential notation because fixed-point notation would have
|too few significant digits, yet exponential notation offers fewer
|significant digits.  We recommend nr>=nd+2, if you want to have
|fixed-point notation for some numbers; the smaller the value of np, the
|more cases are shown in fixed-point notation (cases where few or no
|significant digits remain in fixed-point notation).  We recommend np>nr,
|if you want to have exponential notation for all numbers.
|
|   To give you a better intuition of how they influence the output, here
|are some examples of parameter combinations; in each line the same
|number is printed, in each column the same parameter combination is used
|for printing:
|
|         12 13 0    7 3 4   7 3 0   7 3 1   7 5 1   7 7 1   7 0 2  4 2 1
|     |-1.234568E-6|-1.2E-6| -0.000|-1.2E-6|-1.2E-6|-1.2E-6|-1.2E-6|****|
|     |-1.234568E-5|-1.2E-5| -0.000|-1.2E-5|-.00001|-1.2E-5|-1.2E-5|****|
|     |-1.234568E-4|-1.2E-4| -0.000|-1.2E-4|-.00012|-1.2E-4|-1.2E-4|****|
|     |-1.234568E-3|-1.2E-3| -0.001| -0.001|-.00123|-1.2E-3|-1.2E-3|****|
|     |-1.234568E-2|-1.2E-2| -0.012| -0.012|-.01235|-1.2E-2|-1.2E-2|-.01|
|     |-1.234568E-1|-1.2E-1| -0.123| -0.123|-.12346|-1.2E-1|-1.2E-1|-.12|
|     |-1.2345679E0| -1.235| -1.235| -1.235|-1.23E0|-1.23E0|-1.23E0|-1E0|
|     |-1.2345679E1|-12.346|-12.346|-12.346|-1.23E1|-1.23E1|   -12.|-1E1|
|     |-1.2345679E2|-1.23E2|-1.23E2|-1.23E2|-1.23E2|-1.23E2|  -123.|-1E2|
|     |-1.2345679E3|-1.23E3|-1.23E3|-1.23E3|-1.23E3|-1.23E3| -1235.|-1E3|
|     |-1.2345679E4|-1.23E4|-1.23E4|-1.23E4|-1.23E4|-1.23E4|-12346.|-1E4|
|     |-1.2345679E5|-1.23E5|-1.23E5|-1.23E5|-1.23E5|-1.23E5|-1.23E5|-1E5|

You may consider the behaviour of printing "****" for some numbers to
be insane, but note the following sentence from the documentation: "We
recommend using nr>=7 to avoid the risk of numbers not fitting at
all."

>engineering/SPICE units

Gforth currently supports scale letters for FP numbers on input (see
<https://net2o.de/gforth/Floating_002dpoint-number-and-complex-literals.html>),
but not yet for printing; e.g.

1G5 e. \ prints 1500000000e

I considered letting E. output that, but have not (yet?) done so.
Maybe a different word would be more appropriate.  Likewise for F.RDP.

> unit arithmetic

What do you have in mind?

>My FP programs almost always define a new variant of FP output.

You have not found enough commonalities between uses to define a few
words and use them everywhere?

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

#135319

On 8/8/2026 11:40 AM, Anton Ertl wrote:
> marcel hendrix <mhx@iae.nl> writes:
>> On 8/8/2026 6:39 AM, dxf wrote:
>>> 8 set-precision
>>>
>>> 2e   3e f/ f.
>>> 2e4  3e f/ f.
>>> 2e-4 3e f/ f.
>>> 1e         f.
>>> 1e4        f.
>>> 1e-4       f.
>>
>> iForth version 6.9.109, generated 18:39:31, September 27, 2021.
>>
>> 8 set-precision
>> 2e   3e f/ f. 0.66666667
>> 2e4  3e f/ f. 6666.66666667
> 
> 12 significant digits here.

[..]

iForth uses SET-PRECISION to set the number of digits after the decimal 
point.

> All show much less than 200 significant digits.

The maximum number of 'significant' digits is hard limited to 19.
I have no use for 800 digits, ever. (It may work on iForth for
Linux but I can't check that now.)
>> What I miss: right-alignment in fixed field, adding +/-/space,
>> suppressing trailing zeros, sane behavior when field too small,
> 
> Gforth has f.rdp, which gives you much of that:

I have implemented it but can't ever remember the name, and always 
struggle with the parameters. So it would make the implementations 
shorter but not decrease the number of words. As I'm very fond of
range indicators (120e-12 => 120 p), it can not serve as a plug-in
anyway.
> You may consider the behaviour of printing "****" for some numbers to
> be insane, but note the following sentence from the documentation: "We
> recommend using nr>=7 to avoid the risk of numbers not fitting at
> all."

It is extremely frustrating to receive '****' as a result for a 20 
minute simulation :--) This always happens when I am sure the
results will be in a certain range and have reserved just enough
space for that guess. I now let numbers print in as short a format
as possible in such a case (it is supposed to happen only when debugging).
>> engineering/SPICE units
> 
> Gforth currently supports scale letters for FP numbers on input (see
> <https://net2o.de/gforth/Floating_002dpoint-number-and-complex-literals.html>),
> but not yet for printing; e.g.
> 
> 1G5 e. \ prints 1500000000e

Really useful! A format like '1.5G' is also common and allows niceties 
like '1.5GHz' and such. Although I also need '1.5 GHz' very often.
> I considered letting E. output that, but have not (yet?) done so.
> Maybe a different word would be more appropriate.  Likewise for F.RDP.

Yes, like >FLOAT .
>> unit arithmetic
> 
> What do you have in mind?

It is not high on my list, but it would allow automatic label generation
for typed data. Like if a{ has type Voltage and b{ has type Current then
the legend for a{ is 'V', for b{ it is 'A', and for a{ b{ f/ it is 
{\Ohm}. I currently handle it with string manipulation and I/O redirection.
>> My FP programs almost always define a new variant of FP output.
> 
> You have not found enough commonalities between uses to define a few
> words and use them everywhere?
No, and I have looked many times (but maybe not hard enough) ...
(E.) (F.) (FE.) (E.R) (F.R) (FE.R) E. FE. FS. E.R F.R FE.R
(F.E16) (F.N4) (F.N2) (F.N1) (F.N2+_) (F.N3) F.% _F.N1 F.N2+
F.N2+_ CF.R  F.N3 F.N4 F.N2 F.N1 ....

One example:

FORTH> locate CF.R
File: d:\dfwforth/include/xopg.frt
   215:
   216>> : CF.R ( F: r -- ) PRECISION >S  SET-PRECISION  F.N1  S> 
SET-PRECISION ;
   217:

-marcel

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

#135329

marcel hendrix <mhx@iae.nl> writes:
>On 8/8/2026 11:40 AM, Anton Ertl wrote:
>> marcel hendrix <mhx@iae.nl> writes:
[...]
>It is extremely frustrating to receive '****' as a result for a 20 
>minute simulation :--) This always happens when I am sure the
>results will be in a certain range and have reserved just enough
>space for that guess. I now let numbers print in as short a format
>as possible in such a case (it is supposed to happen only when debugging).

Another way to deal with that is to let the computation run produce
the output in a way that keeps all information (e.g., as binary file,
or as .csv of E. outputs, or .csv of hex-printed FP numbers), and have
the formatted output as a separate post-processing step.

>> Gforth currently supports scale letters for FP numbers on input (see
>> <https://net2o.de/gforth/Floating_002dpoint-number-and-complex-literals.html>),
>> but not yet for printing; e.g.
>> 
>> 1G5 e. \ prints 1500000000e
>
>Really useful! A format like '1.5G' is also common

That works, too (same value).

>and allows niceties 
>like '1.5GHz' and such.

That does not.

>> I considered letting E. output that, but have not (yet?) done so.
>> Maybe a different word would be more appropriate.  Likewise for F.RDP.
>
>Yes, like >FLOAT .

?

>FLOAT is the reverse direction from FP output words like E. and
F.RDP.

BTW, I just checked, and Gforth does not implement the scaling letters
in >FLOAT (so >FLOAT does not accept "1.5G"); instead, REC-FLOAT does
it:

s" 1.5G" rec-float \ pushes 1.5e9 translate-float

>>> unit arithmetic
>> 
>> What do you have in mind?
>
>It is not high on my list, but it would allow automatic label generation
>for typed data. Like if a{ has type Voltage and b{ has type Current then
>the legend for a{ is 'V', for b{ it is 'A', and for a{ b{ f/ it is 
>{\Ohm}.

It is interesting that even programming languages that pride
themselves in "strong typing" rarely support dimensions and units,
despite the infamous incident with the Mars probe or somesuch that was
lost because of a metric/US-customary-unit mixup.  For Forth it would
require a lot of infrastructure to do properly.

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

#135321

On 8/08/2026 5:14 pm, marcel hendrix wrote:
> On 8/8/2026 6:39 AM, dxf wrote:
>> 8 set-precision
>>
>> 2e   3e f/ f.
>> 2e4  3e f/ f.
>> 2e-4 3e f/ f.
>> 1e         f.
>> 1e4        f.
>> 1e-4       f.
> 
> iForth version 6.9.109, generated 18:39:31, September 27, 2021.
> 
> 8 set-precision
> 2e   3e f/ f. 0.66666667
> 2e4  3e f/ f. 6666.66666667
> 2e-4 3e f/ f. 0.00006667
> 1e         f. 1.00000000
> 1e4        f. 10000.00000000
> 1e-4       f. 0.00010000
> 
> 2 set-precision
> 2e   3e f/ f. 0.67
> 2e4  3e f/ f. 6666.67
> 2e-4 3e f/ f. 0.00
> 1e         f. 1.00
> 1e4        f. 10000.00
> 1e-4       f. 0.00
> 5001e-4    f. 0.50
> 
> 200 set-precision
> 2e   3e f/ f. 0.6666666666666666667
> 2e4  3e f/ f. 6666.6666666666666665186
> 2e-4 3e f/ f. 0.0000666666666666667
> 1e         f. 1.0000000000000000000
> 1e4        f. 10000.0000000000000000000
> 1e-4       f. 0.0001000000000000000
> 5001e-4    f. 0.5001000000000000000
> ...

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.

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

#135322

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.

-marcel

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

#135324

On 9/08/2026 3:19 pm, marcel hendrix 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?

Isn't that behaviour what other langs do?  I'd be surprised if FORTRAN
or C couldn't print more than 20 decimal places.

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

I can understand SET-PRECISION being range-limited to a system's float
but printing a number is something else.  I don't have a PLACES as the
value is taken from the stack:

    F.R ( r places width -- )

If that becomes tedious, an app can create a VALUE to hold it.  For
general hacking however, I use F. FS. FE. G. which don't use decimal
places at all.

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

#135326

On 8/10/2026 11:15 AM, dxf wrote:
> On 9/08/2026 3:19 pm, marcel hendrix 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?
> 
> Isn't that behaviour what other langs do?  I'd be surprised if FORTRAN
> or C couldn't print more than 20 decimal places.
[..]
You mean, in case somebody wants to print 1e4932 with 4932 decimal places?

-marcel

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

#135327

On 10/08/2026 9:17 pm, marcel hendrix wrote:
> On 8/10/2026 11:15 AM, dxf wrote:
>> On 9/08/2026 3:19 pm, marcel hendrix 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?
>>
>> Isn't that behaviour what other langs do?  I'd be surprised if FORTRAN
>> or C couldn't print more than 20 decimal places.
> [..]
> You mean, in case somebody wants to print 1e4932 with 4932 decimal places?

ANS requires you provide a buffer sufficient to print a double in binary:

"The size of the pictured numeric output string buffer shall be at least
 (2*n) + 2 characters, where n is the number of bits in a cell."

That should be more than enough to print 1e4932 to 4932 decimal places.

If a lowly 16-bit forth can do it by dynamically changing the buffer size,
surely a 64-bit forth can scrape it in :)

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

#135328

On 10/08/2026 10:59 pm, dxf wrote:
> On 10/08/2026 9:17 pm, marcel hendrix wrote:
>> On 8/10/2026 11:15 AM, dxf wrote:
>>> On 9/08/2026 3:19 pm, marcel hendrix 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?
>>>
>>> Isn't that behaviour what other langs do?  I'd be surprised if FORTRAN
>>> or C couldn't print more than 20 decimal places.
>> [..]
>> You mean, in case somebody wants to print 1e4932 with 4932 decimal places?
> 
> ANS requires you provide a buffer sufficient to print a double in binary:
> 
> "The size of the pictured numeric output string buffer shall be at least
>  (2*n) + 2 characters, where n is the number of bits in a cell."
> 
> That should be more than enough to print 1e4932 to 4932 decimal places.

130 at least
 
> If a lowly 16-bit forth can do it by dynamically changing the buffer size,
> surely a 64-bit forth can scrape it in :)
 

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

#135332

On 8/10/2026 2:59 PM, dxf wrote:
> "The size of the pictured numeric output string buffer shall be at least
>   (2*n) + 2 characters, where n is the number of bits in a cell."

CELL ? I guess that should be 'size of numbers on the floating-point 
stack' ?
Anyway, that would be only 162 characters, not 4932.

-marcel

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

#135336

On 11/08/2026 4:42 am, marcel hendrix wrote:
> On 8/10/2026 2:59 PM, dxf wrote:
>> "The size of the pictured numeric output string buffer shall be at least
>>   (2*n) + 2 characters, where n is the number of bits in a cell."
> 
> CELL ? I guess that should be 'size of numbers on the floating-point stack' ?
> Anyway, that would be only 162 characters, not 4932.

My bad.  Even so, 20 dec. places is small relative to the HOLD buffer that you
likely do have.  It suggests your implementation has a bottleneck somewhere -
that you have accepted as 'good enough'.

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

#135339

On 11/08/2026 5:10 pm, dxf wrote:
> On 11/08/2026 4:42 am, marcel hendrix wrote:
>> On 8/10/2026 2:59 PM, dxf wrote:
>>> "The size of the pictured numeric output string buffer shall be at least
>>>   (2*n) + 2 characters, where n is the number of bits in a cell."
>>
>> CELL ? I guess that should be 'size of numbers on the floating-point stack' ?
>> Anyway, that would be only 162 characters, not 4932.
> 
> My bad.  Even so, 20 dec. places is small relative to the HOLD buffer that you
> likely do have.  It suggests your implementation has a bottleneck somewhere -
> that you have accepted as 'good enough'.

Speaking of unexpected surprises ...

SwiftForth x64-Windows 4.1.6 01-Apr-2026

18 set-precision  ok
3.141592653589793238e  f. 3.141592653589793238  ok
3.141592653589793238e15  f. 3141592653589793.2378ú7777777700000  ok


INCLUDE "D:\FPOUT_SwiftForth4.F"
VFX-compatible floating-point output functions for SwiftForth 4
N.B. To make the functions permanent enter GILD after loading.

FS. isn't unique.
FE. isn't unique.
(F.) isn't unique.
F.R isn't unique.
F. isn't unique.
5 definitions were hidden
 ok

3.141592653589793238e  f. 3.14159265358979324  ok
3.141592653589793238e  -1 0 f.r 3.14159265358979324 ok
3.141592653589793238e15  18 0 f.r 3141592653589793.240000000000000000 ok

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

#135383

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)

>
>-marcel
>

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]

#135386

albert@spenarnc.xs4all.nl writes:
>All floating point numbers are rubbish from a certain point on,

Wrong.

>1E2
> OK
> 100 F.R
> 9.9999999999999999982652765240231929055880755186080932617187500000000000000000000000000000000000000000E1  OK

1E2 can be represented exactly in floating-point, as can all other
integers that fit in the mantissa (i.e., up to 2^53 for binary64 (IEEE
DP FP)).

So in this example either the conversion to FP is "rubbish", to use
your word, or the conversion from FP.  And the problem with the
fallacy that all FP numbers are rubish is that it prevents you from
noticing this.

Here's what you see in Gforth:

1e2 e.exact \ 100e ok

In addition to these integers, there multiples by a power of 2 are
representable until the exponent leaves the normal FP number range.
For subnormal numbers, you get these integers times (for binary64)
2^-1074.

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

#135388

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.

>- anton

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]

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

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

csiph-web