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

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

FP-Number Ambiguities

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

Contents

  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

Page 1 of 2  [1] 2  Next page →

#59567 — FP-Number Ambiguities

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

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

2. truncation of trailing mantissa zeroes yes or no? how can it be controlled?

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

Only one example:
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
0.0  ok  <-- is treated as double number, not as per standard
f. 0.
:2: Floating-point stack underflow
>>>f.<<<
Backtrace:
$7FAA2C08 throw
1e  ok
f. 1.  ok <-- why not 1E ? 
1e  ok
fe. 1.00000000000000E0  ok  <-- why not 1.E0 ?
1 set-precision  ok
1e fs. 1.E0  ok
0 set-precision  ok  <-- test if this trims
1e fs.  .  <-- gforth hangs

(1 SET-PRECISION would do here of course, but not auto-adapt to other floats)

What do you mean? How do you solve this "under-specification" in the standard?
(I am not hacking on gforth, btw!)

[toc] | [next] | [standalone]

#59587

minforth@arcor.de writes:
>I know it is a nearly dead horse in Forth, but IMO it should be streamlined the sooner the better:
>
>1. references for fp-number input and output formats when the double number wordset is loaded and when it is not

What do you want to say?

>2. truncation of trailing mantissa zeroes yes or no? how can it be controlled?

The specification of F. FS. and FE. does not specify much, so the
systems are pretty free in what they do.  If you want it more tightly
specified, make a proposal.  Existing practice: Gforth has F.RDP which
allows you to specify the format relatively precisely.

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

PRECISION and SET-PRECISION are only relevant for F. FE. FS., and they
don't influence REPRESENT at all.


