R help - May 2010 - What does this warning mean: "DLL attempted to change FPU control word from 8001f to 9001f"

I started a brand new session in R 2.10.1 (on Windows).
If it matters, I am running the community edition of MySQL 5.0.67, and it is
all running fine.

I am just beginning to examine the process of getting timer series data from
one table in MySQL, computing moving averages and computing a selection of
estimates based on relations among moving averages of different variates,
and storing all the results in another table in MySQL.

The very first thing I did in this session was execute the following two
commands:

Sys.setenv(MYSQL_HOME='c:/MySQL')
library(RMySQL)

The output I got was:

Loading required package: DBI
Warning message:
In inDL(x, as.logical(local), as.logical(now), ...) :
  DLL attempted to change FPU control word from 8001f to 9001f

Now, I write programs in relatively high level languages (C++, perl, Java,
and now R), and NEVER even consider twiddling with FPU control words or
playing with registers on the processor.  I have never gotten this close to
the hardware since I messed with video memory in the old days when I wrote
computer based teaching materials on DOS and had to get acceptable
performance out of the hardware available way back then..  Consequently, I
have no idea what this warning means or what I ought to do about it.  I
assume the DLL it is referring to is
libmySQL.dll<http://www.stat.berkeley.edu/classes/s133/libmySQL.dll>,
which RMySQL needs.  But I have no idea either why it would do what R says
it is doing or why it matters to me, or what I ought to do about it.

I'd appreciate any info you can provide.

Thanks

Ted

	[[alternative HTML version deleted]]

On 14/05/2010 5:00 PM, Ted Byers wrote:
> I started a brand new session in R 2.10.1 (on Windows).
> If it matters, I am running the community edition of MySQL 5.0.67, and it
is
> all running fine.
>
> I am just beginning to examine the process of getting timer series data
from
> one table in MySQL, computing moving averages and computing a selection of
> estimates based on relations among moving averages of different variates,
> and storing all the results in another table in MySQL.
>
> The very first thing I did in this session was execute the following two
> commands:
>
> Sys.setenv(MYSQL_HOME='c:/MySQL')
> library(RMySQL)
>
> The output I got was:
>
> Loading required package: DBI
> Warning message:
> In inDL(x, as.logical(local), as.logical(now), ...) :
>   DLL attempted to change FPU control word from 8001f to 9001f
>
> Now, I write programs in relatively high level languages (C++, perl, Java,
> and now R), and NEVER even consider twiddling with FPU control words or
> playing with registers on the processor.  I have never gotten this close to
> the hardware since I messed with video memory in the old days when I wrote
> computer based teaching materials on DOS and had to get acceptable
> performance out of the hardware available way back then..  Consequently, I
> have no idea what this warning means or what I ought to do about it.  I
> assume the DLL it is referring to is
> libmySQL.dll<http://www.stat.berkeley.edu/classes/s133/libmySQL.dll>,
> which RMySQL needs.  But I have no idea either why it would do what R says
> it is doing or why it matters to me, or what I ought to do about it.
>
> I'd appreciate any info you can provide.

That message means that the RMySQL libraries are trying to mess with the 
precision of the computations in the rest of your session.    It might 
be safe; R fixes the first attempt.  But if the libraries try again, R 
won't fix them, and the rest of your computations will be less accurate 
than they should be.  It's probably not safe to ignore the warning.   
(This might be unintentional; many Microsoft libraries do this.  But it 
is unsafe to use them.)

The safe advice is to recompile the relevant libraries in an environment 
that doesn't mess with things that don't belong to it.  If this is 
impractical, another safe alternative is to just stop using that 
package.  If this is also impractical, then you should expect your 
computations in R to be less accurate than they should be, and you 
should complain to the supplier of the badly written library that causes 
the problems.

Duncan Murdoch

There's a note on this issue at
http://www.nag.co.uk/numeric/RunderWindows.asp 

which claims it can 'safely be ignored'. 

Your mileage may vary, I presume. 

I had the same error message under a previous version (but with a
different library and during installation, not loading, some packages)
and never observed a visible problem. However, I'd be more than willing
to accept that one would not notice changes to FPU precision for many
applications; core R authors seem to have chosen algorithms that are not
badly affected by limited precision. That doesn't mean it would have no
effect for any application, though.

S

>>> Duncan Murdoch <murdoch.duncan at gmail.com> 14/05/2010 22:55
>>>
On 14/05/2010 5:00 PM, Ted Byers wrote:
> I started a brand new session in R 2.10.1 (on Windows).
> If it matters, I am running the community edition of MySQL 5.0.67,
and it is
> all running fine.
>
> I am just beginning to examine the process of getting timer series
data from
> one table in MySQL, computing moving averages and computing a
selection of
> estimates based on relations among moving averages of different
variates,
> and storing all the results in another table in MySQL.
>
> The very first thing I did in this session was execute the following
two
> commands:
>
> Sys.setenv(MYSQL_HOME='c:/MySQL')
> library(RMySQL)
>
> The output I got was:
>
> Loading required package: DBI
> Warning message:
> In inDL(x, as.logical(local), as.logical(now), ...) :
>   DLL attempted to change FPU control word from 8001f to 9001f
>
> Now, I write programs in relatively high level languages (C++, perl,
Java,
> and now R), and NEVER even consider twiddling with FPU control words
or
> playing with registers on the processor.  I have never gotten this
close to
> the hardware since I messed with video memory in the old days when I
wrote
> computer based teaching materials on DOS and had to get acceptable
> performance out of the hardware available way back then.. 
Consequently, I
> have no idea what this warning means or what I ought to do about it. 
I
> assume the DLL it is referring to is
>
libmySQL.dll<http://www.stat.berkeley.edu/classes/s133/libmySQL.dll>,
> which RMySQL needs.  But I have no idea either why it would do what R
says
> it is doing or why it matters to me, or what I ought to do about it.
>
> I'd appreciate any info you can provide.

