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

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

Bernd Paysan wrote:
> 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.

'round to nearest even' refers to the *direction* the result should take if it
cannot be exactly represented.  We're talking errors of 1 bit.

Implicit in every description of rounding I've seen is that the number being
rounded is numerically correct to begin with.

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

I gave you a real example:

    2147483647. d>f f.  2147484000.  ok

In your view is the above 'rounding'?  Or is it an 'ambiguous condition' which
the Standard supports with the system throw code:

    -41 "loss of precision"

I have no doubt it is the latter.

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

He appears to be leaving that job to you.

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

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

On Saturday, December 5, 2015 at 12:49:25 AM UTC-6, HAA wrote:
> I gave you a real example:
> 
>     2147483647. d>f f.  2147484000.  ok
> 
> In your view is the above 'rounding'?  Or is it an 'ambiguous condition' which
> the Standard supports with the system throw code:
> 
>     -41 "loss of precision"
> 
> I have no doubt it is the latter.

How is this any different from

  \ 32-bit cells
  2147483647 1+ . -2147483648  ok

  \ 64-bit cells
  2147483647 1+ 2147483648  ok

Which is currently treated by.. assuming that people understand
computer math.  And documenting cell assumptions.

-- Julian

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

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

On Saturday, December 5, 2015 at 8:58:33 AM UTC+1, Julian Fondren wrote:
> On Saturday, December 5, 2015 at 12:49:25 AM UTC-6, HAA wrote:
> > I gave you a real example:
> > 
> >     2147483647. d>f f.  2147484000.  ok
> > 
> > In your view is the above 'rounding'?  Or is it an 'ambiguous condition' which
> > the Standard supports with the system throw code:
> > 
> >     -41 "loss of precision"
> > 
> > I have no doubt it is the latter.
> 
> How is this any different from
> 
>   \ 32-bit cells
>   2147483647 1+ . -2147483648  ok
> 
>   \ 64-bit cells
>   2147483647 1+ 2147483648  ok
> 
> Which is currently treated by.. assuming that people understand
> computer math.  And documenting cell assumptions.
> 
> -- Julian

> On Saturday, December 5, 2015 at 12:49:25 AM UTC-6, HAA wrote:
>> I gave you a real example:
>> 
>>     2147483647. d>f f.  2147484000.  ok
>> 
>> In your view is the above 'rounding'?  Or is it an 'ambiguous condition' which
>> the Standard supports with the system throw code:
>> 
>>     -41 "loss of precision"
>> 
>> I have no doubt it is the latter.

> How is this any different from

>  \ 32-bit cells
>  2147483647 1+ . -2147483648  ok

>  \ 64-bit cells
>  2147483647 1+ 2147483648  ok

> Which is currently treated by.. assuming that people understand
> computer math.  And documenting cell assumptions.

I agree with both HAA's *and* your observation. Forth benefits
from deferring hairy dilemmas to the programmer. 

To one looking at bits and bytes "2147483647. d>f f.  2147484000."
is, given a 64bit system with 80bit floats, the wrong answer, as is

1152921504606846976 1 + s>f f.  1152921504606850000.  ok
compared to
1152921504606846976 1 + s>f f. 1.152921504606846977e18  ok

"Rounding" these results only results in added confusion, especially
as it still needs to be convincingly explained where a 'rounded'
result helps (especially when relied on unthinkingly).

-marcel

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

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

mhx@iae.nl writes:
>On Saturday, December 5, 2015 at 8:58:33 AM UTC+1, Julian Fondren wrote:
>> On Saturday, December 5, 2015 at 12:49:25 AM UTC-6, HAA wrote:
>> > I gave you a real example:
>> > 
>> >     2147483647. d>f f.  2147484000.  ok
>> > 
>> > In your view is the above 'rounding'?

If the FP number that is printed as "2147484000." is the nearest FP
number, then this is rounding and would be the correct result
according to the proposal.

>> > Or is it an 'ambiguous condition' which
>> > the Standard supports with the system throw code:
>> > 
>> >     -41 "loss of precision"