>
>Only one example:
>Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>Type `bye' to exit
>0.0  ok  <-- is treated as double number, not as per standard

The standard does not specify what 0.0 means.  In a standard program,
if you want an FP number, you have to write, e.g., "0e", while for a
double number, you have to write, e.g., "0.".

>1e  ok
>f. 1.  ok <-- why not 1E ? 

F. is specified to produce a number in the format 

[-] <digits>.<digits0>

i.e., no "e" allowed.  If you mean that you would expect F. to output
numbers in a way that you can input in the text interpreter, and it
will produce approximately the same number, then yes, I think this
would be nice.  Unfortunately, the Forth-94 committee decided on
something else, and the issue was not grave enough that anyone made a
proposal to fix it in the Forth-200x process (not for Forth-2012, and
not since then).

>1e  ok
>fe. 1.00000000000000E0  ok  <-- why not 1.E0 ?

Maybe thanks to PRECISION?  There are people who advocate having
trailing zeroes in engineering contexts in order to indicate the
precision.  So this might be appropriate for FE. and FS.

>1 set-precision  ok
>1e fs. 1.E0  ok
>0 set-precision  ok  <-- test if this trims
>1e fs.  .  <-- gforth hangs

Thank you for this bug report.  Unfortunately, I cannot reproduce
this.  In both 0.7.2 and in the current development version, I get

0 set-precision  ok
1e fs.  ok

>How do you solve this "under-specification" in the standard?

If you want to solve it in the standard, the way to go is to make a
proposal for tightening the specification.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

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

#59607

Am Samstag, 20. Mai 2017 13:28:56 UTC+2 schrieb Anton Ertl:
> minforth@arcor.de writes:
> >I know it is a nearly dead horse in Forth, but IMO it should be streamlined the sooner the better:
> >
> >1. references for fp-number input and output formats when the double number wordset is loaded and when it is not
> 
> What do you want to say?

Content set before wordsmithing, and focussing on interpreter input,
my ideas move along this table: 

BASE=10  Loaded wordsets:            
INPUT    CORE       CORE+DOUBLE       CORE+FLOAT  CORE+DOUBLE+FLOAT
-------------------------------------------------------------------
1        1          1 (DPL=-1)        d: 1        1 (DPL=-1)
+1       1          1 (DPL=-1)        d: 1        1 (DPL=-1)
-1       -1         -1 (DPL=-1)       d: -1       -1 (DPL=-1)
0        0          0 (DPL=-1)        d: 0        0 (DPL=-1)
+0       0          0 (DPL=-1)        d: 0        0 (DPL=-1)
-0       0          0 (DPL=-1)        d: 0        0 (DPL=-1)
0.       not found  0 0 (DPL=0)       f: +0.      0 0 (DPL=0)
+0.      not found  0 0 (DPL=0)       f: +0.      0 0 (DPL=0)
-0.      not found  0 0 (DPL=0)       f: -0.      0 0 (DPL=0)
1.       not found  1 0 (DPL=0)       f: 1.       1 0 (DPL=0)
-1.      not found  -1 -1 (DPL=0)     f: -1.      -1 -1 (DPL=0)
1.03     not found  103 0 (DPL=1)     f: 1.03     f: 1.03
-1.03    not found  -103 -1 (DPL=2)   f: -1.03    f: -1.03
1.030    not found  1030 (DPL=3)      f: 1.03     f: 1.03
-1.030   not found  -1030 -1 (DPL=3)  f: -1.03    f: -1.03
.0103    not found  103 0 (DPL=4)     f: 1.03E-1  f: 1.03E-1
-.0103   not found  -103 -1 (DPL=4)   f: -1.03E-1 f: -1.03E-1
0.0103   not found  103 0 (DPL=4)     f: 1.03E-2  f: 1.03E-2
-0.0103  not found  -103 -1 (DPL=4)   f: -1.03E-2 f: -1.03E-2
INF      not found  not found         +INF        +INF
+INF     not found  not found         +INF        +INF
-INF     not found  not found         -INF        -INF
NAN      not found  not found         +NAN        +NAN
+NAN     not found  not found         +NAN        +NAN
-NAN     not found  not found         -NAN        -NAN

Requirements:
1. DPL becomes part of the DOUBLE wordset
2. INF/NAN specify default values in the specific hardware

Pros:
well-behaving to legacy code
gives priority to floating point numbers over double numbers
clarifies some unspecified issues in the standard

Cons:
table is incomplete (missing E/D as exponents)
t.b.d. hex base inputs?
t.b.d. standard prefix for double numbers and floats?

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

#59658

minforth@arcor.de writes:
>Am Samstag, 20. Mai 2017 13:28:56 UTC+2 schrieb Anton Ertl:
>BASE=10  Loaded wordsets:            
>INPUT    CORE       CORE+DOUBLE       CORE+FLOAT  CORE+DOUBLE+FLOAT
>-------------------------------------------------------------------
>0.       not found  0 0 (DPL=0)       f: +0.      0 0 (DPL=0)

If we are going to make number conversion for "0." system-dependent,
there is no point in standardizing it.  So my vote is for
de-standardizing "0."; doubles can be written as "#0.", and if people
are actually weaned off "0." for doubles (unlikely), we can switch to
having it mean FP at some time in the future.

>1.03     not found  103 0 (DPL=1)     f: 1.03     f: 1.03

Again, if "1.03" has a system-dependent meaning, there is no point in
standarizing it.  Also, if "1.03" means float, it is confusing if "0."
can mean double in the same system (your last column); i.e., we can
only go there once we have de-standardized "0." as double.

>INF      not found  not found         +INF        +INF

Such constants are certainly a good idea as FLOAT EXT words (i.e.,
optional for the sake of soft-float implementations; in hardware, IEEE
has won).  Who makes the proposal?

>well-behaving to legacy code

If I load a legacy program containing "1.03" on a system with
CORE+DOUBLE+FLOAT, the program gets a float, while it expects a
double.  I.e., not at all well-behaved.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

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

#59690

Am Sonntag, 21. Mai 2017 17:13:15 UTC+2 schrieb Anton Ertl:
> minforth@arcor.de writes:
> >Am Samstag, 20. Mai 2017 13:28:56 UTC+2 schrieb Anton Ertl:
> >BASE=10  Loaded wordsets:            
> >INPUT    CORE       CORE+DOUBLE       CORE+FLOAT  CORE+DOUBLE+FLOAT
> >-------------------------------------------------------------------
> >0.       not found  0 0 (DPL=0)       f: +0.      0 0 (DPL=0)
> 
> If we are going to make number conversion for "0." system-dependent,
> there is no point in standardizing it.  So my vote is for
> de-standardizing "0."; doubles can be written as "#0.", and if people
> are actually weaned off "0." for doubles (unlikely), we can switch to
> having it mean FP at some time in the future.
> 
> >1.03     not found  103 0 (DPL=1)     f: 1.03     f: 1.03
> 
> Again, if "1.03" has a system-dependent meaning, there is no point in
> standarizing it.  Also, if "1.03" means float, it is confusing if "0."
> can mean double in the same system (your last column); i.e., we can
> only go there once we have de-standardized "0." as double.
> 
> >INF      not found  not found         +INF        +INF
> 
> Such constants are certainly a good idea as FLOAT EXT words (i.e.,
> optional for the sake of soft-float implementations; in hardware, IEEE
> has won).  Who makes the proposal?
> 
> >well-behaving to legacy code
> 
> If I load a legacy program containing "1.03" on a system with
> CORE+DOUBLE+FLOAT, the program gets a float, while it expects a
> double.  I.e., not at all well-behaved.
> 

The standard 8.3.1 speaks only of the trailing decimal point, so 1.03
is not strictly a double number.
I know that older "dinosaaur" Forths treated 1.03 as double number.
It made sense for 16 bit systems.

So the question is: who shoulkd rule?
a) dinosaurs: 1.03 is a double number
b) the standard: 1.03 is ambiguous
c) common sense: it's a float

To leave 0. "in the blue" as you suggested is nonsense (pardon me).

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

#59694

On Sunday, May 21, 2017 at 9:08:50 PM UTC+2, minf...@arcor.de wrote:
> Am Sonntag, 21. Mai 2017 17:13:15 UTC+2 schrieb Anton Ertl:
> > minforth@arcor.de writes:
> > >Am Samstag, 20. Mai 2017 13:28:56 UTC+2 schrieb Anton Ertl:
[..]
> The standard 8.3.1 speaks only of the trailing decimal point, so 1.03
> is not strictly a double number.
> I know that older "dinosaaur" Forths treated 1.03 as double number.
> It made sense for 16 bit systems.
> 
> So the question is: who shoulkd rule?
> a) dinosaurs: 1.03 is a double number
> b) the standard: 1.03 is ambiguous
> c) common sense: it's a float
> 
> To leave 0. "in the blue" as you suggested is nonsense (pardon me).

So what is  bad.beef  according to common sense?  Or 1111.1010 ?

-marcel

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

#59699

Am Sonntag, 21. Mai 2017 21:50:44 UTC+2 schrieb m...@iae.nl:
> On Sunday, May 21, 2017 at 9:08:50 PM UTC+2, minf...@arcor.de wrote:
> > Am Sonntag, 21. Mai 2017 17:13:15 UTC+2 schrieb Anton Ertl:
> > > minforth@arcor.de writes:
> > > >Am Samstag, 20. Mai 2017 13:28:56 UTC+2 schrieb Anton Ertl:
> [..]
> > The standard 8.3.1 speaks only of the trailing decimal point, so 1.03
> > is not strictly a double number.
> > I know that older "dinosaaur" Forths treated 1.03 as double number.
> > It made sense for 16 bit systems.
> > 
> > So the question is: who shoulkd rule?
> > a) dinosaurs: 1.03 is a double number
> > b) the standard: 1.03 is ambiguous
> > c) common sense: it's a float
> > 
> > To leave 0. "in the blue" as you suggested is nonsense (pardon me).
> 
> So what is  bad.beef  according to common sense?  Or 1111.1010 ?
> 
> -marcel

FP-number interpretation requires the current base to be decimal.
So bad.beef could be a word in the search wordlist.

For BASE >= 16 it wouldn't even be a double number acc. to the
current standard par. 8.3.1

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

#59717

minforth@arcor.de writes:
>Am Sonntag, 21. Mai 2017 17:13:15 UTC+2 schrieb Anton Ertl:
>> minforth@arcor.de writes:
>> >well-behaving to legacy code
>> 
>> If I load a legacy program containing "1.03" on a system with
>> CORE+DOUBLE+FLOAT, the program gets a float, while it expects a
>> double.  I.e., not at all well-behaved.
>> 
>
>The standard 8.3.1 speaks only of the trailing decimal point, so 1.03
>is not strictly a double number.

The standard has no say on legacy programs.  That's why they are
called legacy programs, not standard programs.

>I know that older "dinosaaur" Forths treated 1.03 as double number.

Popular current Forth systems are "dinosaur" Forths in your
terminology:

[b8:~:16357] vfxlin include /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
VFX Forth
 Version: 4.72 [build 0560]
 Build date: 27 September 2016
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
1.03 d. 103  ok
[b8:~:16358] sf include %SwiftForth/lib/options/fpmath.f.fth
 ok
1.03 d. 103  ok

[b8:~:16359] ~/gforth/gforth
Gforth 0.7.9_20170406, Copyright (C) 1995-2016 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
1.03 d.            
*terminal*:1:1: '1.03' is a double-cell integer; type `help' for more info103  ok

