Re: [Rd] [R] Semantics of sequences in R
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 list. Omigod. There is a function called 'sort' which doesn't sort, and which follows the S3 conventions for sorting lists, but doesn't allow lists as an argument type. That *is* a mess! Well, if it's OK for sort.list to violate S3 naming conventions (presumably because it was defined before S3 was), then I suppose it would be OK for sort to violate S3 coding conventions in return, and dispatch in a non-standard way, e.g. if (is.list(x)) sort.S3.list(...) else UseMethod(sort) Ugly, but then so is sort.list according to svn, sort.list was introduced in late 1999 by Prof Brian Ripley (revision 6598, 'add sort.list for S compatibility'). however, the fancy 'have you called sort on a list' error message was added by Prof Brian Ripley in 2006, replacing the less confusing but still odd (to a naive user) message 'x must be atomic' produced when you call sort.list on a list. 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, 0i)) # 0i 1i vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
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, 0i)) # 0i 1i it's interesting also because one of the arguments for why sort does not operate on lists is that it is not clear how to compare their elements (see, e.g., [1]). so why would sort sort complex numbers, if r cannot compare them? arguing that sort cannot operate on lists because it does not know how to compare the elements is based on a misconception. algorithms for sorting are in essence ignorant of what the elements of the sequences to be sorted are; sorting works equally well with numbers, strings, functions, plants, waste, etc., provided that an appropriate comparator is specified. i think that the right design for sort and sort.list would be to have the former operate on atomic vectors (``real'' vectors, those that can be considered lists but they're not) with defaults for the respective types, and the latter operate on lists with no default for the comparator, even when all elements happen to be of the same type: sort(1:10) # fine sort(as.list(1:10)) # error: no comparator specified sort(as.list(1:10), ``) # fine vQ [1] http://tolstoy.newcastle.edu.au/R/e4/help/08/07/16231.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
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 the operation is currently an error (e.g. sort(list(...))), I'd hope that wouldn't break existing code. [...] This could actually be an example that would break a lot of existing code. sort is a generic function, and for sort(list(...)) to work, it would have to dispatch to a function called sort.list; and as Patrick Burns' The R Inferno points out, such a function exists already and it is not for sorting list. and you mean that sort.list not being applicable to lists is a) good design, and b) something that by noe means should be fixed, right? I neither said nor meant this and I do not see how what I said could be interpreted in such a way. I was just commenting to Stavros that the example he picked, hoping that it would not break existing code, was actually a bad one which potentially will break a lot (?) of existing code. would it, really? if sort.list were, in addition to sorting atomic vectors (can-be-considered-lists), able to sort lists, how likely would this be to break old code? can you give one concrete example, and suggest how to estimate how much old code would involve the same issue? sort.list, to be applied to an atomic vector, must be called explicitly on the vector, because calling sort will not automatically dispatch to sort.list (right?). so allowing sort.list to sort lists does not change anything in this respect -- except for that, as i suggested, if sort.list were requiring an explicit comparator, you'd have to add one wherever sort.list is called, but to accomodate for old code sort.list could actually check whether the argument is not an atomic vector. how much old code could be relying on the fact that sort.list raises an error when given a list? i suspect it's fairly unlikely that any single piece of code does; and if so, allowing sort.list to sort lists would not change anything here either. Also, until reading Patrick Burns' The R Inferno I was not aware of sort.list. That function had not registered with me since I hardly used it. which hints that potentially will break a lot (?) of existing code is a rather unlikely event. And I also have no need of calling sort() on lists. For em a lists is a flexible enough data structure such that defining a sort() command for them makes no sense; it could only work in very specific circumstances. i don't understand the first part: flexible enough data structure such that defining a sort() command for them makes no sense makes no sense. as to it could only work in very specific circumstances -- no, it would work for any list whatsoever, provided the user has a correctly implemented comparator. for example, i'd like to sort a list of vectors by the vectors' length -- is this a very exotic idea? In fact, currently you get: R cc - list(a=runif(4), b=rnorm(6)) R sort(cc) Error in sort.list(cc) : 'x' must be atomic for 'sort.list' Have you called 'sort' on a list? one of the most funny error messages you get in r. note also that, following rolf turner's lists and vectors unproven theorem, a vector can be considered a list I do not remember the exact context of Rolf's comments, but I believe he was talking in a more general sense and not in technical terms. indeed, he was blurring the concepts instead of referring to concrete documentation with clear specified meaning of the terms he used. I find it perfectly valid, even when talking about R, to say something like vectors are stored as a list of numbers in consecutive memory locations in memory. yes; and you can always say that 'vectors can be considered electrical charges', or better, 'vectors can be considered electrical charges, in some sense'. what sense of 'list' are you using here? i'd rather use the term 'array', unless confusing the user is the real purpose. (and to be really picky, you do not store numbers.) Clearly, in a phrase like this, we are not talking about vectors and list as defined by the R Language Definition or R Internals, or what functions like is.vector(), is.list() c return for various R objects. clearly, you can say anything you like, and then add 'i was not talking about x as defined by y'. the art is to talk about x as defined by y. BTW, as I mentioned once before, you might want to consider to lose these chips on your shoulders. berwin, it's been a tradition on this list to discourage people from commenting on the design and implementation of r whenever they think it's wrong. you really should be doing the opposite. as a chinese proverb says, a gem cannot be polished without friction. friction seems to be what you fear a
Re: [Rd] [R] Semantics of sequences in R
Dear vQ, vectors (can-be-considered-lists), can you please stop repeating this nonsense? I don't think anybody ever claimed that vectors can be considered list. It's rather the other way round: lists can also be seen as vectors to R (possibly they are implemented as such, but I don't much about the internals of R). a - as.list(1:10) b - 1:10 is.vector(a) [1] TRUE is.list(a) [1] TRUE is.vector(b) [1] TRUE is.list(b) [1] FALSE Hence the confusion about mode(as.vector(a)) [1] list which prompted the original comment that you are taking so much exception to. as to it could only work in very specific circumstances -- no, it would work for any list whatsoever, provided the user has a correctly implemented comparator. for example, i'd like to sort a list of vectors by the vectors' length -- is this a very exotic idea? Honestly, I can't think of a situation where I would want to do than in R. In a Perl script, quite likely; but this is a kind of data manipulation that R wasn't really designed for IMHO. Not that I'd mind having sort() operate properly on lists; it just isn't something I miss in the language. Best, Stefan [ stefan.ev...@uos.de | http://purl.org/stefan.evert ] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
On Mon, 23 Feb 2009 11:31:16 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: Berwin A Turlach wrote: On Mon, 23 Feb 2009 08:52:05 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: [...] and you mean that sort.list not being applicable to lists is a) good design, and b) something that by noe means should be fixed, right? I neither said nor meant this and I do not see how what I said could be interpreted in such a way. I was just commenting to Stavros that the example he picked, hoping that it would not break existing code, was actually a bad one which potentially will break a lot (?) of existing code. would it, really? if sort.list were, in addition to sorting atomic vectors (can-be-considered-lists), able to sort lists, how likely would this be to break old code? Presumably not. 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 idea how much would break. Additionally, you could try to install all CRAN packages with your modified version and see how many of them break when their examples/demos/c is run. AFAIK, Brian is doing something like this on his machine. I am sure that if you ask nicely he will share his scripts with you. If this sounds too time consuming, you might just want to unpack the sources and grep for sort.list on all .R files; I am sure you know how to use find and grep to do this. Also, until reading Patrick Burns' The R Inferno I was not aware of sort.list. That function had not registered with me since I hardly used it. which hints that potentially will break a lot (?) of existing code is a rather unlikely event. Only for code that I wrote; other people's need and knowledge of R may vary. And I also have no need of calling sort() on lists. For em a lists is a flexible enough data structure such that defining a sort() command for them makes no sense; it could only work in very specific circumstances. i don't understand the first part: flexible enough data structure such that defining a sort() command for them makes no sense makes no sense. lists are very flexible structure whose component must not be of equal type. So how do you want to compare components? How to you compare a vector of numbers to a vector of character strings? Or a list of lists? Or should the sorting be on the length of the components? Or their names? Or should sort(myList) sort each component of myList? But for that case we have already lapply(myList, sort). as to it could only work in very specific circumstances -- no, it would work for any list whatsoever, provided the user has a correctly implemented comparator. for example, i'd like to sort a list of vectors by the vectors' length -- is this a very exotic idea? No, if that is what you want. And I guess it is one way of sorting a list. The question is what should be the default way? BTW, as I mentioned once before, you might want to consider to lose these chips on your shoulders. berwin, it's been a tradition on this list to discourage people from commenting on the design and implementation of r whenever they think it's wrong. I am not aware of any such tradition and I subscribed to R-help on 15 April 1998. The point is rather that by commenting only one will not achieve much, in particular if the comments look more like complaints and the same comments are done again and again (along with dragging up previous comments or comments received on previous comments). R is open source. Check out the svn version, fix what you consider needs fixing, submit a patch, convince R core that the patch fixes a real problem/is an improvement/does not break too much. Then you have a better chance in achieving something. Alternatively, if it turns out that something that bugs you cannot be changed without breaking too much existing code, start from scratch that with a better design. Apparently the GAP project (http://www.gap-system.org/) is doing something like this, as someone closely associated with that project once told me. While developing a version of GAP they collect information on how to improve the design, data structures c; then, at some point, they start to write the next version from scratch. scary! it's much preferred to confuse new users. I usually learn a lot when I get confused about some issues/concept. Confusion forces one to sit down, think deeply and, thus, gain some understanding. So I am not so much concerned with new users being confused. It is, of course, a problem if the new user never comes out of his or her confusion. the problem, is, r users have to learn lots [...] Indeed, and I guess in this age of instant gratification that that is a real bummer for new
Re: [Rd] [R] Semantics of sequences in R
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 idea how much would break. 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. not that it is impossible or even difficult, i just haven't found time yet to learn how to implement internal functions in r. Additionally, you could try to install all CRAN packages with your modified version and see how many of them break when their examples/demos/c is run. that's not a good benchmark; this are third-party stuff, and where people are willing to rely on poor design they should be prepared to suffer. but maybe not in r, where protection of old code seems more important than progress. AFAIK, Brian is doing something like this on his machine. I am sure that if you ask nicely he will share his scripts with you. :) If this sounds too time consuming, you might just want to unpack the sources and grep for sort.list on all .R files; I am sure you know how to use find and grep to do this. of course i've done it in the first place; there are 52 such entries in r-devel, and i can't see any where allowing sort.list to sort lists would break the code. it does not mean, of course, that it wouldn't. Also, until reading Patrick Burns' The R Inferno I was not aware of sort.list. That function had not registered with me since I hardly used it. which hints that potentially will break a lot (?) of existing code is a rather unlikely event. Only for code that I wrote; other people's need and knowledge of R may vary. hence 'hints', not 'proves'. And I also have no need of calling sort() on lists. For em a lists is a flexible enough data structure such that defining a sort() command for them makes no sense; it could only work in very specific circumstances. i don't understand the first part: flexible enough data structure such that defining a sort() command for them makes no sense makes no sense. lists are very flexible structure whose component must not be of equal type. So how do you want to compare components? How to you compare a vector of numbers to a vector of character strings? Or a list of lists? *very* easy: by applying a suitable comparator. in your specific example, the possibilities are virtually limitless. you can convert the numbers to strings, or parse the strings into numbers. you can compute the lengths of the lists, compare their elements pairwise, or whatever you wish. all this done by a comparator which is a function fullfilling just one requirement: that it returns, say, -1, 0, or 1, depending on how the two items it gets compare. (and it has to work for the type of items you happen to have in your lists -- all this *your* business, not sort's.) judging from your question, you couldn't possibly see sorting routines in other languages. Or should the sorting be on the length of the components? why not? Or their names? why not? Or should sort(myList) sort each component of myList? that's a design decision. you can always have a parameter like recursive=TRUE/FALSE, no? so you could sort or not both between and within lists. what's the problem, again? But for that case we have already lapply(myList, sort). so? as to it could only work in very specific circumstances -- no, it would work for any list whatsoever, provided the user has a correctly implemented comparator. for example, i'd like to sort a list of vectors by the vectors' length -- is this a very exotic idea? No, if that is what you want. And I guess it is one way of sorting a list. The question is what should be the default way? one possible answer is: none. (i have already given this answer previously, if you read carefully it's still there). sort.list *should* demand an additional comparator argument. at least, it should demand it if the argument to be sorted is a list, rather than a non-list vector (if you still need to use sort.list on non-lists). BTW, as I mentioned once before, you might want to consider to lose these chips on your shoulders. berwin, it's been a tradition on this list to discourage people from commenting on the design and implementation of r whenever they think it's wrong. I am not aware of any such tradition and I subscribed to R-help on 15 April 1998. The point is rather that by commenting only one will not achieve much, in particular if the comments look more like complaints and the same comments are done again and again (along with dragging up previous comments or comments
Re: [Rd] [R] Semantics of sequences in R
On Mon, 23 Feb 2009 13:27:08 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: 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 idea how much would break. 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 start to move things to compiled code as needed for efficiency Additionally, you could try to install all CRAN packages with your modified version and see how many of them break when their examples/demos/c is run. that's not a good benchmark; this are third-party stuff, and where people are willing to rely on poor design they should be prepared to suffer. [...] I do not believe that those developers are relying on poor design. Rather, they rely on things to work as documented (and how they are used for them to work) and that the behaviour is not gratuitously changed just because it is considered bad design by some. [...] judging from your question, you couldn't possibly see sorting routines in other languages. Quite likely, or the other languages that I regularly use (C, Fortran) have even more primitive sorting facilities. [...] No, if that is what you want. And I guess it is one way of sorting a list. The question is what should be the default way? one possible answer is: none. (i have already given this answer previously, if you read carefully it's still there). sort.list *should* demand an additional comparator argument. at least, it should demand it if the argument to be sorted is a list, rather than a non-list vector (if you still need to use sort.list on non-lists). So when are you sending your patch to implement this facility? [...] The point is rather that by commenting only one will not achieve much, in particular if the comments look more like complaints and the same comments are done again and again (along with dragging up previous comments or comments received on previous comments). again and again because you seem to be immune to critique. You obviously do not know me. open you mind, and it will suffice complain just once. besides, i am certainly *not* just complaining. i am providing concrete arguments, examples, and suggestions. you're being unreasonably unfair. I gladly admit that I am not reading every thread in which you are active, so these comments might have been based on a biased a sample. [...] R is open source. Check out the svn version, fix what you consider needs fixing, submit a patch, convince R core that the patch fixes a real problem/is an improvement/does not break too much. Then you have a better chance in achieving something. no, berwin. this is a serious bug in thinking. people should be allowed -- *encouraged* -- to discuss the design *before* they even attempt to write patches. And what makes you believe this is not the case? I have seen over the years e-mails to R-devel along the lines I am thinking of a change along [lots of details and reasoning for the change]; would patches that implement this be accepted? and these e-mails were discussed more often than not. However, in the end, the only people who can commit changes to the R code are the members of R-core, thus they will have the final word of design issues (and, as I assume, they discuss, among other things, design issues on the private mailing list of R-core member). But you can discuss this issues before writing a patch. writing one patch which will never be considered -- well, never responded to -- is about enough to stop people from sending patches. While it is unfortunate if this happens, and such persons might just be too thin-skinned, worse can happen; e.g. being flamed for sending in a patch that is considered not to address any problems and with a sloppy description of what it tries to address (happened to me). Yes, patches are ignored; patches are gratefully acknowledged and applied; patches are completely re-written and still attributed to the provider of the patch... That does not mean that I stop sending in a patch if I feel it is warranted... And I am sure that if you had sent an e-mail to r-devel pointing out that the binary operator , when called in the non-standard way ''(1,2,3), does not check the number of arguments while other binary operators (e.g. '+'(1,2,3) or '*'(1,2,3)) do such checks, and provided a patch that implemented such a check for '' (and presumably other comparison operators), then that patch would have been acknowledged and applied. maybe that's what you want,
[Rd] copy an external pointer on assignment
Is there a mechanism in R for copying the business end of an external pointer on assignment? For instance, if x is an external pointer and I enter y - x I would like to make a copy of the structure that x refers to and assign its address to y. Thanks, Kjell __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
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 start to move things to compiled code as needed for efficiency sure. this would be a rewrite rather than a modification, though. but surely a possibility. thanks for pointing this out. Additionally, you could try to install all CRAN packages with your modified version and see how many of them break when their examples/demos/c is run. that's not a good benchmark; this are third-party stuff, and where people are willing to rely on poor design they should be prepared to suffer. [...] I do not believe that those developers are relying on poor design. Rather, they rely on things to work as documented (and how they are used for them to work) and that the behaviour is not gratuitously changed just because it is considered bad design by some. you're right. they're willing to rely on the existing design, often unconscious of its flaws. [...] judging from your question, you couldn't possibly see sorting routines in other languages. Quite likely, or the other languages that I regularly use (C, Fortran) have even more primitive sorting facilities. i apologize, this was an unacceptably imprecise expression, which i realized too late. i meant that you must have never used sorting routines in a language from the class that r purports to belong to -- high level functional programming languages. i was sort of clear than you must have used c and fortran, and i had no intention to say that you haven't used *any* other language. for your interest, here are two relevant examples. scheme is older than r, and yet already its developers got the idea that lists of arbitrary objects could be subject to sorting (by whatever magic). you only need to provide a comparator, e.g.: mit-scheme (sort (list 1 '(2 3) (lambda () '())) (lambda (x y) ( (random 2) 0))) # (#[compound-procedure] (2 3) 1) (which is a convoluted approach to using sort to actually scramble the list.) see, e.g., sec. 7.9 miscellaneous list operations in the mit scheme reference manual [1]. python folks -- be it guido van rossum or whoever else -- have gone even further, letting you sort lists of arbitrary items with a default comparator: python 'print sorted([1, (2, 3), lambda x: x])' # [1, function lambda at 0x81a1f44, [2, 3]] the point being: when you're trying to sell the idea that sorting lists of arbitrary items is a silly idea, it's silly. [1] http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/ [...] No, if that is what you want. And I guess it is one way of sorting a list. The question is what should be the default way? one possible answer is: none. (i have already given this answer previously, if you read carefully it's still there). sort.list *should* demand an additional comparator argument. at least, it should demand it if the argument to be sorted is a list, rather than a non-list vector (if you still need to use sort.list on non-lists). So when are you sending your patch to implement this facility? as i said, you seem to have a severe bug in thinking about collaborative development. 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. telling me i have a chip on my shoulder is rather unhelpful. [...] The point is rather that by commenting only one will not achieve much, in particular if the comments look more like complaints and the same comments are done again and again (along with dragging up previous comments or comments received on previous comments). again and again because you seem to be immune to critique. You obviously do not know me. obviously, i can judge only from what you write. snip R is open source. Check out the svn version, fix what you consider needs fixing, submit a patch, convince R core that the patch fixes a real problem/is an improvement/does not break too much. Then you have a better chance in achieving something. no, berwin. this is a serious bug in thinking. people should be allowed -- *encouraged* -- to discuss the design *before* they even attempt to write patches. And what makes you believe this is not the case? I have seen over the years e-mails to R-devel along the lines I am thinking of a change along [lots of details and reasoning for the change]; would patches that implement this be accepted? and these e-mails were discussed more often than not. However, in the end, the only
[Rd] a question about (
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 example is inessential, and is inspired by the __call__
method available in python.
what happens is, as of my understanding, that r sees an application
expression with the operator 'foo', and so tries to find a so-named
function, and there is none, hence the error. however, there *is* an
object named 'foo' there, and so it would, in principle, be possible to
make r try in turn dispatching '(' on the object's type. this would
lead to the function (.foo, and a successful application.
isGeneric('(')
# error: methods may not be defined for primitive function ( in
this version of R
makes me wonder whether making ( a generic function that would work
along the lines sketched above was actually considered for future
versions of r. (or has it actually been removed?)
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
