Hi Wojciech,
this issue is really tough. Indeed, my first response probably still
holds. It is still the most simple solution to use:
s - summary(the_nls_object)
and retrieve the information from 's'.
Yes, I know this is probably a suboptimal solution. In the meantime, I
have serious doubts that there will be a universal solution which will
cover every scenario.
The closest possibility might look like this (BUT it will be definitely
more complex than the method used until now):
Using either the PRINT-METHOD or the SUMMARY-METHOD
1.) PRINT
Every (is it really every object???) object can be printed by R.
If we type x - c(1,2,3,4) and then
x
R invokes the print function which will display x
Similarly, out-nls(y ~ x^beta, start=list(beta = 3)), then when typing
out
R invokes a special print and outputs the result.
2.) Varieties of PRINT
Unfortunately, there is NO unique print. What looks trivial, is a set of
complex methods different for various objects.
To get an idea of the many print-methods, type at the R prompt:
apropos(print)
Depending on the number of packages attached, it will display a number
of print methods (54 on my base-install, much more IF any packages are
attached).
For the default data-structures in R (atomic data), the 'print.atomic'
or 'print.default' methods will be invoked. Actually, 'print.atomic'
calls 'print.default', see:
getAnywhere(print.atomic)
Similarly:
getAnywhere(print.nls)
will show you the details of the function that prints the output for an
object of class nls, i.e. returning to your example:
out
R invokes the 'print.nls' method from the object 'out' and outputs:
out
Nonlinear regression model
model: y ~ x^beta
data: parent.frame()
beta
1.984
residual sum-of-squares: 10.78
Number of iterations to convergence: 6
Achieved convergence tolerance: 1.518e-07
From 'getAnywhere(print.nls)', we can see that beta is retrieved through:
print(x$m$getAllPars(), digits = digits, ...)
i.e. out$m$getAllPars() will contain/compute the value for beta.
One can see, that the value is NOT stored inside a variable, BUT is
retrieved by a function: 'getAllPars()'
In the case of 'nlm' objects, the methods/functions are stored in
'object'$m and this is the first object in the 'object'-list, i.e.:
out$m
will output the list of methods/functions (out[[1]] is identical).
CAVEAT
I really do NOT know if the methods are ALWAYS stored in 'object'[[1]]
or 'object'$m for the various objects. Objects might exist that do NOT
follow this rule.
You can get the methods applicable on an object with the following syntax:
methods(class = nls)
[1] anova.nls* coef.nls*confint.nls* deviance.nls*
[5] df.residual.nls* fitted.nls* formula.nls* logLik.nls*
[9] predict.nls* print.nls* profile.nls* residuals.nls*
[13] summary.nls* vcov.nls*weights.nls*
Methods marked with (*) are hidden methods.
[The class of an object can be identified using class('object_name'),
e.g. 'class(out)' ]
You see, 'nls' has both a 'print.nls' and a 'summary.nls' method, which
get invoked by the corresponding generic 'print' and 'summary' methods.
Unfortunately, as you see form 'getAnywhere(print.nls)', the print
method does NOT produce a list, therefore extracting the useful
parameter is a little bit awkward.
You see, summary() is far better as it exports a list. So, my suggestion
is to test IF the class has a method 'summary', and then use the s -
summary('our_object')' code to retrieve the information. You can surely
hard-code some parameters for a couple of functions, BUT as I think more
thoroughly, I see no easy solution to the more general approach.
I will try to solve this puzzle, but currently I do NOT have any better
idea.
Of course, iterating through 'object'[1:length('object')] is an
acceptable (and easy method) for most objects, BUT more complex objects
(that have functions and methods defined) pose a problem.
As already pointed out,
out[[1]][[12]]()
will work, too and it will output beta (please note, that '()' is used
at the end; also neither out[1][[12], nor out[[1]][12]() will work; you
need the '[[]][[]]()')
However, it is dangerous to iterate through functions, as some may need
additional arguments (and NOT simply '()' ), while other may change
something.
Sincerely,
Leonard
Wojciech Gryc wrote:
Hi Leonard,
My apologies for the silence with regards to your bugs. I will be
addressing them shortly, trying to figure out what's happening. I just
had one more question: if you use the built-in cell functions to call
R, does it also crash after the first attempt? Maybe it's just an
RDUMP issue.
I've been improving the GUI scripting interface I made for Calc and
it's been working very well. I'll be releasing yet another version
soon, but want to address some bugs and smaller features first. One of
the things I've been looking at is implementing some sort of