>So the question is: who shoulkd rule?
>a) dinosaurs: 1.03 is a double number
>b) the standard: 1.03 is ambiguous
>c) common sense: it's a float
>
>To leave 0. "in the blue" as you suggested is nonsense (pardon me).

It's the only good way I see to getting to the situation that you
claim is common sense.  Having "0." as double, and "1.03" as float is
even more confusing than having both as double.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

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

#59718

Am Montag, 22. Mai 2017 13:56:42 UTC+2 schrieb Anton Ertl:
> minforth@arcor.de writes:
> >Am Sonntag, 21. Mai 2017 17:13:15 UTC+2 schrieb Anton Ertl:
> >> minforth@arcor.de writes:
> >> >well-behaving to legacy code
> >> 
> >> If I load a legacy program containing "1.03" on a system with
> >> CORE+DOUBLE+FLOAT, the program gets a float, while it expects a
> >> double.  I.e., not at all well-behaved.
> >> 
> >
> >The standard 8.3.1 speaks only of the trailing decimal point, so 1.03
> >is not strictly a double number.
> 
> The standard has no say on legacy programs.  That's why they are
> called legacy programs, not standard programs.
> 

LOL !!

> >I know that older "dinosaaur" Forths treated 1.03 as double number.
> 
> Popular current Forth systems are "dinosaur" Forths in your
> terminology:
> 

