Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #43629 > unrolled thread
| Started by | C G Montgomery <cgm@physics.utoledo.edu> |
|---|---|
| First post | 2015-11-21 17:59 -0500 |
| Last post | 2015-11-22 10:41 -0600 |
| Articles | 4 on this page of 64 — 14 participants |
Back to article view | Back to comp.lang.forth
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 4 of 4 — ← Prev page 1 2 3 [4]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2015-11-22 18:51 -0800 |
| Message-ID | <1e7a5b7e-b297-49da-8eed-f93278454e44@googlegroups.com> |
| In reply to | #43662 |
On Sunday, November 22, 2015 at 8:40:13 PM UTC-6, krishna...@ccreweb.org wrote: > On Sunday, November 22, 2015 at 3:43:33 PM UTC-6, C G Montgomery wrote: > > krishna.myneni@ccreweb.org krishna.myneni@ccreweb.org wrote: > > > ... > > > > > > Change "precise" to exact. > > > > > I don't see the benefit. > > ... > > I want to respond to each of your points after some further thought, but this one deserves some immediate attention, particularly because the word "precision" is being thrown about loosely in this thread. > > The floating point representation is finite. There are a finite number of bits in the significand and in the exponent. Except for certain numbers, a floating point number is always "precise" to the number of bits in the significand. The unit of least precision defines the precision of the number. The fp representation may also be considered to give an exact representation of an integer or other real number, despite the finite number of bits, for certain numbers when using more bits in the significand gives no change to the binary number. > > A precise representation does not imply an exact representation. The necessity for revising the D>F spec arose from the implication in the existing standard that the floating point number must be an exact representation of the double number, instead of specifying that it must give a precise representation to the least unit of precision. > > Krishna As an example, consider the following double integer number, which you might not expect an exact representation in IEEE 32-bit floating point: 9999999933815812510711506376257961984. Let's check: variable r32 ok 9999999933815812510711506376257961984. d>f r32 sf! ok r32 sf@ f>d ud. 9999999933815812510711506376257961984 ok KM
[toc] | [prev] | [next] | [standalone]
| From | C G Montgomery <cgm@physics.utoledo.edu> |
|---|---|
| Date | 2015-11-25 15:47 -0500 |
| Message-ID | <n356kg$h8b$1@dont-email.me> |
| In reply to | #43662 |
krishna.myneni@ccreweb.org krishna.myneni@ccreweb.org wrote: > On Sunday, November 22, 2015 at 3:43:33 PM UTC-6, C G Montgomery wrote: >> krishna.myneni@ccreweb.org krishna.myneni@ccreweb.org wrote: >> > ... >> > >> > Change "precise" to exact. >> > >> I don't see the benefit. >> ... > > I want to respond to each of your points after some further thought, but > this one deserves some immediate attention, particularly because the > word "precision" is being thrown about loosely in this thread. > > The floating point representation is finite. There are a finite number > of bits in the significand and in the exponent. Except for certain > numbers, a floating point number is always "precise" to the number of > bits in the significand. The unit of least precision defines the > precision of the number. The fp representation may also be considered to > give an exact representation of an integer or other real number, despite > the finite number of bits, for certain numbers when using more bits in > the significand gives no change to the binary number. > > A precise representation does not imply an exact representation. The > necessity for revising the D>F spec arose from the implication in the > existing standard that the floating point number must be an exact > representation of the double number, instead of specifying that it must > give a precise representation to the least unit of precision. > > Krishna I appreciate the distinction you are making. But it is not always observed. The Forth standard says "cannot be precisely represented as a floating point value". I was following that. regards cgm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-22 14:29 +0000 |
| Message-ID | <2015Nov22.152931@mips.complang.tuwien.ac.at> |
| In reply to | #43629 |
C G Montgomery <cgm@physics.utoledo.edu> writes:
>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."
Looks good to me.
>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.
Actually FROUND is relatively easy to provide if you have
round-to-nearest/even addition:
#define X (1024.*1024.*1024.*1024.*1024.*8.)
if (r<0.0)
return (r+X)-X;
else
return (r-X)+X;
The X here is defined for IEEE doubles. But that does not help
implementing the rounding for D>F and S>F. Still, e.g., Intel CPUs
provide various instructions for converting that round to nearest.
One problem is to avoid double rounding if you have to deal with more
integer bits than these instructions handle: If the conversion for the
most significant part already rounds in the wrong direction, adding
the conversion of the least significant part afterwards will not
correct that. The current Gforth code contains an implementation
variant that has this problem.
>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.
Well, testing that
1 MAX-N D>F
gives the same result as
0 MAX-N D>F 1e f+
should be better than nothing.
- 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]
| From | "David N. Williams" <williams@umich.edu> |
|---|---|
| Date | 2015-11-22 10:41 -0600 |
| Subject | Re: RfD: D>F and S>F first draft |
| Message-ID | <n2sr3g$2ev$1@dont-email.me> |
| In reply to | #43629 |
I agree that this would be a good clarification of the standard, up to
the kind of wordsmithing that people are suggesting.
For reference, below is the text about D>F from the last available
online draft of the IEEE floating-point proposal from 2009, which was
vigorously discussed in this forum. It was not finished enough to be an
actual candidate for standardization, but was far enough along to serve
as a resource for IEEE floating point library implementers.
Note that this proposal was specifically about IEEE 754 floating point.
Hence the language:
1) "it shall be rounded according to the current rounding mode".
Charles' language
2) "nearest to n in the sense of 'round to nearest' as given in 12.3.2. "
corresponds to the first of the five IEEE 754-2008 rounding modes, which
is also the IEEE default:
roundTiesToEven
roundTowardPositive
roundTowardNegative
roundTowardZero
roundTiesToAway
The first four of these are typically implemented in desktop hardware.
I think the language 2) is consistent enough with IEEE, since the
concept of "current rounding mode" does not exist in the current Forth
standard. It would presumably mean that any future IEEE fp optional
standard word set would have to declare as an environmental dependency
that round to nearest is only the default among its rounding modes for
D>F. (It wouldn't be practical to use a different name.) That's an
argument for doing IEEE fp word sets as libraries instead of part of the
standard.
-- David
-----------------------------------------
PROPOSAL FOR AN OPTIONAL IEEE 754, BINARY
FLOATING-POINT WORD SET
version 0.5.4a
29-Aug-09
http://www.umich.edu/~williams/archive/temp/ieee-fp-0.5.4a.txt
----------
D>F ( d -- ) ( f: -- r )
The result r is the floating-point equivalent of d. If
conversion of d cannot be represented precisely in the
default fp format, it shall be rounded according to the
current rounding mode, and the inexact or overflow exception
shall be handled just as for arithmetic operations. See
IEEE 754-2008 5.4.1, "Arithmetic operations",
formatOf-convertFromInt(int).
[**RATIONALE
Default handling for overflow/inexact is given by IEEE 754-2008
7.4/7.6. The fp status flags are set, and overflow produces
+/-infinity, while inexact rounds. Default overflow handling
sets the inexact flag as well.
Note that d is always in range for any of the formats binary32,
binary64, binary80, and binary128, for 32- or 64-bit systems.
A programmer can assume that
( d) 2DUP D>F F>D D= ( flag)
results in a true flag *only* when |d| < 2^(p+1), where p is the
format precision, so that rounding does not occur. Rounding
does occur, for example, with 32-bit systems and binary64, when
|d| >= 2^54.
]
----------
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.forth
csiph-web