Hello, I too have two comments here - please see between the lines bellow. I believe they go to the same direction though :-)
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Chambers > Sent: Saturday, August 26, 2006 10:26 AM > To: Bill Dunlap > Cc: R-devel@r-project.org; Duncan Murdoch; Martin Maechler > Subject: Re: [Rd] "+" for character method... > > Well, two comments, in two non-compatible directions. > > 1. I have to say that I find the idea of using "+" to paste > character strings together aesthetically ugly. > > IMO, one thing that makes functional object-based languages > attractive is that the generic function retains a consistent > _function_, that is, purpose and meaning, of which the > methods are implementations. > > It escapes me totally why I should think of pasting strings > as addition in the mathematical or intuitive sense (as Brian > points out re commutativity, it fails a number of axiomatic > properties). And if so, what about "-", "*", "/" and so on? > The mind boggles. I came up with algebraic thoughts immediately after that point of your e-mail however I kept reading and saw Gabor's and Duncan's comments - this for priorities issues only :-) 1. "-", "*","/" definitions (assuming one knows what "+" means :-) "-" - is commonly defined by the (unique) solution of a+x=b ("handedness" could be taken into account) "*" - it does not necessarily have to be homogeneous (the same type) operation - vector spaces "/" - see "-" above 2. Now I totally agree with commutativity issue and would like make another suggestion inspired (if not a logical consequence of) by 1. above It is common to consider non-commutative operation as "*" multiplication so that is my suggestion if you want to keep R "math" spirit. If you want to pursue VB or the kin I then don't care. Then I'd like to have string "^" (string exponentiation operation that is) - obviously (string,integer) w/o any confusion AFAIR. "Root" I'll leave for higher level string algebra :-))) Regards, Latchezar Dimitrov PS. Character string semi-group is well know in Mathematics PPS. I'm an analyst/programmer by occupation and a mathematician and (independently from math) a computer scientist by education. PPS. Thanks for bearing with my thoughts above. BTW I am still waiting for some knowledgeable and good will person to help me with compiling 64-bit R on Sun Solaris 10 OS on amd64 machine. I dug in to the point of integer/pointer/fp sizes/accuracy in lazyload() (or whatever exact spelling is). I can provide complete details if wanted to. > > Its excuse presumably is to save typing, but I would favor > using some %thing% operator at the cost of a couple of extra > key strokes. > > 2. Having said that, it's a reasonable hope that efficiency > of dispatch will not be a serious problem. There are a bunch > of fixes, for semantic correctness and efficiency, nearly > ready to commit (the Bioconductor folks have been doing some > valuable testing). These should help, and more important > perhaps it's fairly easy to see how dispatch in this form can > be tuned for performance if necessary. > > John > > Bill Dunlap wrote: > >>> >> There have been propositions to make "+" work in S (and > >>> >> R) like in some other languages, namely for character > >>> >> (vectors), > >>> >> > >>> >> a + b := paste(a,b, sep="") > >>> ... > >>> yes. I think however if we keep speed and clarity and catching > >>> user errors all in mind, it would be enough - and better - to > >>> only dispatch to paste(.,.) when both arguments are character > >>> (vectors), i.e., the above case needed > >>> "a" + as.character(1:7) or "a" + paste(1:7) or "a" + format(1:7) > >>> which after all is really more clearer, even more for cases of > >>> "1" + 2 which I'd rather want keeping to give errors. > >>> > >>> If Char + Num should work like above, then also > >>> Num + Char should (since after all, "+" should be > commutative > >>> apart from floating point precision issues). > >>> > >>> and so the internal C code gets a bit more complicated > and slightly > >>> slower.. something we had in mind we should strongly avoid... > >>> > >> I doubt that it would be measurably slower, but I agree > that requiring > >> both args to be Char could be done in fewer operations than just > >> requiring one. > >> > >> However, I think the consistency argument is stronger. We > have a rule > >> that operations on mixed types promote the more > restrictive type to the > >> less restrictive one, and I don't think we should handle this case > >> differently. > >> > >> So I'd say we should allow all of Char + Num, Num + Char, > and Char + > >> Char, or, if this costs too much at evaluation time, we > shouldn't allow > >> any of them. > >> > > > > Currently doing arithmetic on mixed class data.frames > > produces useful warnings and errors. E.g., > > > > > z <- data.frame(Factor=factor(c("Lo","Med","High")), > > Char=letters[1:3], > > Num1=exp(0:2), > > Num2=(1:3)*pi, > > stringsAsFactors=FALSE) > > > z+1 > > Error in FUN(left, right) : non-numeric argument to > binary operator > > In addition: Warning message: > > + not meaningful for factors in: Ops.factor(left, right) > > > z[,-2] + 1 > > Factor Num1 Num2 > > 1 NA 2.000000 4.141593 > > 2 NA 3.718282 7.283185 > > 3 NA 8.389056 10.424778 > > Warning message: > > + not meaningful for factors in: Ops.factor(left, right) > > > > If we made + do paste(sep="") for character+number then > > we would lose the messages and let garbage flow further > > down the pipe. > > > > Should factor data be treated as character data in this > > case (e.g., pasting to the levels)? That would be weird, > > but many users confound character and factor data when > > they are buried in data.frames. > > > > > -------------------------------------------------------------- > -------------- > > Bill Dunlap > > Insightful Corporation > > bill at insightful dot com > > 360-428-8146 > > > > "All statements in this message represent the opinions of > the author and do > > not necessarily reflect Insightful Corporation policy or position." > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
