search for: relop

On 09/07/2016 05:00 AM, r-devel-request at r-project.org wrote: > I've been slightly surprised (or even "frustrated") by the empty > reaction on our R-devel list to this post. > > I would have expected some critique, may be even some praise, > ... in any case some sign people are "thinking along" (as we say > in German). Have patience Martin. I read the

.... > (Though I'm > generally opposed to such warnings anyway, unless they could somehow > be restricted to come up only for interactive uses, not from deep in a > program the user didn't write, making them totally mysterious...) >> *and* the logic and relop versions of this, e.g., >> matrix(TRUE,1) | c(TRUE,FALSE) ; matrix(1,1) > 1:2, >> have always been an error; so nothing would break there. > Yes, that wouldn't change the behaviour of old code, but if we're > aiming for consistency, it might make sens...

...That's not true (at least for the cases above): They would give a strong warning, "strong" because it is > matrix(1,1) + 1:2 [1] 2 3 Warning message: In matrix(1, 1) + 1:2 : dropping dim() of array of length one. Will become ERROR > *and* the logic and relop versions of this, e.g., matrix(TRUE,1) | c(TRUE,FALSE) ; matrix(1,1) > 1:2, have always been an error; so nothing would break there. > There are reasons to expect such problems. Some operations such as > vector dot products using %*% produce results that are always scalar,...

> > But isn't the intent to make it an error later? So I assume we're > > debating making it an error, not just a warning. > > Yes, that's correct. > But if we have a longish deprecation period (i.e. where there's > only a warning) all important code should have been adapted > before it turns to an error That might be true for

Regarding Martin Maechler's proposal: Arithmetic between length-1 arrays and longer non-arrays had silently dropped the array attributes and recycled. This now gives a warning and will signal an error in the future, as it has always for logic and comparison operations For example, matrix(1,1,1) + (1:2) would give a warning/error. I think this might be a mistake. The potential

...yr::gather(key = key, value = value, new_sp_m014:newrel_f65, na.rm = FALSE)) u == s # TRUE all.equal(u, s) # "target, current do not match when deparsed" identical(u, s) # FALSE | Thanks, Dan [1] https://github.com/wch/r-source/blob/e647f78cb85282263f88ea30c6337b77a30743d9/src/main/relop.c#L140-L155 ? [[alternative HTML version deleted]]

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Tue, 6 Sep 2016 22:26:31 +0200 writes: > Yesterday, changes to R's development version were committed, relating > to arithmetic, logic ('&' and '|') and > comparison/relational ('<', '==') binary operators > which in NEWS are

...equivalent of those, e.g., by initializing a (to be grown, yes, very inefficient!) vector with NULL instead of with say double(0). For these reasons, many operations that expect a "number-like" (includes logical) atomic vector have treated NULL as such... *and* parts of the {arith/logic/relop} OPs have done so already in R "forever". I still would argue that for these OPs, treating NULL as logical(0) {which then may be promoted by the usual rules} is good thing. > Is your suggestion to leave the length-0 OP length-1 case as it is but make > length-0 OP length-...

...ating making it an error, not just a warning. (Though I'm generally opposed to such warnings anyway, unless they could somehow be restricted to come up only for interactive uses, not from deep in a program the user didn't write, making them totally mysterious...) > *and* the logic and relop versions of this, e.g., > matrix(TRUE,1) | c(TRUE,FALSE) ; matrix(1,1) > 1:2, > have always been an error; so nothing would break there. Yes, that wouldn't change the behaviour of old code, but if we're aiming for consistencey, it might make sense to get rid of that error, al...

>>>>> robin hankin <hankin.robin at gmail.com> >>>>> on Thu, 8 Sep 2016 10:05:21 +1200 writes: > Martin I'd like to make a comment; I think that R's > behaviour on 'edge' cases like this is an important thing > and it's great that you are working on it. > I make heavy use of zero-extent arrays, chiefly

Shouldn't binary operators (arithmetic and logical) should throw an error when one operand is NULL (or other type that doesn't make sense)? This is a different case than a zero-length operand of a legitimate type. E.g., any(x < 0) should return FALSE if x is number-like and length(x)==0 but give an error if x is NULL. I.e., I think the type check should be done before the length

On 09/08/2016 01:22 PM, Gabriel Becker wrote: > On Thu, Sep 8, 2016 at 10:05 AM, William Dunlap <wdunlap at tibco.com> wrote: > >> Shouldn't binary operators (arithmetic and logical) should throw an error >> when one operand is NULL (or other type that doesn't make sense)? This is >> a different case than a zero-length operand of a legitimate type. E.g.,

