1. Forum
  2. Usenet
  3. COMP.LANG.FORTH

  • Re: Display Engineering Notation with SI Prefix

    From mhx@21:1/5 to dxf on Thu Aug 29 10:39:34 2024
    On Thu, 29 Aug 2024 10:02:26 +0000, dxf wrote:

    On 29/08/2024 1:32 am, dxf wrote:
    [..]
    The real (FE.) has no such issues and works as expected ...

    VFX Forth 64 for Windows x64
    © MicroProcessor Engineering Ltd, 1998-2023

    Version: 5.43 [build 4241]
    Build date: 22 December 2023

    2 set-precision ok
    1.234e 1e2 f* -1 (fe.) type 120.E0 ok

    Using the non-standard set-precision of iForth:

    FORTH> 2 set-precision 1.234e f. 1.23 ok
    FORTH> 1 set-precision 1.234e f. 1.2 ok
    FORTH> 3 set-precision 1.234e f. 1.234 ok
    FORTH> 3 set-precision 1234e f. 1234.000 ok
    FORTH> 0 set-precision 1234e f. 1234 ok

    Didn't F83 have DIGITS ?

    -marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From mhx@21:1/5 to dxf on Thu Aug 29 14:23:33 2024
    On Thu, 29 Aug 2024 12:39:20 +0000, dxf wrote:

    [..]

    So iForth PRECISION equates to 'decimal places'.

    Yes. I appreciate the mathematical rigor of SET-PRECISION,
    but literally *none* of my academic and engineering friends
    *ever* complained about iForth's evil deviation. Who really
    likes to see

    -1e 0e 0.5e 0e z^ z. 0.0000000000000000612323399573677 + i1. ok

    3 set-precision ok
    -1e 0e 0.5e 0e z^ z. 0.0000000000000000612 + i1. ok

    in computed output?

    Didn't F83 have DIGITS ?

    Neither Laxen/Perry F83 nor Forth-83 had floating point. You may be
    thinking of PLACES from 'The Forth Vendors Group Standard Floating
    Point Extension' (?)

    Yes, that was it. Although one actually wants PLACES, I can
    understand why it makes more sense to standardize SET-PRECISION .

    Has any language other that Forth opted for 'significant digits' over
    (or in addition to) 'decimal places'? The former seems particularly
    suited to engineering.

    Not that I know of ...

    The problem with PLACES is that a printout of results after a
    few hours of number-crunching may be useless when
    one has estimated the range of the likely outcomes wrong.

    -marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From mhx@21:1/5 to dxf on Fri Aug 30 06:30:20 2024
    On Fri, 30 Aug 2024 2:13:43 +0000, dxf wrote:
    [..]
    3 set-precision  ok
    -1e 0e 0.5e 0e z^ z.  0.0000000000000000612 + i1.  ok
    [..]
    Can't say without knowing what was the criteria. If a user wants
    to show the result to 3 significant digits, who can argue with that.
    3 significant digits is about right for (ENG.) applications.

    When the user wants 3 significant digits according to the mathematical definition there is no discussion that SET-PRECISION is appropriate.

    If a system is to produce 100 Watts, and an approximate model of the
    losses returns 0.0000000000000000612 Watts, then that is quite probably
    not the wanted output (because it tells you the resolution of the
    floating point package, not the accuracy of the approximation).
    However, when that same model returns 100 Watts for the full output
    power, 100 or 100.0 is (probably) the expectation. Extra steps are
    needed
    to print the losses in a useful way, and those steps match perfectly
    with PLACES. PLACES would also work to print the full power as 100.
    It is not ideal, but the reason it is not ideal has nothing to do with SET-PRECISION .

    -marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From mhx@21:1/5 to dxf on Fri Aug 30 08:26:26 2024
    On Fri, 30 Aug 2024 8:03:26 +0000, dxf wrote:

    At the same time I also found
    SET-PRECISION to be useful.

    An example would be instructive.

    -marcel

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