Skip to content

a bug and a question

4 messages · Jim Lindsey, Peter Dalgaard, George White +1 more

Peter Dalgaard
# 
Jim Lindsey <jlindsey at alpha.luc.ac.be> writes:
Not entirely unlikely. The FPU should be the same of course, but the C
and math libraries link to a Microsoft DLL, which I have heard people
speak badly about before. 

Particularly the IEEE exception handling could be causing trouble if
an iterative method wanders near the boundary of a functions domain.
That is pure speculation, though, I suppose Guido and Brian will know
more.
George White
# 
Two things to consider: a) different settings for the f.p. unit, and 
b) different optimizations by the compiler

You can check .Machine -- I haven't used R on Win32, but from other
programs I know that the rounding mode ($double.rounding) is not always
predictable.  I remember some discussion over whether .Machine should be
computed once at compile time or as part of the startup code each time R
is run.  I now have an example (GNU Fortran in a telnet session under OS/2
Warp 4) in which the IEEE rounding mode changes after the first Fortran
write statement, so even if the rounding mode _is_ determined at startup,
it can be altered while a program is running.

Supporting scientific software on Win32 (and OS/2, which shares some
fundamental problems) is not easy!

You might want to check the value of $double.rounding in your code --
ideally it should be 5 (gradual underflow using denormals).  This can
make a big difference to programs using finite differences to approximate
derivatives or in cases of cancellation (summing alternating series).
If you use f.d. for derivatives, it can help to condition the value
of "h", e.g.,:

  for f'(x) ~ (f(x)-f(x+h))/h

you want to use:

  xph = x + h
  h2 = xph - h  // conditioned value for h, but watch for optimizations!
  f'(x) ~ (f(x)-f(xph))/h2

since (x+h) may not be representable in the machine.  The reason I
suspect the IEEE rounding mode is that a) I know it is unpredictable, and
b) underflow in computing (f(x)-f(xph)) is a often a problem.

--
George White <aa056 at chebucto.ns.ca>  tel: 902.426.8509
  Bedford Inst. of Oceanography, Nova Scotia, Canada.
On Wed, 13 Jan 1999, Jim Lindsey wrote:

            

      
      
      
    

        
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

  
  


  


      

    

    

      
      

        


  

        

      Guido Masarotto
    

    

      
      #
    

  


  

      
On Wed, Jan 13, 1999 at 11:15:00AM +0100, Peter Dalgaard BSA wrote:

            

      
      
      
    

        
I think Peter points to the origin of the problem.
  Consider that under MSWindows: (i) the source is the Unix one
  (at least for  the computational part); 
  (ii) the compiler is one that many of us are using under Unix
  (egcs 1.1); (iii) the assembler is more or less the same used
  under Linux (or other ix386/Unix) BUT the libc and libm
  are  completly different.
  
  Anyway, I would like to get a couple of examples to play with.
  
  g.
  (ps) I have just tested Machine()$double.rounding, but is
  equal to 5 at least on my son's Win95 machine (the one
  from which I am connected in this moment) and, at least in this
  moment.





-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._