R devel - May 1997 - R-alpha: options(..) vs. .Options // Re(1i) = 2.4976e-307

The 	.Options

vector had been introduced a while ago after my suggestion
(see Ross's E-mail below).
.Options$digits is used be default in several  print methods (eg print.lm),
however, deparse(.) e.g., uses options()$width, and not .Options$width.

Another problem is that  .Options
is still not in the documentation (on-line help).
Before one could add it there, we'd need ``the specs''.

I think the (at least my) idea was that

	options(.)  queries or sets elements in the   .Options  list

and all functions -- including the internal ones -- use  .Options.
As far as I know, this is what S does.
Currently, this is NOT the case in R.

Ross said a while ago:

   >>> From: Ross Ihaka <ihaka@stat.auckland.ac.nz>
   >>> Date: Wed, 11 Dec 1996 17:10:59 +1300 (NZDT)
   >>> To: Martin Maechler <maechler@stat.math.ethz.ch>
   >>> Cc: R-testers mailing list <R-testers@stat.math.ethz.ch>
   >>> Subject: R-alpha: options() and .Options -- ?

    Ross> Martin Maechler writes:
    >> This is not a bug report, rather than some remarks as a
    >> "request for comments":
    >>
    >> It is clear that  options( foo = bar )
    >> sets the option and also updates the builtin()  .Options  list :
    >> 
    >> > options(myopt = pi)
    >> > .Options$my
    >> [1] 3.14159265
    >> 
    >> In S-plus, it was (is) possible to use .Options locally in a
function
    >> frame in order to just affect some options during evaluation of
that
    >> function.

    Ross> I have made some changes so that such local assignments to .Options
    Ross> will work.  The down side is that such assignments will also work
at
    Ross> top level with the changes shadowing the real system options.

    Ross> This also may be ok.  It would have the advantage that options
would
    Ross> then be preserved from session to session.  Is this a good idea or
a
    Ross> bad idea?

----------
Different issue:
> Re(1i)
[1] 2.497599e-307

rather than  0  whereas  Im(as.complex(1)) gives 0 as it should.

- Martin Maechler
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-devel 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-devel-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

It is really not 'Re',
but the parser for complex constants which is at fault:
> 1i - complex(imag=1)
[1] 2.497599e-307+0i
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-devel 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-devel-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Martin Maechler wrote:
> 
> The 	.Options
> 
> vector had been introduced a while ago after my suggestion
> (see Ross's E-mail below).
> .Options$digits is used be default in several  print methods (eg print.lm),
> however, deparse(.) e.g., uses options()$width, and not .Options$width.
> 
> Another problem is that  .Options
> is still not in the documentation (on-line help).
> Before one could add it there, we'd need ``the specs''.
> 
> I think the (at least my) idea was that
> 
> 	options(.)  queries or sets elements in the   .Options  list
> 
> and all functions -- including the internal ones -- use  .Options.
> As far as I know, this is what S does.
> Currently, this is NOT the case in R.
> 
If I understand this right (which may be a big if :-)) this is a bit
tricky.  What S is trying to do is make .Options a dynamically scoped
variable. This seems to work fine from the user perspective, i.e. if I
do

	g<-function(x) print(x)
	f<-function(x) { .Options$digits<-3; g(x) }

then I get the "right thing"
> f(888888888)
[1] 8.89e+08
[1] 888888888

but actually writing your own functions that use .Options is tricky --

	g<-function() .Options$digits
	f<-function() { .Options$digits<-3; g() }

produces
> f()
[1] 7
> 
since the reference to .Options is governed by ordinary scoping rules.
So some convenient way of looking up the closest dynamic binding is
needed -- just referencing .Options in print.lm, for example, won't do
it. Current Splus defines several methods for print and summary that
just reference .Options, but unless some internal magic is being used
for this name, they won't work as expected.

luke



-- 
Luke Tierney
University of Minnesota                      Phone:           612-625-7843
School of Statistics                         Fax:             612-624-8868
206 Church Street                            email:      luke@stat.umn.edu
Minneapolis, MN 55455 USA                    WWW:  http://www.stat.umn.edu
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-devel 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-devel-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-