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

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

RfD: D>F and S>F first draft

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

Contents

  RfD: D>F and S>F  first draft C G Montgomery <cgm@physics.utoledo.edu> - 2015-11-21 17:59 -0500
    Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-22 18:25 +1100
      Re: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 06:20 -0800
        Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-23 10:58 +1100
          Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-23 02:57 +0100
            Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-24 13:16 +1100
              Re: D>F and S>F  first draft Paul Rubin <no.email@nospam.invalid> - 2015-11-23 18:49 -0800
                Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-25 11:51 +1100
                  Re: D>F and S>F  first draft Paul Rubin <no.email@nospam.invalid> - 2015-11-24 17:26 -0800
              Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-25 02:43 +0100
                Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-26 12:16 +1100
                  Re: D>F and S>F  first draft Paul Rubin <no.email@nospam.invalid> - 2015-11-25 17:47 -0800
                    Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-26 15:47 +1100
                      Re: D>F and S>F  first draft Paul Rubin <no.email@nospam.invalid> - 2015-11-25 23:07 -0800
                      Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 07:27 +0000
                        Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 09:19 +0000
                        Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-28 04:26 +1100
                          Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-28 11:31 +0000
                            Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-29 20:23 +1100
                              Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-29 20:39 +0100
                                Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-12-05 17:48 +1100
                                  Re: D>F and S>F  first draft Julian Fondren <julian.fondren@gmail.com> - 2015-12-04 23:58 -0800
                                    Re: D>F and S>F  first draft mhx@iae.nl - 2015-12-05 02:19 -0800
                                      Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-05 11:25 +0000
                                        Re: D>F and S>F first draft Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-05 13:11 +0000
                                        Re: D>F and S>F  first draft mhx@iae.nl - 2015-12-05 05:27 -0800
                                          Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-05 15:33 +0000
                                            Re: D>F and S>F  first draft mhx@iae.nl - 2015-12-07 10:10 -0800
                                              Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-09 16:58 +0000
                                      Re: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-12-06 10:23 -0800
                                        Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-06 21:37 +0100
                                  Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-05 19:08 +0100
                              Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-30 08:33 +0000
                      Re: D>F and S>F first draft "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 21:43 -1000
                        Re: D>F and S>F first draft "HAA" <someone@microsoft.com> - 2015-11-28 19:28 +1100
                      Re: D>F and S>F first draft Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-26 11:37 +0000
      Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-22 15:10 +0000
      Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-22 20:48 +0100
        Re: D>F and S>F first draft "Elizabeth D. Rather" <erather@forth.com> - 2015-11-22 13:42 -1000
          Re: D>F and S>F first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-23 11:50 +0000
            Re: D>F and S>F first draft "Elizabeth D. Rather" <erather@forth.com> - 2015-11-23 12:46 -1000
              Forth libraries Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-24 08:55 +0100
    Re: RfD: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 06:33 -0800
      Re: RfD: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-22 16:00 +0000
        Re: RfD: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 08:53 -0800
          Re: RfD: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 09:11 -0800
          Re: RfD: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-22 18:24 +0000
        Re: RfD: D>F and S>F  first draft Paul Rubin <no.email@nospam.invalid> - 2015-11-22 09:07 -0800
          Re: RfD: D>F and S>F  first draft stephen@mpeforth.com (Stephen Pelc) - 2015-11-22 18:10 +0000
          Re: RfD: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-22 18:26 +0000
            Re: RfD: D>F and S>F first draft rickman <gnuarm@gmail.com> - 2015-11-22 13:58 -0500
              Re: RfD: D>F and S>F first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-23 12:34 +0000
                Re: RfD: D>F and S>F first draft Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-23 16:39 +0000
                Re: RfD: D>F and S>F first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-24 03:00 +0100
              Re: RfD: D>F and S>F first draft Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-23 13:48 +0100
                Re: RfD: D>F and S>F first draft mhx@iae.nl - 2015-11-23 05:19 -0800
                  Re: RfD: D>F and S>F first draft mhx@iae.nl - 2015-11-23 16:09 -0800
          Re: RfD: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-22 20:42 +0100
      Re: RfD: D>F and S>F  first draft C G Montgomery <cgm@physics.utoledo.edu> - 2015-11-22 16:43 -0500
        Re: RfD: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 18:40 -0800
          Re: RfD: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 18:51 -0800
          Re: RfD: D>F and S>F  first draft C G Montgomery <cgm@physics.utoledo.edu> - 2015-11-25 15:47 -0500
    Re: RfD: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-22 14:29 +0000
    Re: RfD: D>F and S>F first draft "David N. Williams" <williams@umich.edu> - 2015-11-22 10:41 -0600

