home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / pascal / 8470 < prev    next >
Encoding:
Text File  |  1993-01-23  |  1.3 KB  |  30 lines
  1. Newsgroups: comp.lang.pascal
  2. Path: sparky!uunet!spool.mu.edu!torn!news.ccs.queensu.ca!slip202.telnet1.QueensU.CA!dmurdoch
  3. From: dmurdoch@mast.queensu.ca (Duncan Murdoch)
  4. Subject: Re: NaN and comp type
  5. Message-ID: <dmurdoch.333.727797095@mast.queensu.ca>
  6. Keywords: comp, NaN
  7. Lines: 17
  8. Sender: news@knot.ccs.queensu.ca (Netnews control)
  9. Organization: Queen's University
  10. References: <1993Jan23.072940.22388@qiclab.scn.rain.com>
  11. Date: Sat, 23 Jan 1993 13:51:35 GMT
  12.  
  13. In article <1993Jan23.072940.22388@qiclab.scn.rain.com> leonard@qiclab.scn.rain.com (Leonard Erickson) writes:
  14. >According to the TP6 manual, NaN is represented for the comp type
  15. >by a value of 0, with a sign bit of 1. But if you *create* such a
  16. >value TP 5.5 and TP 6.0 both treat it as a *large* negative 
  17. >number (-9.22337203685478E+0018) 
  18.  
  19. >So is it broken, or are the docs wrong? I was *hoping* to use it 
  20. >to mark uninitialized values. <sigh>
  21.  
  22. According to the Intel manual (the one I'm using is the 486 Programmer's
  23. Reference, but I've seen the same thing in the 80x87 manuals) the thing 
  24. described in the TP manual is returned as the result of a calculation that 
  25. produces a NaN, but is treated as a number when read from memory.  There's 
  26. no encoding for the integer types that reads as a NaN.
  27.  
  28. Duncan Murdoch
  29. dmurdoch@mast.queensu.ca
  30.