In the Forth-2012 it is an ambiguous condition, which means that the
system can do anything.  It can throw -41 (but no system does AFAIK),
it can return 2147484000e, it can return something that is not the
nearest FP number, or it can do something else.  OTOH, if the proposal
is accepted, the programmer can check whether the conversion was exact
or did round, and throw if it was not exact.

>To one looking at bits and bytes "2147483647. d>f f.  2147484000."
>is, given a 64bit system with 80bit floats, the wrong answer,

It's the wrong answer for both the current and the proposed F>D,
because 2147483647 can be represented exactly in 80-bit floats (which
have a 64-bit mantissa).

> as is
>
>1152921504606846976 1 + s>f f.  1152921504606850000.  ok
>compared to
>1152921504606846976 1 + s>f f. 1.152921504606846977e18  ok

Again, 1152921504606846977 can be represented exactly in 80-bit FP
numbers, so on such a system the correct result is again the same
without and with this proposal.

OTOH, if you have a system with IEEE 64-bit floats (53-bit mantissa),
1152921504606846977 cannot be represented exactly as floating-point
number.  With the current S>F, the programmer cannot rely on anything
in that case; a program that does that is not a standard program, the
system can do anything, and the programmer has no portable way to
prevent that from happening.  With the proposed change, the programmer
is guaranteed to get the closest FP number, so for a system above the
following

1152921504606846977 s>f f>s .

outputs 1152921504606846976 (using "F>S ." avoids the problem of f. and
other FP output words being somewhat approximate).

>"Rounding" these results only results in added confusion, especially
>as it still needs to be convincingly explained where a 'rounded'
>result helps (especially when relied on unthinkingly).

If it does not help, at least you can determine that the result is not
exact, which you cannot do with an ambiguous result.

I remember one case of using D>F: to get the square root of an integer
with D>F FSQRT F>D.  IIRC I did make an analysis to determine that any
roundings introduced in this process do not cause problems for my
application.

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

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

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

<SNIP>
>I remember one case of using D>F: to get the square root of an integer
>with D>F FSQRT F>D.  IIRC I did make an analysis to determine that any
>roundings introduced in this process do not cause problems for my
>application.

Roundings did present problems because the algorithm needed floor(sqrt(x)).

I remember that. It was yapcp. I was annoyed because here plus or minus
one errors would invalidate the result (as compared to measuring a tower
within a few micron, where nobody cares).
The check you did was only valid in the context of the particular
implementation of gforth, which is not satisfactory IMHO.
The alternative is of course an integer DSQRT that is not at all hard.

In a number of euler problem integer square roots pop up. The
iteration is fast, but it has one problem: the initial value.
In most situations where I used the previous outcome of a square
root as initial value, the number of iterations went down to an
average of about two.

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

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

On Saturday, December 5, 2015 at 12:59:36 PM UTC+1, Anton Ertl wrote:
> mhx@iae.nl writes:
> >On Saturday, December 5, 2015 at 8:58:33 AM UTC+1, Julian Fondren wrote:
> >> On Saturday, December 5, 2015 at 12:49:25 AM UTC-6, HAA wrote:
[..]
> If it does not help, at least you can determine that the result is not
> exact, which you cannot do with an ambiguous result.

Then instead of creating a mess, let's consider prescribing 
that D>F returns NaN when conversion is inexact. The payload
of this NaN might contain a suitable approximation (just a 
suggestion, I would not use it myself).

-marcel

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

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

mhx@iae.nl writes:
>On Saturday, December 5, 2015 at 12:59:36 PM UTC+1, Anton Ertl wrote:
>> mhx@iae.nl writes:
>> >On Saturday, December 5, 2015 at 8:58:33 AM UTC+1, Julian Fondren wrote:
>> >> On Saturday, December 5, 2015 at 12:49:25 AM UTC-6, HAA wrote:
>[..]
>> If it does not help, at least you can determine that the result is not
>> exact, which you cannot do with an ambiguous result.
>
>Then instead of creating a mess, let's consider prescribing 
>that D>F returns NaN when conversion is inexact. The payload
>of this NaN might contain a suitable approximation (just a 
>suggestion, I would not use it myself).

There is no requirement that the system uses an FP representation that
supports NaNs (much less NaNs with a payload).  There is no standard
way to recognize a NaN nor a standard way to extract a payload.

