From Martin Maechler <maechler@stat.math.ethz.ch>  Thu May 22 15:41:16 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 22 May 97 16:41:16 +0200
Subject: R-alpha: options(..) vs.  .Options  //  Re(1i) = 2.4976e-307
Message-ID: <9705221441.AA01396@>

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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


R-alpha: options(..) vs. .Options // Re(1i) = 2.4976e-307
Martin Maechler