Page 1 of 4  [1] 2 3 4  Next page →

#43629 — RfD: D>F and S>F first draft

Author:

Charles G. Montgomery <cgm@physics.utoledo.edu>

Problem:

The current Forth Standard specification for D>F states that an ambiguous 
condition exists if the double number D cannot be precisely represented as 
a floating-point value.
Similarly, the specification for S>F calls for an ambiguous condition if 
the single number N can not be precisely represented as a floating-point 
value.

The purpose of this proposal is to eliminate these ambiguous conditions by 
instead specifying that if no floating-point value is precisely equivalent 
to the provided integer the word provides the floating-point value which 
is closest to the integer.

This is the behavior provided by some Standard Forth systems, and is often 
what is most useful for the programmer.

Preliminary Remarks:

While Forth is largely untyped, it recognizes the distinction between 
integer and floating-point values.  Section 12.3.1.2 says "The internal 
representation of a floating-point number, including the format and 
prescision of the significand and the format and range of the exponent, is 
implementation defined."  This seems to presume that the representation of 
a floating-point value is of the form
    (significand) * (base)^(exponent)  
where (significand), (base), and (exponent) are integers.  Since Section 
12.3.2 refers to  the "least significant bit" in defining "round to 
nearest", (base) is presumably 2.
I am not aware of any Forth which is not consistent with these 
presumptions.
So the "representable values" of floating-point numbers is a countable 
subset of the uncountable real numbers.

Integers in Forth may be signed or unsigned.  Floating point values are 
almost invariably signed, so (significand) includes a sign.  D in D>F is 
presumably signed.

Proposal:

In 2.6.1.1130 D>F  (d -- )(F: -- r) replace 
"r is the floating point equivalent of d.  An ambiguous condition exists 
if d can not be precisely represented as a floating-point value"
with
"r is the floating-point value which is nearest to d in the sense of 
'round to nearest' as given in 12.3.2."

In 12.6.2.2175 S>F  (n -- )(F: -- r) replace 
"r is the floating-point equivalent of the single-cell value n.  An 
ambiguous condition exists if n can not be precisely represented as a 
floating-point value."
with
"r is the floating-point value which is nearest to n in the sense of 
'round to nearest' as given in 12.3.2."

Remove the documentation requirements in section 12.4.1.2 for the no 
longer existing ambiguous conditions from D>F and S>F.

Further Remarks:

D>F is in the FLOATING word set; S>F is in the FLOATING EXT word set.

The reverse operations, F>D and F>S, are unchanged.  For each, the 
Standard includes a note pointing out that rounding a floating-point value 
before using them may be desirable.

No change is needed for the possibly relevant words >FLOAT and REPRESENT.

It remains easy to determine whether the conversion from float to integer 
is precise, by comparing the initial integer value with the result of D>F 
F>D or S>F F>S.

Implementation and Testing:

For any system which provides the FLOATING and FLOATING EXT word sets and 
does not already comply with this proposal it should not be difficult to 
implement.
Whether floating-point support is in hardware or software, if FROUND can 
be provided
it should be no harder to provide the proposed behavior of D>F and S>F.

The intentional flexibility of the Standard in specifying floating point 
internal  representations makes it difficult to provide tests which have 
universal applicability to all Standard systems.

( end of RfD )

regards to all   cgm

[toc] | [next] | [standalone]

#43631 — Re: D>F and S>F first draft

C G Montgomery wrote:
> Author:
>
> Charles G. Montgomery <cgm@physics.utoledo.edu>
>
> Problem:
>
> The current Forth Standard specification for D>F states that an ambiguous
> condition exists if the double number D cannot be precisely represented as
> a floating-point value.
> Similarly, the specification for S>F calls for an ambiguous condition if
> the single number N can not be precisely represented as a floating-point
> value.
>
> The purpose of this proposal is to eliminate these ambiguous conditions by
> instead specifying that if no floating-point value is precisely equivalent
> to the provided integer the word provides the floating-point value which
> is closest to the integer.

IMO all this does is eliminate a range of systems from being able to claim
Standard compliance.  The only gain I can see is that the lucky systems
remaining won't have to document the results they do get.

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

#43634 — Re: D>F and S>F first draft

On Sunday, November 22, 2015 at 1:25:33 AM UTC-6, HAA wrote:
...
> IMO all this does is eliminate a range of systems from being able to claim
> Standard compliance.  The only gain I can see is that the lucky systems
> remaining won't have to document the results they do get.

Besides iForth, which existing Forth systems will this RfD bring out of standards compliance? 

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

