home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / tcl / 1025 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.9 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!mips!pacbell.com!att!cbnewsm!grenache!gah
  2. From: gah@grenache (George A. Howlett)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Re: bug in expr?
  5. Message-ID: <1992Jul22.163913.27329@cbnewsm.cb.att.com>
  6. Date: 22 Jul 92 16:39:13 GMT
  7. References: <1992Jul21.215415.23716@crd.ge.com>
  8. Sender: news@cbnewsm.cb.att.com (NetNews Administrator)
  9. Reply-To: george.howlett@att.com
  10. Organization: AT&T Bell Laboratories
  11. Lines: 78
  12. X-Newsreader: Tin 1.1 PL4
  13. Nntp-Posting-Host: grenache.cnet.att.com
  14.  
  15. kennykb@dssv01.crd.ge.com (Kevin B. Kenny) writes:
  16. : 
  17. : Can someone explain the following?  More to the point, can someone fix it?
  18. : 
  19. : wish: set x [expr 400000.0+500000.0]
  20. : 900000
  21. : wish: set y [expr $x*$x]
  22. : -1748818944
  23. : 
  24. : The square of 900000.0 oughtn't to be a large negative number.
  25. : 
  26. : 
  27. : 73 de ke9tv/2, Kevin          There isn't any .signature virus, is there?
  28.  
  29. I think the point that Kevin is making is that if you started out
  30. with floating point values, you should get a floating point result.
  31. The implicit demotion of the sum of two floating point numbers into
  32. a integer result is unexpected.  It's fairly easy to detect here,
  33. but insidiously hard to track in more complex usages. 
  34.  
  35. Another problem, noted in an earlier posting by Brian Smith:
  36. : Here's an annoying bug in tcl dealing with double precision arithmetic.
  37. : Not really a "bug", so much, but a lousy feature.  It seems the expr
  38. : command is intent on rounding off all double precesions values to about
  39. : 6 significant figures, whereas 14-15 are present on most machines.  For
  40. : example, "expr 123456.789012345" returns "123457", but the command
  41. : "expr 123456.789012345-123456.7890123" returns "4.50091e-08", which is
  42. : pretty reasonable.
  43. :
  44. : Easily fixed (chang "%g" to "%lf" in tclExpr.c), but annoying if you're
  45. : trying to do accurate arithmetic.
  46. :
  47. : --
  48. : -----
  49. : Brian C. Smith
  50. : bsmith@cs.Berkeley.EDU
  51. : University of California, Berkeley
  52. : Computer Sciences Department
  53. : (510)642-9585
  54.  
  55.  
  56. You could simply change the format in tclExpr.c.  Unfortunately, 
  57. this still doesn't address the round-off problem and could break
  58. existing code which relies on the implicit demotion or a compact
  59. representation of a floating point number.
  60.  
  61. The solution I adopted has the same mechanism as "awk".  In awk, the
  62. format of the converted floating point number is controlled by the
  63. variable OFMT.  Setting this variable changes the format conversion.
  64. The default format is "%g".
  65.  
  66. In Kevin's example:
  67.  
  68. wish: set OFMT %#g
  69. %#g
  70. wish: set x [expr 400000.0+500000.0]
  71. 900000.
  72. wish: set y [expr $x*$x]
  73. 8.10000e+11
  74. wish: unset OFMT
  75. wish: set x [expr 400000.0+500000.0]
  76. 900000
  77.  
  78. This way one can set the format for the problem at hand without
  79. breaking existing code.
  80.  
  81. I can repost this patch if anyone's interested.
  82.  
  83. BTW: If you are using the patch to add math library functions,
  84.      you could have explicitly promoted x using the "float()"
  85.      function.
  86.  
  87. wish: set x [expr 400000.0+500000.0]
  88. 900000
  89. wish: set y [expr float($x)*$x]
  90. 8.1e+11
  91.  
  92. --gah
  93.