Poll standings See "VOTING INSTRUCTIONS" below for voting instructions. Systems [ ] conforms to ANS Forth. Gforth bigForth [ ] already implements the proposal in full since release [ ]. Gforth 0.1alpha (Anton Ertl) 4th 3.5c/3.5d (Hans Bezemer) bigForth (since it has had FP support, Bernd Paysan) [ ] implements the proposal in full in a development version. FTC (pfitzen) [ ] will implement the proposal in full in release [ ]. [ ] will implement the proposal in full in some future release. IronForth/JavaForth (Peter Knaggs; currently do not implement FLOAT) FTC (pfitzen) [ ] There are no plans to implement the proposal in full in [ ]. [ ] will never implement the proposal in full. Programmers [ ] I have used (parts of) this proposal in my programs. Hans Bezemer Richard Borrell, WareWorks Ltd. pfitzen [ ] I would use (parts of) this proposal in my programs if the systems I am interested in implemented it. Bernd Paysan Richard Borrell, WareWorks Ltd. [ ] I would use (parts of) this proposal in my programs if this proposal was in the Forth standard. Bernd Paysan pfitzen [ ] I would not use (parts of) this proposal in my programs. Remarks: Bernd Paysan writes: |I don't know if I have actually used this proposal in a program, because I |don't know if I actually exceeded the 1:1 range of conversions from integer to |float, due to the fact that the Forth systems I use (which implement the |proposal) don't provide any diagnostics to tell me. The same is true of Anton Ertl. Peter Knaggs writes: |I would prefer not to reference 12.3.2 in the definition. If necessary it |should be added to the reference list (See). CfV: Author: Charles G. Montgomery 01/07/2016 Votetaker: Anton Ertl 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 precision 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 cannot 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 between floats and integers is exact, by comparing an 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 and similar words 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. Comments: Discussion has called attention to the situation where an integer lies outside the range of representable floating-point values. This proposal clearly calls for the valid extreme floating-point value. A Standard System could not return something like "inf" or "nan". The Forth Standard does not address the use of things like "nan" or "+- inf", which can be useful if they are available from a floating-point implementation. To comply with this proposal, a system might need to test for the condition and provide the required result as the default. At the cost of one more word in the dictionary, another version could be retained as available. A Standard Program should have no problem in testing for the condition and taking any desired action. VOTING INSTRUCTIONS Fill out the appropriate ballot(s) below and mail it/them to the votetaker . Your vote will be published (including your name (without email address) and/or the name of your system) here. You can vote (or change your vote) at any time by mailing to me, and the results will be published here. Note that you can be both a system implementor and a programmer, so you can submit both kinds of ballots. Ballot for systems If you maintain several systems, please mention the systems separately in the ballot. Insert the system name or version between the brackets or in the line below the statement. Multiple hits for the same system are possible (if they do not conflict). [ ] conforms to ANS Forth. [ ] already implements the proposal in full since release [ ]. [ ] implements the proposal in full in a development version. [ ] will implement the proposal in full in release [ ]. [ ] will implement the proposal in full in some future release. [ ] There are no plans to implement the proposal in full in [ ]. [ ] will never implement the proposal in full. If you want to provide information on partial implementation, please do so informally, and I will aggregate this information in some way. Ballot for programmers Just mark the statements that are correct for you (e.g., by putting your name on the line below the statement you agree with). If some statements are true for some of your programs, but not others, please mark the statements for the dominating class of programs you write. [ ] I have used (parts of) this proposal in my programs. [ ] I would use (parts of) this proposal in my programs if the systems I am interested in implemented it. [ ] I would use (parts of) this proposal in my programs if this proposal was in the Forth standard. [ ] I would not use (parts of) this proposal in my programs. If you feel that there is closely related functionality missing from the proposal (especially if you have used that in your programs), make an informal comment, and I will collect these, too. Note that the best time to voice such issues is the RfD stage.