#43658 — Re: D>F and S>F first draft

krishna.myneni@ccreweb.org wrote:
> On Sunday, November 22, 2015 at 1:25:33 AM UTC-6, HAA wrote:
> ...
> > IMO all this does is eliminate a range of systems from being able to claim
> > Standard compliance.  The only gain I can see is that the lucky systems
> > remaining won't have to document the results they do get.
>
> Besides iForth, which existing Forth systems will this RfD bring out of standards
> compliance?

I believe this has already been answered by yourself but essentially any
system whose floats occupy the same or fewer bits than doubles.

Let's not forget floating point is primarily about dynamic range and ease
of use.  Precision was the trade-off.  This is reflected in the current
definitions.  Nothing in the definitions *restrict* precision if you have it.

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

#43661 — Re: D>F and S>F first draft

HAA wrote:

> krishna.myneni@ccreweb.org wrote:
>> On Sunday, November 22, 2015 at 1:25:33 AM UTC-6, HAA wrote:
>> ...
>> > IMO all this does is eliminate a range of systems from being able to
>> > claim
>> > Standard compliance.  The only gain I can see is that the lucky systems
>> > remaining won't have to document the results they do get.
>>
>> Besides iForth, which existing Forth systems will this RfD bring out of
>> standards compliance?
> 
> I believe this has already been answered by yourself but essentially any
> system whose floats occupy the same or fewer bits than doubles.

Not at all.  Only if the exponent has not enough bits to represent the full 
range of doubles, the system is in trouble (e.g. with 16 bit half-sized 
floats).

> Let's not forget floating point is primarily about dynamic range and ease
> of use.  Precision was the trade-off.  This is reflected in the current
> definitions.  Nothing in the definitions *restrict* precision if you have
> it.

Ah, that makes your objection clear:  You don't understand what the new 
definition means.  It actually means what you write here: Precision is not 
required, you are allowed to return a rounded result.  That was standard 
before, too, but as the condition was ambiguous, a system could also throw 
an error if no precise representation was possible.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#43693 — Re: D>F and S>F first draft

Bernd Paysan wrote:
>
> Ah, that makes your objection clear:  You don't understand what the new
> definition means.  It actually means what you write here: Precision is not
> required, you are allowed to return a rounded result.

I didn't read it that way, but if correct, I see no practical difference between
'rounding' to some system-dependent fp value and an ambiguous condition.

> That was standard
> before, too, but as the condition was ambiguous, a system could also throw
> an error if no precise representation was possible.

Even if they did, it's not your problem.  You didn't stop writing 32 bit programs
because the standard supported 16 bit systems.  Similarly there's nothing
preventing you implementing IEEE specs if that's what you need.

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

#43694 — Re: D>F and S>F first draft

"HAA" <someone@microsoft.com> writes:
> I didn't read it that way, but if correct, I see no practical
> difference between 'rounding' to some system-dependent fp value and an
> ambiguous condition.

Think of a number around 2**60 which can be approximated in an IEEE
double but not represented exactly.  Converting it to the closest double
is the sane and reasonable thing to do.  Ambiguous condition means the
implementing could instead convert it to a random number, or infinity,
or throw an exception, or whatever.  That's not good.

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

#43713 — Re: D>F and S>F first draft

Paul Rubin wrote:
> "HAA" <someone@microsoft.com> writes:
> > I didn't read it that way, but if correct, I see no practical
> > difference between 'rounding' to some system-dependent fp value and an
> > ambiguous condition.
>
> Think of a number around 2**60 which can be approximated in an IEEE
> double but not represented exactly.  Converting it to the closest double
> is the sane and reasonable thing to do.  Ambiguous condition means the
> implementing could instead convert it to a random number, or infinity,
> or throw an exception, or whatever.  That's not good.

Ambiguous condition is about the *implementor* - not the user.  It means
the implementor can choose whatever action he feels is appropriate for
the situation specified.  The only requirement the standard makes is that
he document it.  Users then have the choice of going with that system or
choosing another if they don't like the behavior.

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

#43714 — Re: D>F and S>F first draft

"HAA" <someone@microsoft.com> writes:
>> > I see no practical difference between 'rounding' to some
>> > system-dependent fp value and an ambiguous condition.
> Ambiguous condition ... means the implementor can choose whatever
> action he feels is appropriate...  Users then have the choice of going
> with that system or choosing another if they don't like the behavior.

