Newsgroups: comp.lang.apl
Path: watmath!watserv1!utgpu!news-server.csri.toronto.edu!torsqnt!jtsv16!itcyyz!yrloc!rbe
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Numeric/character conversion primitives
Message-ID: <1992Feb19.165508.14679@yrloc.ipsa.reuter.COM>
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Wed, 19 Feb 92 16:55:08 GMT

Recent posters here have sneered at the utility of character to numeric
and numeric to character formatting primitives, on the basis of 
perceived utility and performance. 

Some of these are certainly due to crummy implementation and poorly
thought-out design. 

However, one major virtue of such primitives is the ability to
get the correct answer. For years, SHARP APL (and every other APL
which ran on /360s...) would display the number you entered as
0.07, as 0.0700000000001 (or so), because that was the "right" answer.

Eugene McDonnell, based on theoretical work by Larry Breed, replaced
this with new primitives which would have several desirable properties,
including display of 0.07 as 0.07. How was this done and on what
basis? (There are a few papers published years later in SIGPLAN 
notices, i THINK? by Guy Steele ? on "formatting numbers correctly")

A few basic ideas were:
a. Recognition that there are a whole bunch of real numbers which 
   all get converted to the SAME floating point value. In particular,
   the two values above have that property. 

   WHen you turn a floating value into a displayable form, there is
   no particular reason to choose one of those values over another,
   since they are ALL possibly correct. 

b. Make sure that the algorithms don't exhibit "creep": The value
   you obtain by repetitively converting character to numeric 
   to character to numeric should not result in the number changing,
   or increasing/decreasing in value.

Once you have these ideas in hand, and a few more (If I can find the
papers, I'll post citations of them), it's possible to write a
correct converter. I claim that these converters are non-trivial,
and are NOT the kind of thing that users should be forced to 
write. Neither should users be subjected to incorrect answers
becaused of non-availability of suitable primitives, and lack of
arcane knowledge of IEEE floating point, etc. 

Primitives for these converters are, if anything, more important 
than set membership, etc.

Bob




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