Even if we had all that, what advantage would your variant buy that
justifies complicating the implementation with this stuff?

And if the behaviour you suggest is better than the proposed
behaviour, why do AMD and Intel implement the proposed behaviour and not
your behaviour in the cvtsi2sd (and cvtsi2ss) instruction?

|When conversion is inexact, the value returned is rounded according
|to the rounding control bits in the MXCSR register.
<http://www.felixcloutier.com/x86/CVTSI2SD.html>

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

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

On Saturday, December 5, 2015 at 4:55:27 PM UTC+1, Anton Ertl wrote:
> mhx@iae.nl writes:
> >On Saturday, December 5, 2015 at 12:59:36 PM UTC+1, Anton Ertl wrote:
> >> mhx@iae.nl writes:
> >> >On Saturday, December 5, 2015 at 8:58:33 AM UTC+1, Julian Fondren wrote:
> >> >> On Saturday, December 5, 2015 at 12:49:25 AM UTC-6, HAA wrote:
[..]
> And if the behaviour you suggest is better than the proposed
> behaviour, why do AMD and Intel implement the proposed behaviour and not
> your behaviour in the cvtsi2sd (and cvtsi2ss) instruction?

These instructions do not convert 128-bit integers to 
80-bit floats, and do not work with the FPU stack.
 
CVTSI2SD
IF 64-Bit Mode And OperandSize = 64
THEN
    DEST[63:0] ← Convert_Integer_To_Double_Precision_Floating_Point(SRC[63:0]);
ELSE
    DEST[63:0] ← Convert_Integer_To_Double_Precision_Floating_Point(SRC[31:0]);
FI;
DEST[VLMAX-1:64] (Unmodified)

-marcel

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

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

mhx@iae.nl writes:
>On Saturday, December 5, 2015 at 4:55:27 PM UTC+1, Anton Ertl wrote:
>> And if the behaviour you suggest is better than the proposed
>> behaviour, why do AMD and Intel implement the proposed behaviour and not
>> your behaviour in the cvtsi2sd (and cvtsi2ss) instruction?
>
>These instructions do not convert 128-bit integers to=20
>80-bit floats, and do not work with the FPU stack.

True, so you cannot use them directly for converting 128-bit integers
to FP singles or doubles, and probably not at all for converting
integers to 80-bit floats.  But it seems that the designers of these
instructions thought that getting the FP number closest to the integer
was a useful operation, and apparently nobody at Intel or AMD felt
that producing a NaN with some kind of payload in that situation is
particularly useful.  After all, if rounding on an inexact result is
acceptable for, say, multiplication, why should it be "a mess" on
converting from an integer?

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

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

Not at all. If you want exact reproducibility in floating point computations, you would have to require all systems use the same representation for fp numbers, which would be a ridiculous requirement. The proposal to round to nearest is very sensible, although I would have liked to see a more precise statement of what is meant by rounding to nearest in this context.

Krishna

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

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

krishna.myneni@ccreweb.org wrote:

> Not at all. If you want exact reproducibility in floating point
> computations, you would have to require all systems use the same
> representation for fp numbers, which would be a ridiculous requirement.
> The proposal to round to nearest is very sensible, although I would have
> liked to see a more precise statement of what is meant by rounding to
> nearest in this context.

Well, he referred to 12.3.2, which says

“Round to nearest” means round the result of a floating-point operation to 
the representable value nearest the result. If the two nearest representable 
values are equally near the result, the one having zero as its least 
significant bit shall be delivered.

That should be pretty clear, and referring to text elsewhere in the standard 
is a good idea.

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

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

HAA wrote:
> I gave you a real example:
> 
>     2147483647. d>f f.  2147484000.  ok
> 
> In your view is the above 'rounding'?

Yes, sure.  Floating point has finite precision, and that means the ULP of a 
big number is significantly greater than 1.

> Or is it an 'ambiguous condition'
> which the Standard supports with the system throw code:
> 
>     -41 "loss of precision"
> 
> I have no doubt it is the latter.

Well, there's no exception thrown in the example above, it's obviously 
rounded.  The current standard allows either, rounding or thowing an 
exception, and possible more things ("ambiguous condition" is simply not 
defined).

