Unneeded restriction in FASINH

Poll standings

See below for voting instructions.

Systems

[ ] conforms to ANS Forth.
  iForth (Marcel Hendrix)
  VFX Forth for Windows, Linux, DOS (Stephen Pelc)
[ ] already implements the proposal in full since release [ ].
  iForth (Marcel Hendrix)
  4th 3.5d with ANS Float (Hans Bezemer)
  VFX Forth for Windows, Linux, DOS 3.7 (Stephen Pelc)
  kForth before 06-12-1999 (Krishna Myneni)
[ ] implements the proposal in full in a development version.
  4th with ZEN Float (Hans Bezemer)
[ ] 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.

Programmers

[ ] I have used (parts of) this proposal in my programs.
  Marcel Hendrix
  Krishna Myneni
[ ] I would use (parts of) this proposal in my programs if the systems
     I am interested in implemented it.
  Marcel Hendrix
  David N. Williams
  Hans Bezemer
[ ] I would use (parts of) this proposal in my programs if this
     proposal was in the Forth standard.
  Marcel Hendrix
  David N. Williams
[ ] I would not use (parts of) this proposal in my programs.

Informal results

Proposal

Author: Charles G. Montgomery

Problem

The ANS definition is:

  12.6.2.1487 FASINH   
 f-a-cinch FLOATING EXT 
 
        ( F: r1 -- r2 ) 
        or ( r1 -- r2 )

 r2 is the floating-point value whose hyperbolic sine is r1.
 An ambiguous condition exists if r1 is less than zero.

Proposal

The second sentence is unnecessary, and should be deleted.

Remarks

(This ought to be an easy one.)

The arc hyperbolic sine is an odd function, perfectly well-behaved for
negative real arguments.  asinh(-x) = - asinh(x) .

I would be quite surprised if any Forth sysytem which correctly implements
FASINH doesn't already correctly handle negative arguments.

Experience

The proposed behavior is provided in Gforth and Win32Forth.
There have been no reports of systems with conflicting behavior.

Voting instructions

Fill out the appropriate ballot(s) below and mail it/them to me <anton@mips.complang.tuwien.ac.at>. 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.

Anton Ertl