Re: [Rd] surprising behaviour of names-
Berwin A Turlach wrote:
foo = function(arg) arg$foo = foo
e = new.env()
foo(e)
e$foo
are you sure this is pass by value?
But that is what environments are for, aren't they?
might be.
And it is
documented behaviour.
sure!
Read section 2.1.10 (Environments) in the R
Language Definition,
haven't objected to that. i object to your 'r uses pass by value',
which is only partially correct.
in particular the last paragraph:
Unlike most other R objects, environments are not copied when
passed to functions or used in assignments. Thus, if you assign the
same environment to several symbols and change one, the others will
change too. In particular, assigning attributes to an environment can
lead to surprises.
[..]
and actually, in the example we discuss, 'names-' does *not* return
an updated *tmp*, so there's even less to entertain.
How do you know? Are you sure? Have you by now studied what goes on
under the hood?
yes, a bit. but in this example, it's enough to look into *tmp* to see
that it hasn't got the names added, and since x does have names, names-
must have returned a copy of *tmp* rather than *tmp* changed:
x = 1
tmp = x
x = 'names-'(tmp, 'foo')
names(tmp)
# NULL
you suggested that One reads the manual, (...) one reflects and
investigates, ... -- had you done it, you wouldn't have asked the question.
for fun and more guesswork, the example could have been:
x = x
x = 'names-'(x, value=c('a', 'b'))
But it is manifestly not written that way in the manual; and for good
reasons since 'names-' might have side effects which invokes in the
last line undefined behaviour. Just as in the equivalent C snippet
that I mentioned.
i just can't get it why the manual does not manifestly explain what
'names-' does, and leaves you doing the guesswork you suggest.
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rd \usage clause for an S4 replace method
Given S4 methods [ and [-, how do I write the Rd-file usage clause for
the latter one?
What I have now is:
\S4method{[}{TimeSeries,TimeDate,missing}(x, i, j, ..., drop)
\S4method{[-}{TimeSeries,TimeDate,missing,ANY}(x, i, j, ..., value)
which results in the following output:
## S4 method for signature 'TimeSeries, TimeDate, missing':
x[i, j, ..., drop]
\S4method{[-}{TimeSeries,TimeDate,missing,ANY}(x, i, j, ..., value)
How should I document the latter? Thanks.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
**
Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees ...{{dropped:19}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names-
On Fri, 13 Mar 2009 11:43:55 +0100
Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote:
Berwin A Turlach wrote:
And it is documented behaviour.
sure!
Glad to see that we agree on this.
Read section 2.1.10 (Environments) in the R
Language Definition,
haven't objected to that. i object to your 'r uses pass by value',
which is only partially correct.
Well, I used qualifiers and did not stated it categorically.
and actually, in the example we discuss, 'names-' does *not*
return an updated *tmp*, so there's even less to entertain.
How do you know? Are you sure? Have you by now studied what goes
on under the hood?
yes, a bit. but in this example, it's enough to look into *tmp* to
see that it hasn't got the names added, and since x does have names,
names- must have returned a copy of *tmp* rather than *tmp* changed:
x = 1
tmp = x
x = 'names-'(tmp, 'foo')
names(tmp)
# NULL
Indeed, if you type these two commands on the command line, then it is
not surprising that a copy of tmp is returned since you create a
temporary object that ends up in the symbol table and persist after the
commands are finished.
Obviously, assuming that R really executes
*tmp* - x
x - names-('*tmp*', value=c(a,b))
under the hood, in the C code, then *tmp* does not end up in the symbol
table and does not persist beyond the execution of
names(x) - c(a,b)
This looks to me as one of the situations where a value of 1 is used
for the named field of some of the objects involves so that a copy can
be avoided. That's why I asked whether you looked under the hood.
you suggested that One reads the manual, (...) one reflects and
investigates, ...
Indeed, and I am not giving up hope that one day you will master this
art.
-- had you done it, you wouldn't have asked the question.
Sorry, I forgot that you have a tendency to interpret statements
extremely verbatim and with little reference to the context in which
they are made. I will try to be more explicit in future.
for fun and more guesswork, the example could have been:
x = x
x = 'names-'(x, value=c('a', 'b'))
But it is manifestly not written that way in the manual; and for
good reasons since 'names-' might have side effects which invokes
in the last line undefined behaviour. Just as in the equivalent C
snippet that I mentioned.
i just can't get it why the manual does not manifestly explain what
'names-' does, and leaves you doing the guesswork you suggest.
As I said before, patched to documentation are also welcome.
Best wishes,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rd \usage clause for an S4 replace method
That's not how you use it, surely?
The obvious to me
\usage{
\S4method{[}{TimeSeries,TimeDate,missing}(x, i, j, ..., drop)
\S4method{[}{TimeSeries,TimeDate,missing,ANY}(x, i, j, ...) - value
}
works. There is an example of a replacement method using \method in
'Writing R Extensions', so expecting \S4method to work in the same way
seems reasonable to me (and I didn't write or document any of this).
On Fri, 13 Mar 2009, Sklyar, Oleg (London) wrote:
Given S4 methods [ and [-, how do I write the Rd-file usage clause for
the latter one?
What I have now is:
\S4method{[}{TimeSeries,TimeDate,missing}(x, i, j, ..., drop)
\S4method{[-}{TimeSeries,TimeDate,missing,ANY}(x, i, j, ..., value)
which results in the following output:
## S4 method for signature 'TimeSeries, TimeDate, missing':
x[i, j, ..., drop]
\S4method{[-}{TimeSeries,TimeDate,missing,ANY}(x, i, j, ..., value)
How should I document the latter? Thanks.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
**
Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees ...{{dropped:19}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names-
Berwin A Turlach wrote:
sure!
Glad to see that we agree on this.
owe you a beer.
Read section 2.1.10 (Environments) in the R
Language Definition,
haven't objected to that. i object to your 'r uses pass by value',
which is only partially correct.
Well, I used qualifiers and did not stated it categorically.
indeed, you said R supposedly uses call-by-value (though we know how to
circumvent that, don't we?).
in that vain, R supposedly can be used to do valid statistical
computations (though we know how to circumvent it) ;)
and actually, in the example we discuss, 'names-' does *not*
return an updated *tmp*, so there's even less to entertain.
How do you know? Are you sure? Have you by now studied what goes
on under the hood?
yes, a bit. but in this example, it's enough to look into *tmp* to
see that it hasn't got the names added, and since x does have names,
names- must have returned a copy of *tmp* rather than *tmp* changed:
x = 1
tmp = x
x = 'names-'(tmp, 'foo')
names(tmp)
# NULL
Indeed, if you type these two commands on the command line, then it is
not surprising that a copy of tmp is returned since you create a
temporary object that ends up in the symbol table and persist after the
commands are finished.
what does command line have to do with it?
Obviously, assuming that R really executes
*tmp* - x
x - names-('*tmp*', value=c(a,b))
under the hood, in the C code, then *tmp* does not end up in the symbol
table
no?
and does not persist beyond the execution of
names(x) - c(a,b)
no?
i guess you have looked under the hood; point me to the relevant code.
This looks to me as one of the situations where a value of 1 is used
for the named field of some of the objects involves so that a copy can
be avoided. That's why I asked whether you looked under the hood.
anyway, what happens under the hood is much less interesting from the
user's perspective that what can be seen over the hood. what i can see,
is that 'names-' will incoherently perform in-place modification or
copy-on-assignment.
yes, *if* you are able to predict the refcount of the object passed to
'names-' *then* you can predict what 'names-' will do, but in general
you may not have the chance. and in general, this should not matter
because it should be unobservable, but it isn't.
back to your i += i++ example, the outcome may differ from a compiler to
a compiler, but, i guess, compilers will implement the order coherently,
so that whatever version they choose, the outcome will be predictable,
and not dependent on some earlier code. (prove me wrong. or maybe i'll
do it myself.)
you suggested that One reads the manual, (...) one reflects and
investigates, ...
Indeed, and I am not giving up hope that one day you will master this
art.
well, this time i meant you.
-- had you done it, you wouldn't have asked the question.
Sorry, I forgot that you have a tendency to interpret statements
extremely verbatim
yes, i have two hooks installed: one says \begin{verbatim}, the other
says \end{verbatim}.
and with little reference to the context in which
they are made.
not that you're trying to be extremely accurate or polite here...
I will try to be more explicit in future.
it will certainly do good to you.
i just can't get it why the manual does not manifestly explain what
'names-' does, and leaves you doing the guesswork you suggest.
As I said before, patched to documentation are also welcome.
i'll give it a try.
Best wishes,
hope you mean it.
likewise,
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Does anybody have some starter code in Java to instance a standalone JGRConsole ?
Hi: Does anybody have some starter code in Java to instance a stand alone JGRConsole ? From the docs it looks that it shouldn't be that hard to write some starter code: http://www.rosuda.org/r/nightly/javadoc/org/rosuda/JGR/JGRConsole.html But in practice starter code has always little tricks ... Searched in rseek, Google and mailing lists but came out empty handed :-( Thanks. Daniel. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names-
Would it make anyone any happier if the manual said
that the replacement functions should not be called
in the form
xNew - `func-` (xOld, value)
and should only be used as
func(xToBeChanged) - value
?
The explanation
names(x) - c(a,b)
is equivalent to
'*tmp*' - x
x - names-('*tmp*', value=c(a,b))
could also be extended a bit, adding a line like
rm(`*tmp*`)
Those 3 lines should be considered an atomic operation:
the value that `*tmp*` or `x` may have or what is
in the symbol table at various points in that sequence
is not defined. (Letting details be explicitly undefined
is important: it gives developers room to improve the
efficiency of the interpreter and tells users where not to go.)
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Wacek Kusnierczyk
Sent: Friday, March 13, 2009 11:42 AM
To: Berwin A Turlach
Cc: r-devel@r-project.org List
Subject: Re: [Rd] surprising behaviour of names-
... blah blah blah
x = 1
tmp = x
x = 'names-'(tmp, 'foo')
names(tmp)
# NULL
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names-
Wacek Kusnierczyk wrote: [snip] i just can't get it why the manual does not manifestly explain what 'names-' does, and leaves you doing the guesswork you suggest. I'm having trouble understanding the point of this discussion. Someone is calling a replacement function in a way that it's not meant to be used, and is them complaining about it not doing what he thinks it should, or about the documentation not describing what happens when one does that? Is there anything incorrect or missing in the help page for normal usage of the replacement function for 'names'? (i.e., when used in an expression like 'names(x) - ...') R does give one the ability to use its facilities in non-standard ways. However, I don't see much value in the help page for 'gun' attempting to describe the ways in which the bones in your foot will be shattered should you choose to point the gun at your foot and pull the trigger. Reminds me of the story of the guy in New York, who after injuring his back in refrigerator-carrying race, sued the manufacturer of the refrigerator for not having a warning label against that sort of use. -- Tony Plate __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names-
William Dunlap wrote:
Would it make anyone any happier if the manual said
that the replacement functions should not be called
in the form
xNew - `func-` (xOld, value)
and should only be used as
func(xToBeChanged) - value
surely better than guesswork.
?
The explanation
names(x) - c(a,b)
is equivalent to
'*tmp*' - x
x - names-('*tmp*', value=c(a,b))
could also be extended a bit, adding a line like
rm(`*tmp*`)
Those 3 lines should be considered an atomic operation:
the value that `*tmp*` or `x` may have or what is
in the symbol table at various points in that sequence
is not defined. (Letting details be explicitly undefined
is important: it gives developers room to improve the
efficiency of the interpreter and tells users where not to go.)
there is a difference between letting things be undefined and explicitly
stating that things are unspecified. the c99 standard [1], for example,
is explicit about the non-determinism of expressions that involve side
effects, as it is about that some expressions may actually not be
evaluated if the optimizer decides so.
berwin has already suggested that one reads from what docs do *not*
say; it's a very bad idea. it's best that the documentation *does* say
that, for example, a particular function should be used only in the
infix form because the semantics of the prefix form are not guaranteed
and may change in future versions.
if the current state is that 'names-' will modify the object it is
given as an argument in some situations, but not in others, and this is
visible to the user, the best thing to do is to give an explicit warning
-- perhaps with an annotation that things may change, if they may.
best,
vQ
[1] http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names-
Tony Plate wrote: Wacek Kusnierczyk wrote: [snip] i just can't get it why the manual does not manifestly explain what 'names-' does, and leaves you doing the guesswork you suggest. I'm having trouble understanding the point of this discussion. Someone is calling a replacement function in a way that it's not meant to be used, and is them complaining about it not doing what he thinks it should, or about the documentation not describing what happens when one does that? where is it written that the function is not meant to be used this way? you get an example in the man page, showing precisely how it could be used that way. it also explains the value of 'names-': For 'names-', the updated object. (Note that the value of 'names(x) - value' is that of the assignment, 'value', not the return value from the left-hand side.) it does speak of 'names-' used in prefix form, and does not do it in any negative (discouraging) way. Is there anything incorrect or missing in the help page for normal usage of the replacement function for 'names'? (i.e., when used in an expression like 'names(x) - ...') what is missing here in the first place is a specification of what 'normal' means. as far as i can see from the man page, 'normal' does not exclude prefix use. and if so, what is missing in the help page is a clear statement what an application of 'names-' will do, in the sense of what a user may observe. R does give one the ability to use its facilities in non-standard ways. However, I don't see much value in the help page for 'gun' attempting to describe the ways in which the bones in your foot will be shattered should you choose to point the gun at your foot and pull the trigger. Reminds me of the story of the guy in New York, who after injuring his back in refrigerator-carrying race, sued the manufacturer of the refrigerator for not having a warning label against that sort of use. very funny. little relevant. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] installed.packages and package info cache buglet (PR#13592)
Mark Bravington mark.braving...@csiro.au
on Thu, 12 Mar 2009 21:45:18 +0100 (CET) writes:
Looks like there is a buglet in 'installed.packages', around line 17:
for (lib in lib.loc) {
dest - file.path(tempdir(), paste(libloc_, URLencode(lib,=20
TRUE), paste(fields, collapse =3D ,), .rds, sep =3D ))
if (!noCache file.exists(dest) file.info(dest)$mtime =20
file.info(lib.loc)$mtime) {
^^^
=20
The 'lib.loc' should be 'lib', otherwise the comparison is always against t=
he first library in 'lib.loc', not against the one being checked. [Normally=
the multiple test in '' would flag a warning from 'if', but the s mean =
that only the first element is used.]
I can't provide a reproducible example for this, because it's so installati=
on-dependent.
Still present in R-devel from 8th March.
and today. Thank you, Mark, I've corrected it (in R-devel
only).
Martin Maechler, ETH Zurich
Mark Bravington
CSIRO
Hobart
Australia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] lsfit w/ rank-deficient x
Dear R-devel, It seems that lsfit incorrectly reports coefficients when the input matrix 'x' is rank-deficient, see the example below: ## here values of 'b' and 'c' are incorrectly swapped x - cbind(a=rnorm(100), b=0, c=rnorm(100)); y - rnorm(100); lsfit(x, y)$coef Intercept a b c -0.0227787 0.1042860 -0.1729261 0.000 Warning message: In lsfit(x, y) : 'X' matrix was collinear ## correct values lsfit(x[,-2], y)$coef Intercept a c -0.0227787 0.1042860 -0.1729261 I looked inside the lsfit code and it appears that even though rank-deficiency is detected there is no attempt to patch the coefficients. Why is that? Taking clues from the code it appears that the following trick might do the work: foo - lsfit(x, y) Warning message: In lsfit(x, y) : 'X' matrix was collinear structure(foo$coefficients[foo$qr$pivot], names=names(foo$coefficients)) Intercept a b c 0.14857345 -0.07473099 0. 0.12835155 Is this reliable or there are cases when it may fail? Thanks, Vadim P.S. version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 7.1 year 2008 month 06 day23 svn rev45970 language R version.string R version 2.7.1 (2008-06-23) Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. Jump Trading, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial product. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names-
Tony Plate wrote:
Wacek Kusnierczyk wrote:
Tony Plate wrote:
Is there anything incorrect or missing in the help page for normal
usage of the replacement function for 'names'? (i.e., when used in an
expression like 'names(x) - ...')
what is missing here in the first place is a specification of what
'normal' means. as far as i can see from the man page, 'normal' does
not exclude prefix use. and if so, what is missing in the help page is
a clear statement what an application of 'names-' will do, in the sense
of what a user may observe.
Fair enough. I looked at the help page for names after sending my
email, and was surprised to see the following in the DETAILS section:
It is possible to update just part of the names attribute via the
general rules: see the examples. This works because the expression
there is evaluated as |z - names-(z, [-(names(z), 3, c2))|.
To me, this paragraph is far more confusing than enlightening,
especially as also gives the impression that it's OK to use a
replacement function in a functional form. In my own personal opinion
it would be a enhancement to remove that example from the
documentation, and just say you can do things like 'names(x)[2:3] -
c(a,b)'.
i must say that this part of the man page does explain things to me.
much less the code [1] berwin suggested as a piece to read and
investigate (slightly modified):
tmp = x
x = 'names-'(tmp, 'foo')
berwin's conclusion seemed to be that this code
hints/suggests/fortune-tells the user that 'names-' might be doing side
effects.
this code illustrates what names(x) = 'foo' (the infix form) does --
that it destructively modifies x. now, if the code were to illustrate
that the prefix form does perform side effects too, then the following
would be enough:
'names-'(x, 'foo')
if the code were to illustrate that the prefix form, unlike the infix
form, does not perform side effects, then the following would suffice
for a discussion:
x = 'names-'(x, 'foo')
if the code wee to illustrate that the prefix form may or may not do
side effects depending on the situation, then it surely fails to show
that, unless the user performs some sophisticated inference which i am
not capable of, or, more likely, unless the user already knows that this
was to be shown.
without a discussion, the example is simply an unworked rubbish. and
it's obviously wrong; it says that (slightly and irrelevantly simplified)
names(x) = 'foo'
is equivalent to
tmp = x
x = 'names-'(tmp, 'foo')
which is nonsense, because in the latter case you either have an
additional binding that you don't have in the former case, or, worse,
you rebind, possibly with a different value, a name that has had a
binding already. it's a gritty-nitty detail, but so is most of
statistics based on nitty-gritty details which non-statisticians are
happy to either ignore or be ignorant about.
[1] http://stat.ethz.ch/R-manual/R-devel/doc/manual/R-lang.html#Comments
I often use name replacement functions in a functional way, and
because one can't use 'names-' etc in this way,
note, this 'because' does not follow in any way from the man page, or
the section of 'r language definition' referred to above.
I define my own functions like the following:
set.names - function(n,x) {names(x) - n; x}
it appears that
set.names = function(n, x) 'names-'(x, n)
would do the job (guess why).
(and similarly for set.rownames(), set colnames(), etc.)
I would highly recommend you do this rather than try to use a call
like names-(x, ...).
i'm almost tempted to extend your recommendation to 'define your own
function for about every function already in r' ;)
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names-
On Fri, 13 Mar 2009 19:41:42 +0100
Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote:
Glad to see that we agree on this.
owe you a beer.
O.k., if we ever meet is is first your shout and then mine.
haven't objected to that. i object to your 'r uses pass by value',
which is only partially correct.
Well, I used qualifiers and did not stated it categorically.
indeed, you said R supposedly uses call-by-value (though we know how
to circumvent that, don't we?).
in that vain, R supposedly can be used to do valid statistical
computations (though we know how to circumvent it) ;)
Sure, use Excel? ;-)
Indeed, if you type these two commands on the command line, then it
is not surprising that a copy of tmp is returned since you create a
temporary object that ends up in the symbol table and persist after
the commands are finished.
what does command line have to do with it?
If you want to find out what goes on under the hood, it is not
necessarily sufficient to do the same calculations on the command line.
Obviously, assuming that R really executes
*tmp* - x
x - names-('*tmp*', value=c(a,b))
under the hood, in the C code, then *tmp* does not end up in the
symbol table
no?
Well, I don't see any new object created in my workspace after
x - 4
names(x) - foo
Do you?
i guess you have looked under the hood; point me to the relevant
code.
No I did not, because I am not interested in knowing such intimate
details of R, but it seems you were interested.
yes, *if* you are able to predict the refcount of the object passed to
'names-' *then* you can predict what 'names-' will do, [...]
I think Simon pointed already out that you seem to have a wrong
picture of what is going on. As far as I know, there is no refcount
for objects.
The relevant documentation would be R Language Manual, 1.1 SEXPs:
What R users think of as variables or objects are symbols which are
bound to a value. The value can be thought of as either a SEXP (a
pointer), or the structure it points to, a SEXPREC (and there are
alternative forms used for vectors, namely VECSXP pointing to
VECTOR_SEXPREC structures).
and 1.1.2 Rest of header:
The named field is set and accessed by the SET_NAMED
and NAMED macros, and take values 0, 1 and 2. R has a `call by value'
illusion, so an assignment like
b - a
appears to make a copy of a and refer to it as b. However, if neither
a nor b are subsequently altered there is no need to copy. What really
happens is that a new symbol b is bound to the same value as a and the
named field on the value object is set (in this case to 2). When an
object is about to be altered, the named field is consulted. A value
of 2 means that the object must be duplicated before being changed.
(Note that this does not say that it is necessary to duplicate, only
that it should be duplicated whether necessary or not.) A value of 0
means that it is known that no other SEXP shares data with this
object, and so it may safely be altered. A value of 1 is used for
situations like
dim(a) - c(7, 2)
where in principle two copies of a exist for the duration of the
computation as (in principle)
a - `dim-`(a, c(7, 2))
but for no longer, and so some primitive functions can be optimized to
avoid a copy in this case.
but in general you may not have the chance. [...]
Agreed.
and in general, this should not matter because it should be
unobservable, but it isn't.
That's your opinion (to which you are entitled). Unfortunately (for
you), the designers of R decided on a design which allows them to
reduce the number of copies that have to be made.
you suggested that One reads the manual, (...) one reflects and
investigates, ...
Indeed, and I am not giving up hope that one day you will master
this art.
well, this time i meant you.
Rest assure I have read and reflected on that part of the manual.
And I guess it boils down to how you interpret what is equivalent to
means.
For me it means that those two commands are what is executed in the C
engine once the names(x)-c(a,b) expression is parsed and the
parse list arrives at the interpreter. To investigate whether that is
the case, one would have to look at the C code, and I have little
inclination to do so. But that would be necessary to answer the
question whether *tmp* or a copy of *tmp* is returned, if one is really
interested in this question. Or whether a *tmp* object is created at
all.
You seem to take is equivalent to to mean that issuing
names(x)-c(a,b) on the command line has the same effect as
issuing those two other commands on the command line and addressing
whether *tmp* or a copy of *tmp* is returned in this case. Fair
enough, but it addresses a different question. And, as you said
yourself in another e-mail, on the command line these two versions are
not equivalent since