>> It's not the job description of a proposal writer to beat all the trolls
>> to death with his own club.
> 
> He appears to be leaving that job to you.

Yes.  It is pretty obvious that you simply don't understand what "rounding" 
means with floating point numbers.

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

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

"HAA" <someone@microsoft.com> writes:
>How should
>systems respond in the case of gross errors in D>F ?

If there are any errors in D>F, the system implementor should correct
them.

If you mean that the d cannot be represented precisely (or exactly?) as
r, the system should produce the r nearest to the d.  That's specified
clearly in the proposal.

And with this proposal you can also check whether the conversion is
exact, as I showed, or you can also check whether the deviation is
within bounds acceptable for your application.  None of that is
standard with the current D>F.

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

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

On 11/25/15 6:47 PM, HAA wrote:
> 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.

Accounting programs have no business using floating point. FP introduces 
too many errors. Fixed-point is precise. FP is for cases when you have 
huge differences in scale; accounting has none.

Cheers,
Elizabeth


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

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

Elizabeth D. Rather wrote:
>
> Accounting programs have no business using floating point. FP introduces
> too many errors. Fixed-point is precise. FP is for cases when you have
> huge differences in scale; accounting has none.

You can tell people not to use fp but while D>F and friends remain ANS is
obliged to address their limitations.

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

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

"HAA" <someone@microsoft.com> writes:

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

Using floats in an accounting program is a design error.

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]

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

"HAA" <someone@microsoft.com> writes:
>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.

A very system-centric view.  Maybe you should also consider the effect
on programs.

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

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

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.

Three questions:

1. Proof of existence: Which system is no longer standard?  An actual 
example would be helpful.  Just claiming that there would be systems 
affected is just theoretical.  We had this discussion with the two's 
complement and the 1 CHARS = 1 thing; for the 1 CHARS = 1, there were actual 
examples.

2. Proof of complicatedness: Would it be an awful lot of work to make it 
compilant?  If so, why?

3. As the popular systems now are already using it that way, programs 
probably will fail if the reaction of the system is different.

I think the general idea is that if you make everything ambiguous, anybody 
can claim he's a standard system.  It would reduce our work as standard 
committee a lot.  E.g. we could write "A Forth system is a system where you 
input a sequence of space spearated words, which operate on stacks.  What 
precicely happens with that sequence is an ambiguous condition.  All 
operations may be named differently."  Hooray, everybody has his standard 
Forth system.  But nobody can write standard programs.

So we have two possible directions: More ambiguous behavior reduces the 
usefulness for programmers and increases the amount of systems that can 
claim compliance.  Less ambiguous behavior increases the pressure on system 
implementer to be compliant, and reduces the work for programmer.

There has been a at least 20 year long complaint about the lack of Forth 
libraries, but if we can't make Forth systems sufficiently compatible with 
each others by leaving too many things ambiguous, that situation will stay 
that way.

Some things should be implementation details, and some things should be open 
to experiments.

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

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

On 11/22/15 9:48 AM, Bernd Paysan wrote:
> There has been a at least 20 year long complaint about the lack of Forth
> libraries, but if we can't make Forth systems sufficiently compatible with
> each others by leaving too many things ambiguous, that situation will stay
> that way.

It's more like 40 years. I do not think the problem is with "ambiguity," 
it's because a lot of people would rather write "yet another Forth" and 
the rest are too busy writing real-world applications.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

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

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 11/22/15 9:48 AM, Bernd Paysan wrote:
>> There has been a at least 20 year long complaint about the lack of Forth
>> libraries, but if we can't make Forth systems sufficiently compatible with
>> each others by leaving too many things ambiguous, that situation will stay
>> that way.
>
>It's more like 40 years. I do not think the problem is with "ambiguity," 
>it's because a lot of people would rather write "yet another Forth"

Now why is that?  Why do people like to write yet another system when
they are dealing with Forth, while they like to write libraries when
they are dealing with Python?  Maybe it's because the Forth standard
makes it hard to write portable libraries (in order to make it easier
to claim that your system is standard), while Python makes it easier.

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

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

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

csiph-web