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

Groups > comp.lang.forth > #59612

Re: FP-Number Ambiguities (answer imported from future)

Show all headers | View raw

On Fri, 19 May 2017 14:06:32 -0700 (PDT)
minforth@arcor.de wrote:

> I know it is a nearly dead horse in Forth, but IMO it should
> be streamlined the sooner the better:

I think the ambiguities are in the float number hardware, and
not especially any Forth. 

> 1. references for fp-number input and output formats when the
> double number wordset is loaded and when it is not

Perhaps it would be much better for the computer to remember
more precisely what you type in, and select how to most
efficiently store it. I'm working on numeric input which does
this.  
 
> 2. truncation of trailing mantissa zeroes yes or no? how can
> it be controlled?

It should be controlled by only displaying digits that are
valid.  Presently we see oddities like this:

1.000E0  3E  F/ F. 0.333333333333333  ok
1.000E0  10E  F/ F. 0.1  ok

The computer is doing it's best, but given that the precision of
the entered numbers is about the same there are too many threes,
and not nearly enough zeros in these results.

> 3. buffer length for REPRESENT differs from PRECISION: what
> happens then?

The results should correctly reflect the precision of the data
processed, a brief comparison:

  One Ten Slash - Today:
1.000000E0  10E  F/ F. 0.1  [64b]
1.000E0  10E  F/ F. 0.1  [64b]
1.E0  10E  F/ F. 0.1  [64b] [1]

  One Ten Slash - Ideal:
1.000000E0  10  / . 0.100000…  [~32b] [4]
1.000E0  10  / . 0.100…   [~16b]
1.E0  10  / . 0↙  [~8b]  [2] [5]


  One Three Slash - Today:
1.000000E0  3E  F/ F. 0.333333333333333  [64b]
1.000E0  3E  F/ F. 0.333333333333333  [64b]
1.E0  3E  F/ F. 0.333333333333333  [64b]

  One Three Slash - Ideal:
1.000000E0  3  / . 0.333333…  [~32b]
1.000E0  3  / . 0.3333…  [~16b]
1.E0  3  / . 0↙  [~8b]  [2]
1.0E0  3  / . 0.3…  [~16b] [3]


Would this ideal degree of complexity make computers too
expensive?  Well yes and no. The six times more complex
processor would cost more, but what is the value of having
correct answers? 

Overall performance can be limited by memory bandwidth, waste
heat disposal, and electricity bills. Most of this relates to
pushing bits between the processor and external RAM. 

Only moving valid bits can reduce memory access and/or increase
performance by a factor of two, see data size notes above. The
unum technology is about 3 years old now, probably another 7 to
go before common usage. 

Back to the present, its nearly Monday...

Jan Coombs
-- 

[1] "0.1" may be misleading, the data stored here is 64b long:
1e0 10e0 f/ myFlt f!  .myFlt  + 107FB34A73F050 3FB  ok
and there is no provision to tell how many ofthese bits are
valid.

[2] Bad data entry?  The radix point indicates a fraction, but
none is provided, the "E" anticipates an exponent, but none
is given. This may deserve an error message, otherwise is just
an integer.

[3] 1.0E0 indicates the degree of source data precision, (~3.5b)
and this dictates the available precision in any results using
this. 

[4] Most float computation produces inexact results, which is
indicated by the ellipsis. The digits before the ellipsis are
calculated and correct. 

[5] If a simple computation only uses integers, and binary
fractions then the result may be exact, and could be marked
like this: "120↙"

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

FP-Number Ambiguities minforth@arcor.de - 2017-05-19 14:06 -0700
  Re: FP-Number Ambiguities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-20 10:56 +0000
    Re: FP-Number Ambiguities minforth@arcor.de - 2017-05-20 11:50 -0700
      Re: FP-Number Ambiguities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-21 14:59 +0000
        Re: FP-Number Ambiguities minforth@arcor.de - 2017-05-21 12:08 -0700
          Re: FP-Number Ambiguities mhx@iae.nl - 2017-05-21 12:50 -0700
            Re: FP-Number Ambiguities minforth@arcor.de - 2017-05-21 15:04 -0700
          Re: FP-Number Ambiguities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-22 11:43 +0000
            Re: FP-Number Ambiguities minforth@arcor.de - 2017-05-22 06:40 -0700
              Re: FP-Number Ambiguities albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-22 16:33 +0200
                Re: FP-Number Ambiguities minforth@arcor.de - 2017-05-22 08:34 -0700
              Double numbers and floats in the text interpreter (was: FP-Number...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-22 16:17 +0000
    Re: FP-Number Ambiguities pahihu <pahihu@gmail.com> - 2017-05-24 10:19 -0700
      Re: FP-Number Ambiguities minforth@arcor.de - 2017-05-24 11:21 -0700
        Re: FP-Number Ambiguities pahihu <pahihu@gmail.com> - 2017-05-24 12:13 -0700
          Re: FP-Number Ambiguities minforth@arcor.de - 2017-05-24 13:12 -0700
  Re: FP-Number Ambiguities (answer imported from future) Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-05-20 22:54 +0100
  Re: FP-Number Ambiguities "HAA" <someone@microsoft.com> - 2017-05-24 17:21 +1000
    Re: FP-Number Ambiguities minforth@arcor.de - 2017-05-24 01:11 -0700
      Re: FP-Number Ambiguities "HAA" <someone@microsoft.com> - 2017-05-25 12:28 +1000
        Re: FP-Number Ambiguities minforth@arcor.de - 2017-05-25 00:36 -0700

csiph-web