Yes, pardon my terminology to make things mor pregnant.

So popular Forths follow either "legacy" or "standard" as their particular
authors like or do not like.

Okay.......


> >To leave 0. "in the blue" as you suggested is nonsense (pardon me).
> 
> It's the only good way I see to getting to the situation that you
> claim is common sense.  Having "0." as double, and "1.03" as float is
> even more confusing than having both as double.


That's why I suggested that whenever the float wordset is loaded, it should
overrule the legacy double number recognition.

But you are right, it can be confusing when a user is unaware.

Indeed the most consistent way would be to declare legacy double number
recognition obsolete, unless they are casted by some prefix
(# or [D] perhaps). 
 

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

#59722

In article <33aae2b8-f7c7-41e5-a790-88bcfb963372@googlegroups.com>,
 <minforth@arcor.de> wrote:
>Am Montag, 22. Mai 2017 13:56:42 UTC+2 schrieb Anton Ertl:
>> minforth@arcor.de writes:
>> >Am Sonntag, 21. Mai 2017 17:13:15 UTC+2 schrieb Anton Ertl:
>> >> minforth@arcor.de writes:
>> >> >well-behaving to legacy code
>> >>
>> >> If I load a legacy program containing "1.03" on a system with
>> >> CORE+DOUBLE+FLOAT, the program gets a float, while it expects a
>> >> double.  I.e., not at all well-behaved.
>> >>
>> >
>> >The standard 8.3.1 speaks only of the trailing decimal point, so 1.03
>> >is not strictly a double number.
>>
>> The standard has no say on legacy programs.  That's why they are
>> called legacy programs, not standard programs.
>>
>
>LOL !!
>
>> >I know that older "dinosaaur" Forths treated 1.03 as double number.
>>
>> Popular current Forth systems are "dinosaur" Forths in your
>> terminology:
>>
>
>Yes, pardon my terminology to make things mor pregnant.
>
>So popular Forths follow either "legacy" or "standard" as their particular
>authors like or do not like.
>
>Okay.......

Not okay. Upwards compatibility is not the same as "following legacy".

>
>
>> >To leave 0. "in the blue" as you suggested is nonsense (pardon me).
>>
>> It's the only good way I see to getting to the situation that you
>> claim is common sense.  Having "0." as double, and "1.03" as float is
>> even more confusing than having both as double.
>
>
>That's why I suggested that whenever the float wordset is loaded, it should
>overrule the legacy double number recognition.

Which is rejected by Anton Ertl and for a good reason. It is no problem
that after loading the float wordset more literals (denotations) are
accepted than before. It is bad if they change meaning.

>
>But you are right, it can be confusing when a user is unaware.

An understatement.

>
>Indeed the most consistent way would be to declare legacy double number
>recognition obsolete, unless they are casted by some prefix
>(# or [D] perhaps).
>

My preference is . Two dots in a word can never mean floating point.
And we already have dedicated the dot to double numbers.
******************************************
*    .1999.                              *
******************************************

Groetjes Albert.
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#59727

Am Montag, 22. Mai 2017 16:33:10 UTC+2 schrieb Albert van der Horst:

> >
> >> >To leave 0. "in the blue" as you suggested is nonsense (pardon me).
> >>
> >> It's the only good way I see to getting to the situation that you
> >> claim is common sense.  Having "0." as double, and "1.03" as float is
> >> even more confusing than having both as double.
> >
> >
> >That's why I suggested that whenever the float wordset is loaded, it should
> >overrule the legacy double number recognition.
> 
> Which is rejected by Anton Ertl and for a good reason. It is no problem
> that after loading the float wordset more literals (denotations) are
> accepted than before. It is bad if they change meaning.

It is still ambiguous, depending on which wordsets are loaded first:

1.0E could be a hex double or a valid float

> >
> >Indeed the most consistent way would be to declare legacy double number
> >recognition obsolete, unless they are casted by some prefix
> >(# or [D] perhaps).
> >
> 
> My preference is . Two dots in a word can never mean floating point.
> And we already have dedicated the dot to double numbers.
> ******************************************
> *    .1999.                              *
> ******************************************

I assume you're not kidding...   ;-)

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

#59729 — Double numbers and floats in the text interpreter (was: FP-Number...)

minforth@arcor.de writes:
>Am Montag, 22. Mai 2017 13:56:42 UTC+2 schrieb Anton Ertl:
>So popular Forths follow either "legacy" or "standard" as their particular
>authors like or do not like.

Actually both: They support "0." as double as required by the
standard, and "1.03" as double as allowed (for systems) by the
standard, and as required by legacy programs.

>Indeed the most consistent way would be to declare legacy double number
>recognition obsolete, unless they are casted by some prefix
>(# or [D] perhaps). 

#0. is already a standard (Forth-2012) way to write doubles, and it
does not conflict with FP syntax in the wider world.

However, assuming we manage to de-standardize "0.", that is only the
first step.  As long as legacy programs continue to use "0." and
"1.23", systems will continue to support this syntax, and cannot
switch to using this syntax for FP.

One way to deal with that would be to prefix the legacy programs with
some word (maybe LEGACY-DOUBLE-SYNTAX) that switches the
interpretation of "0." to mean double, but that means that you cannot
mix the legacy program with new code.

So what is needed IMO is a tool that converts the legacy code into
modern code (e.g., replace "0." with "#0." or "$0.", or maybe some
system-specific non-conflicting syntax, e.g., ".0.").  Should not be
hard to write: Just output the input on text interpretation, except
for numbers with the "0." syntax; there the tool outputs the modern
form.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

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

#59778

In Gforth 0.7.9_20170518:

-1e 0e f/ f. -in ok

pahihu

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

#59783

Am Mittwoch, 24. Mai 2017 19:19:40 UTC+2 schrieb pahihu:
> In Gforth 0.7.9_20170518:
> 
> -1e 0e f/ f. -in ok
> 
> pahihu

the same here
> -1. 0. f/ f. -inf  ok

btw VFX Forth even offers legacy-floats, ans-floats or mpe-floats.
here 1e is an integer when it fits in the current base 
but 1.e is a float indeed.

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

#59786

2017. május 24., szerda 20:21:55 UTC+2 időpontban minf...@arcor.de a következőt írta:
> Am Mittwoch, 24. Mai 2017 19:19:40 UTC+2 schrieb pahihu:
> > In Gforth 0.7.9_20170518:
> > 
> > -1e 0e f/ f. -in ok
> > 
> > pahihu
> 
> the same here
> > -1. 0. f/ f. -inf  ok
> 

In Gforth the "f" is missing, just "-in".

iForth uses PRECISION as decimal digits, not significant digits.
Gforth and SwiftForth uses PRECISION as significant digits.
Gforth rounds in F. FS. FE. but SwiftForth truncates....

pahihu

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

#59787

Am Mittwoch, 24. Mai 2017 21:13:46 UTC+2 schrieb pahihu:
> 2017. május 24., szerda 20:21:55 UTC+2 időpontban minf...@arcor.de a következőt írta:
> > Am Mittwoch, 24. Mai 2017 19:19:40 UTC+2 schrieb pahihu:
> > > In Gforth 0.7.9_20170518:
> > > 
> > > -1e 0e f/ f. -in ok
> > > 
> > > pahihu
> > 
> > the same here
> > > -1. 0. f/ f. -inf  ok
> > 
> 
> In Gforth the "f" is missing, just "-in".
> 
> iForth uses PRECISION as decimal digits, not significant digits.
> Gforth and SwiftForth uses PRECISION as significant digits.
> Gforth rounds in F. FS. FE. but SwiftForth truncates....
> 
> pahihu

It might just be a small gforth bug. gforth 0.7.0 prints Inf, but unsigned.

My first post in this thread suggested a reference table for input and
output formats of doubles and floats.

But legacy chaos rules.

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

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

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↙"

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

#59768

minforth@arcor.de wrote:
> ...
> 0 set-precision  ok  <-- test if this trims
> 1e fs.  .  <-- gforth hangs

PRECISION under ANS refers to 'significant digits' (see the spec).
Displaying zero significant digits is meaningless i.e. an ambiguous condition.
Similarly ambiguous is requesting more significant digits than your system
can supply.   With this in mind, most forths range-limit SET-PRECISION
e.g. 1 MAX  xxx MIN  where xxx is the highest precision the system can supply,
say 16 for 64-bit floats.

Perhaps you are thinking of 'decimal places'?  ANS has nothing to say about
that.  Your system may provide suitable functions or you can write your own.

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

#59770

Am Mittwoch, 24. Mai 2017 09:21:49 UTC+2 schrieb HAA:
> minforth@arcor.de wrote:
> > ...
> > 0 set-precision  ok  <-- test if this trims
> > 1e fs.  .  <-- gforth hangs
> 
> PRECISION under ANS refers to 'significant digits' (see the spec).
> Displaying zero significant digits is meaningless i.e. an ambiguous condition.
> Similarly ambiguous is requesting more significant digits than your system
> can supply.   With this in mind, most forths range-limit SET-PRECISION
> e.g. 1 MAX  xxx MIN  where xxx is the highest precision the system can supply,
> say 16 for 64-bit floats.
> 
> Perhaps you are thinking of 'decimal places'?  ANS has nothing to say about
> that.  Your system may provide suitable functions or you can write your own.

Sure I know, garbage in, garbage out.
Anyhow the fp-number wordset spec is short and leaves many things "system specific".
Also whether trailing zeros are significant or not so that they can be trimmed
is "application specific".

So in my world all fp-numbers have a decimal point and an optional exponent, meaning 1E is no fp-number in "violation" of ANS § 12.3.7.  ;-)

Trimming trailing mantissa zeros for fp-number output can be controlled by a flag.

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

#59798

minforth@arcor.de wrote:
> Am Mittwoch, 24. Mai 2017 09:21:49 UTC+2 schrieb HAA:
> > minforth@arcor.de wrote:
> > > ...
> > > 0 set-precision  ok  <-- test if this trims
> > > 1e fs.  .  <-- gforth hangs
> >
> > PRECISION under ANS refers to 'significant digits' (see the spec).
> > Displaying zero significant digits is meaningless i.e. an ambiguous condition.
> > Similarly ambiguous is requesting more significant digits than your system
> > can supply.   With this in mind, most forths range-limit SET-PRECISION
> > e.g. 1 MAX  xxx MIN  where xxx is the highest precision the system can supply,
> > say 16 for 64-bit floats.
> >
> > Perhaps you are thinking of 'decimal places'?  ANS has nothing to say about
> > that.  Your system may provide suitable functions or you can write your own.
>
> Sure I know, garbage in, garbage out.
> Anyhow the fp-number wordset spec is short and leaves many things "system specific".
> Also whether trailing zeros are significant or not so that they can be trimmed
> is "application specific".
> ...

Much water has passed under the bridge since ANS.  IMO it's no longer a case
of what did ANS mean, but has it fulfilled the expectations of f/p users.  I expect
f/p output functions similar to what C and Fortran offer and today there are Forths
which provide that.  Do they care whether they conform to ANS?  I suspect not.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web