You're saying there's no practical difference between a) requiring a
standard system to do something sane, and b) letting it do something
crazy while still calling itself standard, and telling the user to pick
a different system if they want sanity?  I think Elizabeth gave the
example that in Colorforth, OR means exclusive or.  That's fine in the
greater scheme of things, but I think it's best for it to be considered
nonstandard.

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

#43715 — Re: D>F and S>F first draft

HAA wrote:

> Bernd Paysan wrote:
>>
>> Ah, that makes your objection clear:  You don't understand what the new
>> definition means.  It actually means what you write here: Precision is
>> not required, you are allowed to return a rounded result.
> 
> I didn't read it that way, but if correct, I see no practical difference
> between 'rounding' to some system-dependent fp value and an ambiguous
> condition.

Yes, every sane system would choose round to nearest.  The insane systems 
can do whatever they want.  I want to keep it that way, but the insane 
systems should not be allowed to say "I'm standard".

>> That was standard
>> before, too, but as the condition was ambiguous, a system could also
>> throw an error if no precise representation was possible.
> 
> Even if they did, it's not your problem.

When I write a portable program that uses D>F on some larger integers, of 
course it is my problem.  My program will quite likely not work on such a 
system.

> You didn't stop writing 32 bit programs
> because the standard supported 16 bit systems.

Sure, you always can document your program to have an environmental 
dependency.

> Similarly there's nothing
> preventing you implementing IEEE specs if that's what you need.

Well, that's what I'm doing with the current situation of Forth: I'm 
maintaining my own system and making sure that its quality of implementation 
matches with my needs.

Result: Non-portable stuff.

IMHO, raising the quality of implementation of every standard system makes 
it easier for me to write portable programs and libraries.

If you don't want to write portable programs, you are probably not 
interested in a standard anyways.  I am.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#43792 — Re: D>F and S>F first draft

Bernd Paysan wrote:
> HAA wrote:
>
> > Bernd Paysan wrote:
> >>
> >> Ah, that makes your objection clear:  You don't understand what the new
> >> definition means.  It actually means what you write here: Precision is
> >> not required, you are allowed to return a rounded result.
> >
> > I didn't read it that way, but if correct, I see no practical difference
> > between 'rounding' to some system-dependent fp value and an ambiguous
> > condition.
>
> Yes, every sane system would choose round to nearest.  The insane systems
> can do whatever they want.  I want to keep it that way, but the insane
> systems should not be allowed to say "I'm standard".

You have a 16 bit forth with 32 bit floats.  You run a program that involves a
calculation that exceeds the precision of your system e.g.

    2147483647. d>f f.

Three possible outcomes spring to mind:

    2147484000.  ok
    +INF  ok
    Error: Insufficient precision

Which of the above do you consider "insane"?

If the program expected the answer 2147483647 then you have an
'ambiguous condition' and IMO it makes *no difference* which of the
above actions a system takes because the situation is terminal.

There are systems which don't abort when presented with a divide-by-zero.
Are these also "insane" and should they be excluded from the Standard?

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

#43793 — Re: D>F and S>F first draft

"HAA" <someone@microsoft.com> writes:
>     2147483647. d>f f.
> Three possible outcomes spring to mind:
>     2147484000.  ok
>     +INF  ok
>     Error: Insufficient precision
> Which of the above do you consider "insane"?

The second and third.

> If the program expected the answer 2147483647 then you have an
> 'ambiguous condition' 

Actually you have a design error, since floating point numbers have
limited precision, and if you're using them you're supposed to know
that.  That's why 2147484000 (or whatever the nearest float is) is the
right answer.

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

#43796 — Re: D>F and S>F first draft

Paul Rubin wrote:
> "HAA" <someone@microsoft.com> writes:
> >     2147483647. d>f f.
> > Three possible outcomes spring to mind:
> >     2147484000.  ok
> >     +INF  ok
> >     Error: Insufficient precision
> > Which of the above do you consider "insane"?
>
> The second and third.

+INF shouldn't have been included. My mistake.

> > If the program expected the answer 2147483647 then you have an
> > 'ambiguous condition'
>
> Actually you have a design error, since floating point numbers have
> limited precision, and if you're using them you're supposed to know
> that.  That's why 2147484000 (or whatever the nearest float is) is the
> right answer.

What if it's an accounting program.  Is it still the 'right answer'?
It's not a design error because the program works fine on a system
with higher precision floats.

The point is D>F for this system encountered a situation where it
couldn't provide the expected result.  That's what's meant by
ambiguous condition.  You can dictate the action systems should
take on an ambiguous condition but you cannot eliminate them or
their flow on effects.

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

#43804 — Re: D>F and S>F first draft

