> Radford Nea:
> > So it may make more sense to move towards consistency in the
> > permissive direction, rather than the restrictive direction.
>
> > That would mean allowing matrix(1,1,1) < (1:2), and maybe also things
> > like matrix(1,2,2)+(1:8).
>
> Martin Maechler:
> That is an interesting idea. Yes, in my view that would
> definitely also have to allow the latter, by the above argument
> of not treating the dim/dimnames attributes special. For
> non-arrays length-1 is not treated much special apart from the
> fact that length-1 can always be recycled (without warning).
I think one could argue for allowing matrix(1,1,1)+(1:8) but not
matrix(1,2,2)+(1:8). Length-1 vectors certainly are special in some
circumstances, being R's only way of representing a scalar. For
instance, if (c(T,F)) gives a warning.
This really goes back to what I think may have been a basic mistake in
the design of S, in deciding that everything is a vector, then halfway
modifying this with dim attributes, but it's too late to totally undo
that (though allowing a 0-length dim attribute to explicitly mark a
length-1 vector as a scalar might help).
> > And I think there would be some significant problems. In addition to
> > the 10-20+ packages that Martin expects to break, there could be quite
> > a bit of user code that would no longer work - scripts for analysing
> > data sets that used to work, but now don't with the latest version.
>
> That's not true (at least for the cases above): They would give
> a strong warning
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. (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,
allowing code like sum(a%*%b<c(10,20,30)) with a and b being vectors,
rather than forcing the programmer to write sum(c(a%*%b)<c(10,20,30)).
> Of course; that *was* the reason the very special treatment for arithmetic
> length-1 arrays had been introduced. It is convenient.
>
> However, *some* of the conveniences in S (and hence R) functions
> have been dangerous {and much more used, hence close to
> impossible to abolish, e.g., sample(x) when x is numeric of length 1,
There's a difference between these two. Giving an error when using a
1x1 matrix as a scalar may detect some programming bugs, but not
giving an error doesn't introduce a bug. Whereas sample(2:n) behaving
differently when n is 2 than when n is greater than 2 is itself a bug,
that the programmer has to consciously avoid by being aware of the quirk.
Radford Neal
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
