Re: [Rd] 'unique' error message is printed despite silent=TRUE (PR#13547)

2009-02-22 Thread Wacek Kusnierczyk
macra...@alum.mit.edu wrote: In 2.8.0/Windows Vista: When 'unique' gives a type error message, it prints out even if errors are being caught: try(unique(quote(hello)),silent=TRUE) hello This comes from the .Internal unique routine:

Re: [Rd] 'unique' error message is printed despite silent=TRUE (PR#13547)

2009-02-22 Thread Wacek Kusnierczyk
Peter Dalgaard wrote: macra...@alum.mit.edu wrote: snip try(.Internal(unique(quote(hello),NULL,NULL)),silent=TRUE) hello I guess it is using the internal equivalent of print rather than the internal equivalent of stop. silent=TRUE is a red herring (this has nothing to do with try()).

Re: [Rd] 'unique' error message is printed despite silent=TRUE (PR#13547)

2009-02-22 Thread Wacek Kusnierczyk
Duncan Murdoch wrote: hmm, why wouldn't you use something like DEBUG(x) with DEBUG being a macro defined so that it's replacement is void unless a specific flag or environment variable is set specifically for the purpose of debugging? you would then avoid confusing users' code just

Re: [Rd] 'unique' error message is printed despite silent=TRUE (PR#13547)

2009-02-22 Thread Wacek Kusnierczyk
Duncan Murdoch wrote: On 22/02/2009 4:38 PM, Wacek Kusnierczyk wrote: Duncan Murdoch wrote: hmm, why wouldn't you use something like DEBUG(x) with DEBUG being a macro defined so that it's replacement is void unless a specific flag or environment variable is set specifically

Re: [Rd] [R] Semantics of sequences in R

2009-02-22 Thread Wacek Kusnierczyk
g'orning, Berwin A Turlach wrote: G'day Stavros, snip In many cases, the orthogonal design is pretty straightforward. And in the cases where the operation is currently an error (e.g. sort(list(...))), I'd hope that wouldn't break existing code. [...] This could actually be an

Re: [Rd] [R] Semantics of sequences in R

2009-02-23 Thread Wacek Kusnierczyk
Stavros Macrakis wrote: ...sort(list(...))), I'd hope that wouldn't break existing code. [...] ...sort is a generic function, and for sort(list(...)) to work, it would have to dispatch to a function called sort.list;... such a function exists already and it is not for sorting

Re: [Rd] [R] Semantics of sequences in R

2009-02-23 Thread Wacek Kusnierczyk
Wacek Kusnierczyk wrote: btw. it's interesting that in revision 38438 (2006) Prof Brian Ripley introduced (or so does the commit message say) sorting complex numbers, and now you have things like: 1i 0i # Error in 0+0i 0+1i : invalid comparison with complex values sort(c(1i

Re: [Rd] [R] Semantics of sequences in R

2009-02-23 Thread Wacek Kusnierczyk
Berwin A Turlach wrote: On Mon, 23 Feb 2009 08:52:05 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: Berwin A Turlach wrote: G'day Stavros, snip In many cases, the orthogonal design is pretty straightforward. And in the cases where

Re: [Rd] [R] Semantics of sequences in R

2009-02-23 Thread Wacek Kusnierczyk
Berwin A Turlach wrote: snip can you give one concrete example, and suggest how to estimate how much old code would involve the same issue? Check out the svn source of R, run configure, do whatever change you want to sort.list, make, make check FORCE=FORCE. That should give you an

Re: [Rd] [R] Semantics of sequences in R

2009-02-23 Thread Wacek Kusnierczyk
Berwin A Turlach wrote: it's not just making changes to sort.list, berwin. sort.list calls .Internal order, and this one would have to be modified in order to accommodate for the additional comparator argument. [...] Well, you could start of with an R only implementation and then

[Rd] a question about (

2009-02-23 Thread Wacek Kusnierczyk
i wonder why the following approach to make an 'object' executable could not be made to work: foo = 1:3 class(object) = c('foo', class(foo)) '(.foo' = function(foo, fun) sapply(foo, fun) foo # 1 2 3 foo(function(x) x^2) # error: no function foo defined the actual

Re: [Rd] [R] Semantics of sequences in R

2009-02-24 Thread Wacek Kusnierczyk
Berwin A Turlach wrote: i am sending *no* patch for this. the issue has to be first discussed on the design level, and only then, if accepted, should anyone -- me, for example -- make an attempt to implement it. tell me you want to listen to what i have to say, and we can discuss.

Re: [Rd] [R] are arithmetic comparison operators binary?

2009-02-24 Thread Wacek Kusnierczyk
Martin Maechler wrote: Thank you, Wacek, though .. wrong mailing list WK apologies. i was actually asking for explanation, assuming that it WK might be my misunderstanding, rather than reporting a bug. ( yes; but it is really a technical topic, also touching on

Re: [Rd] [R] are arithmetic comparison operators binary?

2009-02-24 Thread Wacek Kusnierczyk
Wacek Kusnierczyk wrote: The patch for src/main/arithmetic.c was prepared as follows: svn co https://svn.R-project.org/R/trunk/ cd trunk tools/rsync-recommended # modifications made to src/main/character.c svn diff do_grep.diff The patched sources were successfully compiled and tested

Re: [Rd] [R] Semantics of sequences in R

2009-02-24 Thread Wacek Kusnierczyk
Dimitris Rizopoulos wrote: in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. Take human languages as an example and in particular, English. I do not know the history

Re: [Rd] [R] learning R

2009-02-25 Thread Wacek Kusnierczyk
: p = pairlist(a=1) names(p) # a names(p) = 'b' # fine is.vector(p) # FALSE which is incoherent with the above error message, in that p is *not* a vector. vQ Wacek Kusnierczyk wrote: the following: names(a[2]) = 'foo' has (partially) a functional flavour

Re: [Rd] [R] Problems with ARIMA models?

2009-02-26 Thread Wacek Kusnierczyk
that's interesting, marie. on his webpage [1], david s. stoffer provides concrete arguments for why the r arima function in the stats package should be considered to produce misleading, if not just wrong results. david (cc:ed for reference) reported the issue in october 2005, bug report #8231

Re: [Rd] Persistent data structures for R

2009-02-27 Thread Wacek Kusnierczyk
hadley wickham wrote: Hi all, Has anyone thought about developing persistent (http://en.wikipedia.org/wiki/Persistent_data_structure) functional data structures for R? A persistent data frame, for example, would seem like a possible way of drastically reducing memory consumption for many

Re: [Rd] question

2009-03-07 Thread Wacek Kusnierczyk
mark.braving...@csiro.au wrote: The syntax for returning multiple arguments does not strike me as particularly appealing. would it not possible to allow syntax like: f= function() { return( rnorm(10), rnorm(20) ) } (a,d$b) = f() FWIW, my own solution is to define a

Re: [Rd] question

2009-03-07 Thread Wacek Kusnierczyk
ivo...@gmail.com wrote: Gentlemen---these are all very clever workarounds, hacks around the lack of a feature but please forgive me for voicing my own opinion: IMHO, returning multiple values in a statistical language should really be part of the language itself. returning multiple values

Re: [Rd] question

2009-03-07 Thread Wacek Kusnierczyk
Gabor Grothendieck wrote: On Sat, Mar 7, 2009 at 9:38 AM, ivo welch ivo...@gmail.com wrote: hi gabor: this would be difficult to do. I don't think you want to read my programs. it would give you an appreciation of what ugly horror programs end users can write in the beautiful R language

Re: [Rd] question

2009-03-07 Thread Wacek Kusnierczyk
Gabor Grothendieck wrote: as gabor says in another post, you probably should first show why having multiple value returns would be useful in r. however, i don't think there are good counterarguments anyway, and putting on you the burden of proving a relatively obvious (or not so?) thing is a

Re: [Rd] question

2009-03-07 Thread Wacek Kusnierczyk
Gabor Grothendieck wrote: I've provided an argument against it and no one has provided one for it. The so-called identical code Ivo showed was not identical and, in fact, was flawed. no, you're wrong. you think of the part where ivo shows what he'd like to have; the example i was

Re: [Rd] question

2009-03-07 Thread Wacek Kusnierczyk
Gabor Grothendieck wrote: - this still does not allow one to use the names directly, only as L$first etc., with the syntactic and semantic (longer lookup times) penalty; That's how it should be done. Using the auto split you get many variables which is not desirable. it encourages bad

Re: [Rd] question

2009-03-07 Thread Wacek Kusnierczyk
Thomas Petzoldt wrote: Patrick Burns wrote: One idea of program design is that users should be protected against themselves. ... and r coherently implements this idea :] It is my experience that users, especially novices, tend to over-split items rather than over-clump items. The fact

Re: [Rd] question

2009-03-08 Thread Wacek Kusnierczyk
ivo...@gmail.com wrote: Gentlemen---these are all very clever workarounds, but please forgive me for voicing my own opinion: IMHO, returning multiple values in a statistical language should really be part of the language itself. there should be a standard syntax of some sort, whatever it

Re: [Rd] E``rrors in recursive default argument references

2009-03-09 Thread Wacek Kusnierczyk
Stavros Macrakis wrote: Tested in: R version 2.8.1 (2008-12-22) / Windows Recursive default argument references normally give nice clear errors. In the first set of examples, you get the error: Error in ... : promise already under evaluation: recursive default argument reference or

[Rd] surprising behaviour of names-

2009-03-10 Thread Wacek Kusnierczyk
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)

Re: [Rd] surprising behaviour of names-

2009-03-10 Thread Wacek Kusnierczyk
Peter Dalgaard wrote: Wacek Kusnierczyk wrote: 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

Re: [Rd] surprising behaviour of names-

2009-03-10 Thread Wacek Kusnierczyk
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, so that

Re: [Rd] surprising behaviour of names-

2009-03-10 Thread Wacek Kusnierczyk
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 in r

Re: [Rd] logical comparison of functions (PR#13588)

2009-03-10 Thread Wacek Kusnierczyk
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 only possible for

Re: [Rd] surprising behaviour of names-

2009-03-10 Thread Wacek Kusnierczyk
(*) unless you mess with match.call() or substitute() and the like. But that's a different story. -- --- Wacek Kusnierczyk, MD PhD Email: w...@idi.ntnu.no Phone: +47 73591875, +47 72574609 Department of Computer

Re: [Rd] surprising behaviour of names-

2009-03-11 Thread Wacek Kusnierczyk
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 different

Re: [Rd] surprising behaviour of names-

2009-03-11 Thread Wacek Kusnierczyk
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 hinted at

Re: [Rd] surprising behaviour of names-

2009-03-12 Thread Wacek Kusnierczyk
Berwin A Turlach wrote: On Wed, 11 Mar 2009 20:31:18 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: 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

Re: [Rd] surprising behaviour of names-

2009-03-12 Thread Wacek Kusnierczyk
Berwin A Turlach wrote: On Wed, 11 Mar 2009 20:29:14 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: 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

Re: [Rd] surprising behaviour of names-

2009-03-12 Thread Wacek Kusnierczyk
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

Re: [Rd] surprising behaviour of names-

2009-03-12 Thread Wacek Kusnierczyk
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 make the point differently, i'd expect the following two to be equivalent: x

Re: [Rd] surprising behaviour of names-

2009-03-12 Thread Wacek Kusnierczyk
Berwin A Turlach wrote: On Thu, 12 Mar 2009 10:53:19 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: well, ?'names-' says: Value: For 'names-', the updated object. which is only partially correct, in that the value will sometimes be an updated *copy

Re: [Rd] surprising behaviour of names-

2009-03-12 Thread Wacek Kusnierczyk
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 because the result here is clearly specified by the semantics (as far as i

Re: [Rd] E``rrors in recursive default argument references

2009-03-12 Thread Wacek Kusnierczyk
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

Re: [Rd] surprising behaviour of names-

2009-03-12 Thread Wacek Kusnierczyk
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 hinted at

Re: [Rd] surprising behaviour of names-

2009-03-12 Thread Wacek Kusnierczyk
Berwin A Turlach wrote: On Thu, 12 Mar 2009 15:21:50 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: seems to suggest? is not the purpose of documentation to clearly, ideally beyond any doubt, specify what is to be specified? The R Language Definition manual

Re: [Rd] surprising behaviour of names-

2009-03-12 Thread Wacek Kusnierczyk
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 explaining it very well. If you really want to be able to trace each instance yourself, you have to learn

Re: [Rd] surprising behaviour of names-

2009-03-12 Thread Wacek Kusnierczyk
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... or that the screws

Re: [Rd] surprising behaviour of names-

2009-03-13 Thread Wacek Kusnierczyk
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

Re: [Rd] surprising behaviour of names-

2009-03-13 Thread Wacek Kusnierczyk
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

Re: [Rd] surprising behaviour of names-

2009-03-13 Thread Wacek Kusnierczyk
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

Re: [Rd] surprising behaviour of names-

2009-03-13 Thread Wacek Kusnierczyk
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

Re: [Rd] surprising behaviour of names-

2009-03-13 Thread Wacek Kusnierczyk
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

Re: [Rd] surprising behaviour of names-

2009-03-14 Thread Wacek Kusnierczyk
Berwin A Turlach wrote: On Sat, 14 Mar 2009 07:22:34 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: [...] Well, I don't see any new object created in my workspace after x - 4 names(x) - foo Do you? of course not. that's why i'd say the two

Re: [Rd] surprising behaviour of names-

2009-03-15 Thread Wacek Kusnierczyk
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) to prove that

Re: [Rd] Definition of [[

2009-03-15 Thread Wacek Kusnierczyk
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 mailing

Re: [Rd] surprising behaviour of names-

2009-03-16 Thread Wacek Kusnierczyk
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 anything in the documentation

Re: [Rd] Definition of [[

2009-03-16 Thread Wacek Kusnierczyk
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

Re: [Rd] surprising behaviour of names-

2009-03-16 Thread Wacek Kusnierczyk
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 about the

Re: [Rd] Match .3 in a sequence

2009-03-16 Thread Wacek Kusnierczyk
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 problematic. What is the

Re: [Rd] Match .3 in a sequence

2009-03-16 Thread Wacek Kusnierczyk
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

Re: [Rd] Match .3 in a sequence

2009-03-17 Thread Wacek Kusnierczyk
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 precision

Re: [Rd] Match .3 in a sequence

2009-03-17 Thread Wacek Kusnierczyk
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 0.3 0.3 0.300 ord[1

Re: [Rd] [R] incoherent conversions from/to raw

2009-03-19 Thread Wacek Kusnierczyk
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 the highest type of the components

Re: [Rd] sprintf causes a segfault (PR#13613)

2009-03-20 Thread Wacek Kusnierczyk
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) :

[Rd] gsub('(.).(.)(.)', '\\3\\2\\1', 'gsub')

2009-03-21 Thread Wacek Kusnierczyk
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

[Rd] incoherent treatment of NULL

2009-03-23 Thread Wacek Kusnierczyk
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 =

Re: [Rd] incoherent treatment of NULL

2009-03-23 Thread Wacek Kusnierczyk
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 to WK try

Re: [Rd] dput(as.list(function...)...) bug

2009-03-23 Thread Wacek Kusnierczyk
-- --- Wacek Kusnierczyk, MD PhD Email: w...@idi.ntnu.no Phone: +47 73591875, +47 72574609 Department of Computer and Information Science (IDI) Faculty of Information Technology, Mathematics and Electrical Engineering (IME) Norwegian University of Science and Technology (NTNU) Sem

Re: [Rd] [R] variance/mean

2009-03-23 Thread Wacek Kusnierczyk
(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).

Re: [Rd] [R] variance/mean

2009-03-24 Thread Wacek Kusnierczyk
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,

Re: [Rd] typo in sprintf format string segfaults R

2009-03-26 Thread Wacek Kusnierczyk
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

Re: [Rd] [R] [.data.frame and lapply

2009-03-27 Thread Wacek Kusnierczyk
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 number

Re: [Rd] [R] [.data.frame and lapply

2009-03-28 Thread Wacek Kusnierczyk
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: Hi, This is a bug I think. [.data.frame

Re: [Rd] duplicated fails to rise correct errors (PR#13632)

2009-03-30 Thread Wacek Kusnierczyk
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 OS: Ubuntu 8.04 Linux 32 bit

Re: [Rd] [R] incoherent conversions from/to raw

2009-03-31 Thread Wacek Kusnierczyk
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 a more

Re: [Rd] duplicated.data.frame {was [R] which rows are duplicates?}

2009-03-31 Thread Wacek Kusnierczyk
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 WK

Re: [Rd] as.data.frame peculiarities

2009-03-31 Thread Wacek Kusnierczyk
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:

Re: [Rd] duplicated.data.frame {was [R] which rows are duplicates?}

2009-03-31 Thread Wacek Kusnierczyk
(), 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 OS: Ubuntu 8.04 Linux 32 bit Submission from: (NULL) (129.241.110.161) In the following code

Re: [Rd] duplicated.data.frame {was [R] which rows are duplicates?}

2009-04-01 Thread Wacek Kusnierczyk
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 patch).

Re: [Rd] [R] variance/mean

2009-04-01 Thread Wacek Kusnierczyk
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 (DATAPTR(x) ==

Re: [Rd] Gamma funtion(s) bug

2009-04-01 Thread Wacek Kusnierczyk
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

Re: [Rd] Assignment to string

2009-04-01 Thread Wacek Kusnierczyk
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

Re: [Rd] [R] Definition of = vs. -

2009-04-02 Thread Wacek Kusnierczyk
Peter Dalgaard wrote: Wacek Kusnierczyk wrote: Stavros Macrakis wrote: `-` Error: object - not found that's weird! Why??? partly because it was april fools. but more seriously, it's because one could assume that in any syntactic expression with an operator involved

Re: [Rd] [R] Definition of = vs. -

2009-04-02 Thread Wacek Kusnierczyk
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 work as an assignment operator (or otherwise

Re: [Rd] Assignment to string

2009-04-02 Thread Wacek Kusnierczyk
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 assignment a string can work as a name. note that `foo bar` = 1

Re: [Rd] actual argument matching does not conform to the definition (PR#13634)

2009-04-02 Thread Wacek Kusnierczyk
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

[Rd] sprintf limits output string length with no warning/error message

2009-04-21 Thread Wacek Kusnierczyk
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

Re: [Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)

2009-04-23 Thread Wacek Kusnierczyk
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 (output

Re: [Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)

2009-04-24 Thread Wacek Kusnierczyk
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 (output

Re: [Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)

2009-04-27 Thread Wacek Kusnierczyk
Gabor Grothendieck wrote: On Fri, Apr 24, 2009 at 6:45 AM, maech...@stat.math.ethz.ch 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;

Re: [Rd] Some extensions to class inheritance and method selection

2009-04-29 Thread Wacek Kusnierczyk
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

Re: [Rd] proposed changes to RSiteSearch

2009-05-08 Thread Wacek Kusnierczyk
Romain Francois wrote: txt - grep( '^tr.*td align=right.*a', readLines( url ), value = TRUE ) rx - '^.*?a href=(.*?)(.*?)/a.*td(.*?)/td.*$' out - data.frame( url = gsub( rx, \\1, txt ), group = gsub( rx, \\2, txt ), description = gsub( rx, \\3, txt ),

Re: [Rd] proposed changes to RSiteSearch

2009-05-08 Thread Wacek Kusnierczyk
Romain Francois wrote: strapply in package gsubfn brings elegance here: txt - 'foobar/foo' 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 to pay

Re: [Rd] proposed changes to RSiteSearch

2009-05-08 Thread Wacek Kusnierczyk
hadley wickham wrote: On Fri, May 8, 2009 at 10:11 AM, Romain Francois romain.franc...@dbmail.com wrote: strapply in package gsubfn brings elegance here: txt - 'foobar/foo' rx - (.*?)(.*?)/(.*?) strapply( txt, rx, c , perl = T ) [[1]] [1] foo bar foo Too bad you have

Re: [Rd] unsplit list of data.frames with one column

2009-05-09 Thread Wacek Kusnierczyk
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. An

Re: [Rd] View() crashy on Ubuntu 9.04

2009-05-13 Thread Wacek Kusnierczyk
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

Re: [Rd] Qs: The list of arguments, wrapping functions...

2009-05-19 Thread Wacek Kusnierczyk
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

Re: [Rd] Qs: The list of arguments, wrapping functions...

2009-05-19 Thread Wacek Kusnierczyk
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 interested in introspection facilities and dynamic code

Re: [Rd] Qs: The list of arguments, wrapping functions...

2009-05-19 Thread Wacek Kusnierczyk
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 the definition of functions at runtime). I'm most interested

[Rd] minor correction to the r internals manual

2009-05-27 Thread Wacek Kusnierczyk
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; \

Re: [Rd] as.numeric(levels(factor(x))) may be a decreasing sequence

2009-05-27 Thread Wacek Kusnierczyk
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 in

  1   2   >