"HAA" <someone@microsoft.com> writes:
> What if it's an accounting program.  Is it still the 'right answer'?
> It's not a design error because the program works fine on a system
> with higher precision floats.

It's still the right answer because if doubles are part of the
requirement and you used a system with singles, it's at least a
deployment error if not a design error.

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

#43806 — Re: D>F and S>F first draft

"HAA" <someone@microsoft.com> writes:
>What if it's an accounting program.  Is it still the 'right answer'?

If it is not, why are you trying to convert it into FP?  Anyway, you
can get a checking version of D>F easily as follows:

: d?f ( d -- r )
  2dup d>f fdup f>d d= 0= -41 and throw ;

Note that this works with the proposed D>F, but not necessarily with
the current one (an ambiguous condition makes no guarantee at all
about what happens), although I cannot think of a plausible failure
mode (but my imagination in that direction is quite limited and has
been surprised by the nonsense that GCC and LLVM maintainers have
done).

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43819 — Re: D>F and S>F first draft

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>"HAA" <someone@microsoft.com> writes:
>>What if it's an accounting program.  Is it still the 'right answer'?
>
>If it is not, why are you trying to convert it into FP?  Anyway, you
>can get a checking version of D>F easily as follows:
>
>: d?f ( d -- r )
>  2dup d>f fdup f>d d= 0= -41 and throw ;
>
>Note that this works with the proposed D>F, but not necessarily with
>the current one (an ambiguous condition makes no guarantee at all
>about what happens), although I cannot think of a plausible failure
>mode (but my imagination in that direction is quite limited and has
>been surprised by the nonsense that GCC and LLVM maintainers have
>done).

Thinking some more, here's a typical GCC-ish failure mode:

(Forth-2012) D>F is ambiguous when F>D would not return the original d,
so a GCC-ish Forth compiler could "optimize" this to:

: d?f ( d -- r )
  2dup d>f 2dup d= 0= -41 and throw ;

and then "optimize" this to

: d?f ( d -- r ) d>f ;

Guaranteed to work for all cases where (Forth-2012) D>F is not
ambiguous, and (in GCC maintainer thinking) other cases are bugs in
the program and should not occur.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43872 — Re: D>F and S>F first draft

Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >What if it's an accounting program.  Is it still the 'right answer'?
>
> If it is not, why are you trying to convert it into FP?  Anyway, you
> can get a checking version of D>F easily as follows:

Ambiguous conditions can often be avoided in programs but they
can't be eliminated from standard definitions without adversely
impacting implementations.

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

#43898 — Re: D>F and S>F first draft

"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> "HAA" <someone@microsoft.com> writes:
>> >What if it's an accounting program.  Is it still the 'right answer'?
>>
>> If it is not, why are you trying to convert it into FP?  Anyway, you
>> can get a checking version of D>F easily as follows:
>
>Ambiguous conditions can often be avoided in programs but they
>can't be eliminated from standard definitions without adversely
>impacting implementations.

The proposed change won't affect many implementations.  For the rest,
I would not call the impact "adverse", rather on the contrary.  Also,
there is no way that a standard program can avoid the ambiguous
condition that is present in D>F in Forth-2012 except by not using D>F
at all.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43929 — Re: D>F and S>F first draft

Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >Anton Ertl wrote:
> >> "HAA" <someone@microsoft.com> writes:
> >> >What if it's an accounting program.  Is it still the 'right answer'?
> >>
> >> If it is not, why are you trying to convert it into FP?  Anyway, you
> >> can get a checking version of D>F easily as follows:
> >
> >Ambiguous conditions can often be avoided in programs but they
> >can't be eliminated from standard definitions without adversely
> >impacting implementations.
>
> The proposed change won't affect many implementations.

I don't know many it will affect because it's not clear to me (and
perhaps others) what behavior the proposal expects.  How should
systems respond in the case of gross errors in D>F ?  Charles
hasn't clarified the point.  In fact he seems to have disappeared.

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

#43940 — Re: D>F and S>F first draft

HAA wrote:
> I don't know many it will affect because it's not clear to me (and
> perhaps others) what behavior the proposal expects.

Round to nearest even, as the proposal says.

> How should
> systems respond in the case of gross errors in D>F?

What kind of "gross error" do you expect? d has a very specific range (cell-
size dependent), and any D is well defined within that range.  So unless you 
use float16 on a system with more than 16 bit integers (more than 32 bit 
doubles), all possible ds fit without overflow, and only need rounding.

> Charles hasn't clarified the point.  In fact he seems to have disappeared.

It's not the job description of a proposal writer to beat all the trolls to 
death with his own club.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web