Martin Morgan wrote:
[...]
## Attempt two -- initialize
setClass("Element",
representation=representation(conn="file"))
setMethod(initialize, "Element", function(.Object, ..., conn=file()) {
callNextMethod(.Object, ..., conn=conn)
})
new("Element")
## oops, connection created b
Mathieu Ribatet wrote:
> I guess that having something like this
>
>> q()
>> Save workspace image (/home/me/workspace/.RData)? [y/n/c/e]:
>>
>
> where "e" means Editing the path should be clear enought, isn't it?
>
good idea; maybe 'o' for 'other path'; or 'a' for 'alternative path';
Duncan Murdoch wrote:
> On 05/06/2009 7:53 AM, Barry Rowlingson wrote:
>> When I quit R, it says:
>>
>> > q()
>> Save workspace image? [y/n/c]:
>>
>> and since I've probably got 3 R sessions running in however many
>> different directories and I might have jumped around with setwd() , I
>> forge
Barry Rowlingson wrote:
> Would something like
>
> > q()
> Save workspace image (/home/me/workspace/.RData)? [y/n/c]:
>
> be useful to anyone else? Just thought I'd ask before I dive into
> internals or wrap the q function for myself.
>
yes, it would be very useful to me.
vQ
_
the post 13613 has been classified as features&faq and annotated with
"As documented in the Warning section!". however, the bug has actually
been fixed.
may i kindly suggest that the annotation be changed to a more
appropriate note?
regards,
vQ
__
R-
William Dunlap wrote:
> help('while') says:
> Usage:
> for(var in seq) expr
> while(cond) expr
> repeat expr
> break
> next
> Value:
> 'for', 'while' and 'repeat' return the value of the last
> expression evaluated (or 'NULL' if none was), invisibly. 'for'
>
Wacek Kusnierczyk wrote:
>
> a simplified example may help to get a clear picture:
>
> i = 1; y = 1:3;
> (while(TRUE) {
>y[i] = 0
>if (i == 2) break
>i = i + 1
>y })
> # 0 0 3
>
> i = 1; y = 1:3;
> (while(T
Stavros Macrakis wrote:
> In R 2.8.0 on Windows (tested both under ESS and under R Console in case
> there was an I/O issue)
>
> There is a bug in printing val <- matrix(list(NA_complex_,NA_complex_),1).
>
>
>> dput(val)
>>
> structure(list(NA_complex_, NA_complex_), .Dim = 1:2)
>
>
>> p
William Dunlap wrote:
> One of our R users here just showed me the following problem while
> investigating the return value of a while loop. I added some
> information
> on a similar bug in for loops. I think he was using 2.9.0
> but I see the same problem on today's development version of 2.10.0
Barry Rowlingson wrote:
[...]
> I suspect it's using 'deparse()' to get the character representation.
> This function is mentioned in ?as.character, but as.character.default
> disappears into the infernal .Internal and I don't have time to chase
> source code - it's sunny outside!
>
on the si
William Dunlap wrote:
> %in% is a thin wrapper on a call to match(). match() is
> not a generic function (and is not documented to be one),
> so it treats data.frames as lists, as their underlying
> representation is a list of columns. match is documented
> to convert lists to character and to th
Stavros Macrakis wrote:
>
> '1:3' %in% data.frame(a=2:4,b=1:3) # TRUE
>
utterly weird. so what would x have to be so that
x %in% data.frame('a')
# TRUE
hint:
'1' %in% data.frame(1)
# TRUE
vQ
__
R-devel@r-project.org mailin
William Dunlap wrote:
> It looks like the 'seq' variable to 'for' can be altered from
> within the loop, leading to incorrect answers. E.g., in
> the following I'd expect 'sum' to be 1+2=3, but R 2.10.0
> (svn 48686) gives 44.5.
>
>> x = c(1,2); sum = 0; for (i in x) { x[i+1] = i + 42.5; sum
Martin Maechler wrote:
>> "PS" == Petr Savicky
>> on Sun, 31 May 2009 10:29:41 +0200 writes:
>>
>
> []
>
> PS> I appreciate the current version, which contains static
> PS> const char* dropTrailing0(char *s, char cdec) ...
> PS> mkChar(dropTrail
Martin Maechler wrote:
[...]
> vQ> the first question is, why does ER return the string as const? it
> vQ> appears that the returned pointer provides the address of a buffer
> used
> vQ> internally in ER, which is allocated *statically*. that is, each call
> vQ> to ER operates
Martin Maechler wrote:
> Hi Waclav (and other interested parties),
>
> I have committed my working version of src/main/coerce.c
> so you can prepare your patch against that.
>
some further investigation and reflections on the code in StringFromReal
(henceforth SFR), src/main/coerce.c:315 (as in
Stavros Macrakis wrote:
> This is another example of the general preference of the designers of R for
> convenience over consistency.
>
> In my opinion, this is a design flaw even for non-programmers, because I
> find that inconsistencies make the system harder to learn. Yes, the naive
> user may
Martin Maechler wrote:
> Hi Waclav (and other interested parties),
>
> I have committed my working version of src/main/coerce.c
> so you can prepare your patch against that.
>
Hi Martin,
One quick reaction (which does not resolve my original complaint): you
can have p non-const, and cast s to
Martin Maechler wrote:
[...]
> vQ> you return s, which should be the same pointer value (given the actual
> vQ> code that does not modify the local variable s) with the same
> pointed-to
> vQ> string value (given the signature of the function).
>
> vQ> was perhaps
>
> vQ> char
Petr Savicky wrote:
> On Fri, May 29, 2009 at 03:53:02PM +0200, Martin Maechler wrote:
>
>> my version of *using* the function was
>>
>> 1 SEXP attribute_hidden StringFromReal(double x, int *warn)
>> 2 {
>> 3 int w, d, e;
>> 4 formatReal(&x, 1, &w, &d, &e, 0);
>> 5 if (ISNA(x)) return NA_S
src/main/character.c:435-438 (do_strsplit) contains the following code:
for (i = 0; i < tlen; i++)
if (getCharCE(STRING_ELT(tok, 0)) == CE_UTF8) use_UTF8 = TRUE;
for (i = 0; i < len; i++)
if (getCharCE(STRING_ELT(x, 0)) == CE_UTF8) use_UTF8 = TRUE;
since both loops iterate
Wacek Kusnierczyk wrote:
> William Dunlap wrote:
>
>> Would your patched code affect the following
>> use of regexpr's output as input to substr, to
>> pull out the matched text from the string?
>>> x<-c("ooo","good food",&q
William Dunlap wrote:
>
> Would your patched code affect the following
> use of regexpr's output as input to substr, to
> pull out the matched text from the string?
>> x<-c("ooo","good food","bad")
>> r<-regexpr("o+", x)
>> substring(x,r,attr(r,"match.length")+r-1)
>[1] "ooo" "oo"
(diverted to r-devel, a source code patch attached)
Wacek Kusnierczyk wrote:
> Allan Engelhardt wrote:
>
>> Immaterial, yes, but it is always good to test :) and your solution
>> *is* faster and it is even faster if you can assume byte strings:
>>
>
> :)
&g
Martin Maechler wrote:
>
> I have very slightly modified the changes (to get rid of -Wall
> warnings) and also exported the function as Rf_dropTrailing0(),
> and tested the result with 'make check-all' .
> As the change seems reasonable and consequent, and as
> it seems not to produce any problems
sec. 1.1 says:
"both types of node structure have as their first three fields a 32-bit
sxpinfo header and then three pointers [...]"
that's *four* fields, as seen in src/include/Rinternals.h:208+:
#define SEXPREC_HEADER \
struct sxpinfo_struct sxpinfo; \
struct SEXPREC *attrib; \
str
Wacek Kusnierczyk wrote:
> Wacek Kusnierczyk wrote:
>
>> Kynn Jones wrote:
>>
>>
>>
>>> In general, I'm looking for all the information I can find on the subject of
>>> dynamic function definition (i.e. using code to automate t
Wacek Kusnierczyk wrote:
> Kynn Jones wrote:
>
>
>> In general, I'm looking for all the information I can find on the subject of
>> dynamic function definition (i.e. using code to automate the definition of
>> functions at runtime). I'm most inter
Kynn Jones wrote:
> Hi. I'm pretty new to R, but I've been programming in other languages for
> some time. I have a couple of questions regarding programming with function
> objects.
> 1. Is there a way for a function to refer generically to all its actual
> arguments as a list? I'm thinking of
Ben Bolker wrote:
> It's my vague impression that View() is workable on Windows and maybe
> on MacOS, but on Ubuntu Linux 9.04 (intrepid) it seems completely
> unstable. I can reliably crash R by trying to look at a very small,
> simple data frame ...
>
on my 8.04, r is reliable at crashing
Peter Dalgaard wrote:
> Will Gray wrote:
>>
>> Perhaps this is the intended behavior, but I discovered that unsplit
>> throws an error when it tries to set rownames of a variable that has
>> no dimension. This occurs when unsplit is passed a list of
>> data.frames that have only a single column.
>
hadley wickham wrote:
> On Fri, May 8, 2009 at 10:11 AM, Romain Francois
> wrote:
>
>> strapply in package gsubfn brings elegance here:
>>
>>
>>> txt <- 'bar'
>>> rx <- "<(.*?)>(.*?)"
>>> strapply( txt, rx, c , perl = T )
>>>
>> [[1]]
>> [1] "foo" "bar" "foo"
>>
>> Too bad you have
Romain Francois wrote:
> strapply in package gsubfn brings elegance here:
>
> > txt <- 'bar'
> > rx <- "<(.*?)>(.*?)"
> > strapply( txt, rx, c , perl = T )
> [[1]]
> [1] "foo" "bar" "foo"
>
sure, but this does not, in any way, make it less strange that gsub is
not vectorized.
> Too bad you have
Romain Francois wrote:
>
>txt <- grep( '^ TRUE )
> rx <- '^.*?(.*?).*(.*?).*$'
>out <- data.frame(
>url = gsub( rx, "\\1", txt ),
>group = gsub( rx, "\\2", txt ),
>description = gsub( rx, "\\3", txt ),
looking at this bit of your code, i wonder why gsub is not
Stavros Macrakis wrote:
> These look like important improvements. As a relative newcomer to the R
> community, I'm not sure I understand what the procedures are for such
> changes.
>
> In particular, does the fact that the changes were committed to R-devel mean
> that the changes have already been
Gabor Grothendieck wrote:
> On Fri, Apr 24, 2009 at 6:45 AM, wrote:
>
>> Yes, the documentation will also have to be amended, but apart
>> from that, would people see a big problem with the "8192" limit
>> which now is suddenly of greater importance
>> {{as I said all along; hence my question
maech...@stat.math.ethz.ch wrote:
>
> vQ> sprintf has a documented limit on strings included in the output
> using the
> vQ> format '%s'. It appears that there is a limit on the length of
> strings included
> vQ> with, e.g., the format '%d' beyond which surprising things happen
> (o
maech...@stat.math.ethz.ch wrote:
>
> vQ> sprintf has a documented limit on strings included in the output
> using the
> vQ> format '%s'. It appears that there is a limit on the length of
> strings included
> vQ> with, e.g., the format '%d' beyond which surprising things happen
> (o
sprintf has a limit on the length of a string produced with a '%s'
specification:
nchar(sprintf('%1s', ''))
# 8191
nchar(sprintf('%*s', 1, ''))
# 8191
This is sort of documented in ?sprintf:
" There is a limit of 8192 bytes on elements of 'fmt' and also on
strings inclu
Thomas Lumley wrote:
>
> The explanation is that quote() is a primitive function and that the
> argument matching rules do not apply to primitives. That section of
> the R Language definition should say that primitives are excluded; it
> is documented in ?.Primitive.
thanks. indeed, the documen
Stavros Macrakis wrote:
> On Wed, Apr 1, 2009 at 5:11 PM, Wacek Kusnierczyk <
> waclaw.marcin.kusnierc...@idi.ntnu.no> wrote:
>
>
>> Stavros Macrakis wrote:
>> ...
>> i think this concords with the documentation in the sense that in an
>> assignme
Wacek Kusnierczyk wrote:
>
> and btw. the following is also weird:
>
> quote(a=1)
> # 1
>
> not because '=' works as named argument specifier (so that the result
> would be something like `=`(a, 1)),
i meant to write: not because '=' does not
Peter Dalgaard wrote:
> Wacek Kusnierczyk wrote:
>> Stavros Macrakis wrote:
>>>> `->`
>>>>
>>> Error: object "->" not found
>>>
>>
>> that's weird!
>
> Why???
>
partly because it was april fools.
Stavros Macrakis wrote:
> The documentation for assignment says:
>
> In all the assignment operator expressions, 'x' can be a name or
> an expression defining a part of an object to be replaced (e.g.,
> 'z[[1]]'). A syntactic name does not need to be quoted, though it
> can be
Martin Maechler wrote:
>
> Using 'bug' (without any qualifying "?" or "possible" ..)
> in the subject line is still a bit unfriendly...
>
is suggesting that a poster includes 'excel bug' in the subject line [1]
friendly??
vQ
[1] https://stat.ethz.ch/pipermail/r-help/2009-March/190119.html
Martin Maechler wrote:
>
> Your patch is basically only affecting the default
> method = "pearson". For (most) other cases, 'y = NULL' would
> still remain *the* way to save computations, unless we'd start
> to use an R-level equivalent [which I think does not exist] of
> your C trick (DATAPT
Martin Maechler wrote:
>
> WK> i attach the patch post for reference. note that you need to fix all
> of
> WK> the functions in duplicated.R that share the buggy code. (yes, this
> was
> WK> another thread; i submitted a bug report, and then sent a follow-up
> WK> post with a p
svn revert -R src
patch -p0 < duplicated.R.diff
tools/rsync-recommended
./configure
make
make check
and now
duplicated(data.frame(), incomparables=NA)
# error: argument 'incomparables != FALSE' is not used (yet)
regards,
vQ
waclaw.marcin.kusnier
Stavros Macrakis wrote:
> The documentation of as.data.frame is not explicit about how it generates
> column names for the simple vector case, but it seems to use the character
> form of the quoted argument, e.g.
>
> names(as.data.frame(1:3))
> [1] "1:3"
>
> But there is a strange case:
>
> names(a
Martin Maechler wrote:
>
> WK> what the documentation *fails* to tell you is that the parameter
> WK> 'incomparables' is defunct
>
> No, not "defunct", but the contrary of it,
> "not yet implemented" !
>
that's my bad english, again. sorry.
> WK> # data as above, or any data frame
Martin Maechler wrote:
(...)
> WK> which shows that raw won't coerce to the four first types in the
> WK> 'hierarchy' (excluding NULL), but it will to character, list, and
> WK> expression.
>
> WK> suggestion: improve the documentation, or adapt the implementation
> to
> WK
figure
make
make check
and now
duplicated(data.frame(), incomparables=NA)
# error: argument 'incomparables != FALSE' is not used (yet)
regards,
vQ
waclaw.marcin.kusnierc...@idi.ntnu.no wrote:
> Full_Name: Wacek Kusnierczyk
> Version: 2.8.0 and 2.10.0 r48242
>
Romain Francois wrote:
> Wacek Kusnierczyk wrote:
>> redirected to r-devel, because there are implementational details of
>> [.data.frame discussed here. spoiler: at the bottom there is a fairly
>> interesting performance result.
>>
>> Romain Francois wrote:
>
redirected to r-devel, because there are implementational details of
[.data.frame discussed here. spoiler: at the bottom there is a fairly
interesting performance result.
Romain Francois wrote:
>
> Hi,
>
> This is a bug I think. [.data.frame treats its arguments differently
> depending on the num
Sklyar, Oleg (London) wrote:
> typo as simple as %S instead of %s segfaults R devel:
>
not exactly:
sprintf('%S', 'aa')
# error: unrecognised format at end of string
without a segfault. but with another format specifier behind, it will
cause a segfault.
interestingly, here's again t
William Dunlap wrote:
> Doesn't Fortran still require that the arguments to
> a function not alias each other (in whole or in part)?
>
what do you mean? the following works pretty fine:
echo '
program foo
implicit none
integer, target :: a = 1
integer, poi
as
> dput(list(23),control="all"), but as I understand it, pairlists will
> become non-user-visible at some point.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
---
(this post suggests a patch to the sources, so i allow myself to divert
it to r-devel)
Bert Gunter wrote:
> x a numeric vector, matrix or data frame.
> y NULL (default) or a vector, matrix or data frame with compatible
> dimensions to x. The default is equivalent to y = x (but more efficient).
Martin Maechler wrote:
>
> >> more verbously, all NULL objects in R are identical, or as the
> >> help page says, there's only ``*The* NULL Object'' in R,
> >> i.e., NULL cannot get any attributes.
> >>
>
> WK> yes, but that's not the issue. the issue is that names(x)<- seems
Martin Maechler wrote:
>
> [.. omitted part no longer relevant ]
>
> WK> however, the following has a different pattern:
> >>
> WK> x = NULL
> WK> dput(x)
> WK> # NULL
> WK> names(x) = character(0)
> WK> # error: attempt to set an attribute on NULL
> >>
Martin Maechler wrote:
>>>>>> "WK" == Wacek Kusnierczyk
>>>>>>
>>>>>>
> WK> somewhat related to a previous discussion [1] on how 'names<-' would
> WK> sometimes modify its argument i
somewhat related to a previous discussion [1] on how 'names<-' would
sometimes modify its argument in place, and sometimes produce a modified
copy without changing the original, here's another example of how it
becomes visible to the user when r makes or doesn't make a copy of an
object:
x = N
there seems to be something wrong with r's regexing. consider the
following example:
gregexpr('a*|b', 'ab')
# positions: 1 2
# lengths: 1 1
gsub('a*|b', '.', 'ab')
# ..
where the pattern matches any number of 'a's or one b, and replaces the
match with a dot, globally. the a
strangely enough, the way r handles the same sequence of expressions on
different occasions varies:
# fresh session 1
e = simpleError('foo')
sprintf('%s', e)
# segfault: address 0x202, cause memory not mapped
# ^c
sprintf('%s', e)
# error in sprintf("%s", e) : 'getEncCh
Wacek Kusnierczyk wrote:
> interestingly,
>
> c(1, as.raw(1))
> # error: type 'raw' is unimplemented in 'RealAnswer'
>
>
three more comments.
(1)
the above is interesting in the light of what ?c says:
"
The output type is determined from
Wacek Kusnierczyk wrote:
>
>
> there's one more curiosity about factors, in particular, ordered factors:
>
> ord <- as.ordered(nums); ord
> # [1] 0.300 0.3 0.3
> 0.300
> # Levels: 0.300
Petr Savicky wrote:
> On Mon, Mar 16, 2009 at 07:39:23PM -0400, Stavros Macrakis wrote:
> ...
>
>> Let's look at the extraordinarily poor behavior I was mentioning. Consider:
>>
>> nums <- (.3 + 2e-16 * c(-2,-1,1,2)); nums
>> [1] 0.3 0.3 0.3 0.3
>>
>> Though they all print as .3 with the default
Petr Savicky wrote:
> On Mon, Mar 16, 2009 at 06:36:53AM -0700, Daniel Murphy wrote:
>
>> Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get
>>
>>> 0.3 %in% seq(from=.2,to=.3)
>>>
>> [1] FALSE
>>
>
> As others already pointed out, you should use seq(from=
Duncan Murdoch wrote:
> On 3/16/2009 9:36 AM, Daniel Murphy wrote:
>> Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3).
>> I get
>>> 0.3 %in% seq(from=.2,to=.3)
>> [1] FALSE
>> Yet
>>> 0.3 %in% c(.2,.3)
>> [1] TRUE
>> For arbitrary sequences, this "invisible .3" has been problema
Thomas Lumley wrote:
>
> Wacek,
>
> In this case I think the *tmp* dates from the days before backticks,
> when it was not a legal name (it still isn't) and it was much, much
> harder to use illegal names, so the collision issue really didn't exist.
>
thanks for the explanation.
> You're right ab
somewhat one the side,
l = list(1)
l[[2]]
# error, index out of bounds
l[2][[1]]
# NULL
that is, we can't extract from l any element at an index exceeding the
list's length (if we could, it would have been NULL or some sort of
_NA_list), but we can extract a sublist at an
Berwin A Turlach wrote:
>
>> '*tmp*' = 0
>> `*tmp*`
>> # 0
>>
>> x = 1
>> names(x) = 'foo'
>> `*tmp*`
>> # error: object "*tmp*" not found
>>
>> `*ugly*`
>>
>
> I agree, and I am a bit flabbergasted. I had not expected that
> something like this would happen and I am indeed not aware of anyth
Stavros Macrakis wrote:
>
> Well, that's one issue. But another is that there should be a
> specification addressed to users, who should not have to understand
> internals.
>
this should really be taken seriously.
vQ
__
R-devel@r-project.org mailin
Berwin A Turlach wrote:
>
> 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")
Berwin A Turlach wrote:
> On Sat, 14 Mar 2009 07:22:34 +0100
> Wacek Kusnierczyk wrote:
>
> [...]
>
>>> Well, I don't see any new object created in my workspace after
>>> x <- 4
>>> names(x) <- "foo"
>>> Do you?
&
Berwin A Turlach wrote:
> On Fri, 13 Mar 2009 19:41:42 +0100
> Wacek Kusnierczyk wrote:
>
>
>
>> indeed, you said "R supposedly uses call-by-value (though we know how
>> to circumvent that, don't we?)".
>>
>> in that vain, R supposed
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 '
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 understa
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 explana
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 corr
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 s
G. Jay Kerns wrote:
> Wacek Kusnierczyk wrote:
>
>
>
> I am prompted to imagine someone pointing out to the volunteers of the
> International Red Cross - on the field of a natural disaster, no less
> - that their uniforms are not an acceptably consistent shade of
> pink.
Simon Urbanek wrote:
>
> On Mar 12, 2009, at 11:12 , Wacek Kusnierczyk wrote:
>
>> Simon Urbanek wrote:
>>>
>>> On Mar 11, 2009, at 10:52 , Simon Urbanek wrote:
>>>
>>>> Wacek,
>>>>
>>>> Peter gave you a full answer expl
Berwin A Turlach wrote:
> On Thu, 12 Mar 2009 15:21:50 +0100
> Wacek Kusnierczyk wrote:
>
>
>> seems to suggest? is not the purpose of documentation to clearly,
>> ideally beyond any doubt, specify what is to be specified?
>>
>
> The R Languag
Simon Urbanek wrote:
>
> On Mar 11, 2009, at 10:52 , Simon Urbanek wrote:
>
>> Wacek,
>>
>> Peter gave you a full answer explaining it very well. If you really
>> want to be able to trace each instance yourself, you have to learn
>> far more about R internals than you apparently know (and Peter hin
l...@stat.uiowa.edu wrote:
> Thanks to Stavros for the report. This should now be fixed in R-devel.
indeed, though i find some of the error messages strange:
(function(a=a) -a)()
# Error in (function(a = a) -a)() :
# element 1 is empty;
# the part of the args list of '-' being
Wacek Kusnierczyk wrote:
> Berwin A Turlach wrote:
>
>
>> This is similar to the discussion what value i should have in the
>> following C snippet:
>> i = 0;
>> i += i++;
>>
>>
>
>
> in fact, your example is useless
Berwin A Turlach wrote:
> On Thu, 12 Mar 2009 10:53:19 +0100
> Wacek Kusnierczyk wrote:
>
>
>> well, ?'names<-' says:
>>
>> "
>> Value:
>> For 'names<-', the updated object.
>> "
>>
>> which i
Berwin A Turlach wrote:
>
> Whoever said that must have been at that moment not as precise as he or
> she could have been. Also, R does not behave according to what people
> say on this list (which is good, because some times people they wrong
> things on this list) but according to how it is docu
Wacek Kusnierczyk wrote:
>
> is precisely why i'd think that the prefix 'names<-' should never do
> destructive modifications, because that's what x = 'names<-'(x, 'foo'),
> and thus also names(x) = 'foo', is for.
>
>
to
Berwin A Turlach wrote:
> On Wed, 11 Mar 2009 20:29:14 +0100
> Wacek Kusnierczyk wrote:
>
>
>> Simon Urbanek wrote:
>>
>>> Wacek,
>>>
>>> Peter gave you a full answer explaining it very well. If you really
>>> want to be able to
Berwin A Turlach wrote:
> On Wed, 11 Mar 2009 20:31:18 +0100
> Wacek Kusnierczyk wrote:
>
>
>> Simon Urbanek wrote:
>>
>>> On Mar 11, 2009, at 10:52 , Simon Urbanek wrote:
>>>
>>>
>>>> Wacek,
>>>>
>>&g
Simon Urbanek wrote:
>
> On Mar 11, 2009, at 10:52 , Simon Urbanek wrote:
>
>> Wacek,
>>
>> Peter gave you a full answer explaining it very well. If you really
>> want to be able to trace each instance yourself, you have to learn
>> far more about R internals than you apparently know (and Peter hin
Simon Urbanek wrote:
> Wacek,
>
> Peter gave you a full answer explaining it very well. If you really
> want to be able to trace each instance yourself, you have to learn far
> more about R internals than you apparently know (and Peter hinted at
> that). Internally x=1 an x=c(1) are slightly differ
t functions, PROVIDED
> that the x is not used by anything else. On the least suspicion that
> something else is using the object, a copy of x is made before the
> modification.
>
> So
>
> (A) you should not use code like y <- "foo<-"(x, bar)
>
> becaus
Duncan Murdoch wrote:
> On 10/03/2009 4:35 PM, michael_ka...@earthlink.net wrote:
>> Full_Name: Michael Aaron Karsh
>> Version: 2.8.0
>> OS: Windows XP
>> Submission from: (NULL) (164.67.71.215)
>>
>>
>> When I try to say if (method==f), where f is a function, it says that
>> the
>> comparison is o
Peter Dalgaard wrote:
>
> (*) unless you mess with match.call() or substitute() and the like. But
> that's a different story.
>
different or not, it is a story that happens quite often -- too often,
perhaps -- to the degree that one may be tempted to say that the
semantics of argument passing i
Stavros Macrakis wrote:
>>> (B) you cannot (easily) predict whether or not x will be modified
>>> destructively
>>>
>> that's fine, thanks, but i must be terribly stupid as i do not see how
>> this explains the examples above. where is the x used by something else
>> in the first example, s
Peter Dalgaard wrote:
> Wacek Kusnierczyk wrote:
>
>> playing with 'names<-', i observed the following:
>>
>> x = 1
>> names(x)
>> # NULL
>> 'names<-'(x, 'foo')
>> # c(foo=1)
>>
playing with 'names<-', i observed the following:
x = 1
names(x)
# NULL
'names<-'(x, 'foo')
# c(foo=1)
names(x)
# NULL
where 'names<-' has a functional flavour (does not change x), but:
x = 1:2
names(x)
# NULL
'names<-'(x, 'foo')
# c(foo=1, 2)
1 - 100 of 156 matches
Mail list logo