That message means that the RMySQL libraries are trying to mess with
the 
precision of the computations in the rest of your session.    It might

be safe; R fixes the first attempt.  But if the libraries try again, R

won't fix them, and the rest of your computations will be less accurate

than they should be.  It's probably not safe to ignore the warning.   
(This might be unintentional; many Microsoft libraries do this.  But it

is unsafe to use them.)

The safe advice is to recompile the relevant libraries in an
environment 
that doesn't mess with things that don't belong to it.  If this is 
impractical, another safe alternative is to just stop using that 
package.  If this is also impractical, then you should expect your 
computations in R to be less accurate than they should be, and you 
should complain to the supplier of the badly written library that
causes 
the problems.

Duncan Murdoch

______________________________________________
R-help at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help 
PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html 
and provide commented, minimal, self-contained, reproducible code.

*******************************************************************
This email and any attachments are confidential. Any use...{{dropped:8}}

On 17/05/2010 6:58 AM, S Ellison wrote:
> There's a note on this issue at
> http://www.nag.co.uk/numeric/RunderWindows.asp 
>
> which claims it can 'safely be ignored'. 
>
>   
That's very specific to NAG.  The quote continues:  "Only one of the
NAG
routines uses a different FPU control word and this routine returns the 
control word to its original value before exiting."  If that claim is 
true, then it is indeed safe.  But it also claims:  "This is a common 
issue when calling DLLs compiled using a visual studio compiler (as per 
the NAG library)..." which is true, but somewhat misleading.  The 
Microsoft default is to change the FPU control word so it is a common 
issue, but it is easily avoided.

There are two potential problems:

 - The library may change the control word again.  I think it is fairly 
common for this to happen, e.g. in string conversions of floating point 
values for display.  If it does, then R will subsequently produce 
incorrect results.

 - The library may depend on the setting it chose.  (It was almost 
certainly tested with that setting in place.)  Since R has changed it, 
the library itself may later produce garbage results.

I would not ignore the error.

Duncan Murdoch
> Your mileage may vary, I presume. 
>
> I had the same error message under a previous version (but with a
> different library and during installation, not loading, some packages)
> and never observed a visible problem. However, I'd be more than willing
> to accept that one would not notice changes to FPU precision for many
> applications; core R authors seem to have chosen algorithms that are not
> badly affected by limited precision. That doesn't mean it would have no
> effect for any application, though.
>
> S
>
>
> >>> Duncan Murdoch <murdoch.duncan at gmail.com> 14/05/2010
22:55 >>>
> On 14/05/2010 5:00 PM, Ted Byers wrote:
> > I started a brand new session in R 2.10.1 (on Windows).
> > If it matters, I am running the community edition of MySQL 5.0.67,
> and it is
> > all running fine.
> >
> > I am just beginning to examine the process of getting timer series
> data from
> > one table in MySQL, computing moving averages and computing a
> selection of
> > estimates based on relations among moving averages of different
> variates,
> > and storing all the results in another table in MySQL.
> >
> > The very first thing I did in this session was execute the following
> two
> > commands:
> >
> > Sys.setenv(MYSQL_HOME='c:/MySQL')
> > library(RMySQL)
> >
> > The output I got was:
> >
> > Loading required package: DBI
> > Warning message:
> > In inDL(x, as.logical(local), as.logical(now), ...) :
> >   DLL attempted to change FPU control word from 8001f to 9001f
> >
> > Now, I write programs in relatively high level languages (C++, perl,
> Java,
> > and now R), and NEVER even consider twiddling with FPU control words
> or
> > playing with registers on the processor.  I have never gotten this
> close to
> > the hardware since I messed with video memory in the old days when I
> wrote
> > computer based teaching materials on DOS and had to get acceptable
> > performance out of the hardware available way back then.. 
> Consequently, I
> > have no idea what this warning means or what I ought to do about it. 
> I
> > assume the DLL it is referring to is
> >
> libmySQL.dll<http://www.stat.berkeley.edu/classes/s133/libmySQL.dll>,
> > which RMySQL needs.  But I have no idea either why it would do what R
> says
> > it is doing or why it matters to me, or what I ought to do about it.
> >
> > I'd appreciate any info you can provide.
>
>
> That message means that the RMySQL libraries are trying to mess with
> the 
> precision of the computations in the rest of your session.    It might
>
> be safe; R fixes the first attempt.  But if the libraries try again, R
>
> won't fix them, and the rest of your computations will be less accurate
>
> than they should be.  It's probably not safe to ignore the warning.   
> (This might be unintentional; many Microsoft libraries do this.  But it
>
> is unsafe to use them.)
>
> The safe advice is to recompile the relevant libraries in an
> environment 
> that doesn't mess with things that don't belong to it.  If this is 
> impractical, another safe alternative is to just stop using that 
> package.  If this is also impractical, then you should expect your 
> computations in R to be less accurate than they should be, and you 
> should complain to the supplier of the badly written library that
> causes 
> the problems.
>
> Duncan Murdoch
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help 
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html 
> and provide commented, minimal, self-contained, reproducible code.
>
> *******************************************************************
> This email and any attachments are confidential. Any u...{{dropped:9}}