home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / smalltal / 2801 < prev    next >
Encoding:
Text File  |  1993-01-23  |  4.4 KB  |  102 lines
  1. Newsgroups: comp.lang.smalltalk
  2. Path: sparky!uunet!cs.utexas.edu!news.uta.edu!utafll!bruce
  3. From: bruce@utafll.uta.edu (Bruce Samuelson)
  4. Subject: Slopstone/Smopstone bugs
  5. Message-ID: <1993Jan23.002443.11226@utagraph.uta.edu>
  6. Sender: news@utagraph.uta.edu (USENET News System)
  7. Nntp-Posting-Host: utafll.uta.edu
  8. Organization: University of Texas at Arlington
  9. Date: Sat, 23 Jan 1993 00:24:43 GMT
  10. Lines: 90
  11.  
  12. Summary: There were some minor bugs in Slopstones and Smopstones, mostly in
  13. documentation and terminology.  They are easily corrected, and by a stroke of
  14. luck, none of the numeric results that have been posted are affected. New
  15. fileins with bugs corrected are posted separately.
  16.  
  17. -----------------------------------------------------------------------------
  18. 1) Computation of mean
  19. -----------------------------------------------------------------------------
  20.  
  21. Slopstone>>readme
  22. Slopstone>>execute
  23. Smopstone>>readme
  24. Smopstone>>execute
  25.  
  26. The benchmarks calculate the geometric mean but erroneously refer to it as
  27. harmonic mean. Thanks to Urs Hoelzle for pointing this out. Three popular
  28. means are arithmetic, harmonic, and geometric. Since geometric is least
  29. sensitive to widely differing component values, and scales better than
  30. harmonic mean, let's stick with it. The ParcPlace Dorado benchmarks happen to
  31. use harmonic mean. According to a textbook of mine, the definitions are
  32.  
  33. arithmetic mean = (x1+x2...+xn)/n
  34. harmonic mean   = n/((1/x1)+(1/x2)...+(1/xn))
  35. geometric mean  = (x1*x2...*xn)**(1/n)
  36.  
  37. Rather than use this formula for geometric mean, I used an equivalent formula
  38. to avoid floating point overflow in ST/V-DOS:
  39.  
  40. geometric mean  = (x1**(1/n))*(x2**(1/n))*...*(xn**(1/n))
  41.  
  42. Significance of the bug: posted numbers are correct but results should read
  43. 'geometric mean.'
  44.  
  45. -----------------------------------------------------------------------------
  46. 2) Rectangle intersection in Smopstone>>sorcercersApprentice
  47. -----------------------------------------------------------------------------
  48.  
  49. change (r1 origin ~= r2 origin and: [r1 corner ~= r2 corner])
  50. to     (r1 origin ~= r2 origin or:  [r1 corner ~= r2 corner])
  51.  
  52. This test was supposed to be equivalent to r1 ~= r2.
  53.  
  54. Significance of the bug: In theory, the error could make the benchmark
  55. converge slightly faster than it would have otherwise. In practice, for the
  56. numeric parameters chosen, the error has no effect at all.
  57.  
  58. -----------------------------------------------------------------------------
  59. 3) Comment and error message in Smopstone>>primesUpTo:
  60. -----------------------------------------------------------------------------
  61.  
  62. change "Return the prime numbers between 1 and n."
  63. to     "Return the prime numbers between 2 and n."
  64.  
  65. change 'Upper limit out of range.'
  66. to     'Prime limit(s) out of range.'
  67.  
  68. Significance of the bug: the comment and error message weren't quite accurate.
  69.  
  70. -----------------------------------------------------------------------------
  71. 4) Variances of Float>>printString in Smopstone>>streamTestsOn:
  72. -----------------------------------------------------------------------------
  73.  
  74. Some European versions of Smalltalk use commas when printing floats, while USA
  75. versions use decimal points. Marten Feldtmann pointed this out. See the code
  76. for details.
  77.  
  78. Significance of the bug: it can be fixed in a portable manner that doesn't
  79. affect performance. In my consolidated benchmark tables, I'll use decimal
  80. point for uniformity.
  81.  
  82. -----------------------------------------------------------------------------
  83. 5) Luck of the draw in SmopstoneBenchmark>>streamTestsOn:
  84. -----------------------------------------------------------------------------
  85.  
  86. The final test for integers = floats works because it so happens that both are
  87. OrderedCollections. If integers had been an Array, for instance, it wouldn't
  88. have worked. In other words, for example, Array with: 1 does not equal
  89. OrderedCollection with: 1 in Smalltalk. However, OrderedCollection with: 1
  90. does equal OrderedCollection with: 1.0. I don't want to coerce both to the
  91. same kind of collection in this method, because it would make this test run
  92. slightly longer. I could do the coersion in SmopstoneBenchmark>>setup, but
  93. I'll just leave things be.
  94.  
  95. Significance of the bug: none, unless the '=' selector is redefined in future
  96. versions of Smalltalk.
  97. -- 
  98. **********************************************************
  99. * Bruce Samuelson    Department of Linguistics     *
  100. * bruce@ling.uta.edu    University of Texas at Arlington *
  101. **********************************************************
  102.