...dstruct.o duplicate.o envir.o errors.o eval.o format.o fourier.o gram.o gram-ex.o graphics.o iosupport.o list.o logic.o main.o match.o memory.o model.o names.o objects.o optimize.o options.o par.o paste.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o random.o relop.o saveload.o scan.o seq.o sort.o source.o split.o subassign.o subscript.o subset.o summary.o unique.o util.o version.o ../unix/libunix.a ../appl/libappl.a ../nmath/libmath.a -lSM -lICE -L/usr/X11R6/lib -lX11 -lreadline -lz -ldl -lncurses -lm the binary would exit with the error /usr/local/lib...

...dstruct.o duplicate.o envir.o errors.o eval.o format.o fourier.o gram.o gram-ex.o graphics.o iosupport.o list.o logic.o main.o match.o memory.o model.o names.o objects.o optimize.o options.o par.o paste.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o random.o relop.o saveload.o scan.o seq.o sort.o source.o split.o subassign.o subscript.o subset.o summary.o unique.o util.o version.o ../unix/libunix.a ../appl/libappl.a ../nmath/libmath.a -lSM -lICE -L/usr/X11R6/lib -lX11 -lreadline -lz -ldl -lncurses -lm the binary would exit with the error /usr/local/lib...

Prior to the mid-1990s, S did "length-0 OP length-n -> rep(NA, n)" and it was changed to "length-0 OP length-n -> length-0" to avoid lots of problems like any(x<0) being NA when length(x)==0. Yes, people could code defensively by putting lots of if(length(x)==0)... in their code, but that is tedious and error-prone and creates really ugly code. Is your suggestion to

R 0.65.0 (and all others I have seen), Solaris 2.6. > sort(c("a", "A", "b", "B")) [1] "A" "a" "B" "b" > "a" < "B" [1] FALSE in the en_UK locale. I don't think it is good idea that sort and < have a different idea of ordering, so I rate this as a bug. As far as I can see sort uses

...TNAME(x) : STRING_ELT(deparse1(x, 0, > DEFAULTDEPARSE), 0)); | > Is this a fix that needs to happen within the |==| documentation? or an > actual bug with the operator? This a good question. Thank you, Daniel, for providing the link to the source code in <R>/src/main/relop.c . Looking at that and its context, I think we (R core) should reconsider that implementation of '==' which indeed does about the same thing as deparse {which also truncates at some point by default; something very very reasonable for error messages, but undesirable in other cases}. But...

...envir.o errors.o eval.o >> format.o fourier.o iosupport.o gram.o list.o logic.o main.o match.o memory.o >> model.o names.o objects.o optimize.o options.o par.o paste.o plot.o plot3d.o >> plotmath.o print.o printarray.o printvector.o printutils.o random.o relop.o >> saveload.o scan.o seq.o sort.o source.o split.o subassign.o subscript.o >> subset.o summary.o unique.o util.o version.o ../lib/libgraphics.a >> ../lib/libunix.a ../lib/libappl.a ../lib/libmath.a -lSM -lICE -L/usr/openwin/lib >> -R/usr/openwin/lib -lX11 -...

...e.o deriv.o devices.o dotcode.o dstruct.o duplicate.o envir.o errors.o eval.o format.o fourier.o iosupport.o gram.o list.o logic.o main.o match.o memory.o model.o names.o objects.o optimize.o options.o par.o paste.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o random.o relop.o saveload.o scan.o seq.o sort.o source.o split.o subassign.o subscript.o subset.o summary.o unique.o util.o version.o ../lib/libgraphics.a ../lib/libunix.a ../lib/libappl.a ../lib/libmath.a -lSM -lICE -L/s/X11R6.3-1/lib -lX11 -ldnet_stub -ltermcap -lm ld: ../lib/libunix.a(system.o): main: multi...

...debug.o deparse.o dotcode.o dstruct.o duplicate.o edit.o envir.o errors.o eval.o format.o gram.o list.o logic.o main.o match.o memory.o model.o names.o objects.o optimize.o options.o par.o paste.o plot.o plot3d.o print.o printarray.o printvector.o printutils.o random.o relop.o saveload.o scan.o seq.o sort.o source.o split.o subassign.o subscript.o subset.o summary.o unique.o util.o version.o ../lib/libgraphics.a ../lib/libunix.a ../lib/libappl.a ../lib/libmath.a -L/usr/openwin/lib -R/usr/openwin/lib -lX11 -lnsl -lsocket -ldl -ltermcap -lm *** Error cod...