Re: [Rd] Operator precedence of =, <- and ?
Thanks, for reference, this has been already reported as PR#16710. Now
fixed, the precedence of "?" is again lower than the precedence of "=",
as documented in ?Syntax.
Please note the role of the precedence table in the parser definition:
the precedence given there is not necessarily the precedence of
operators you would see in the language. The precedence table in the
parser definition tells the parser how to behave in situations when it
does not know otherwise (please refer to bison documentation if you were
curious about the details), but it "knows otherwise" in R, the grammar
was written so that "=" had the lowest precedence, before the fix. Also,
in principle, the precedence can be different in different contexts.
It is the precedence table in the programming language
definition/specification/documentation (here ?Syntax) that should give
the precedence a user would observe in the language. Following the
table, programmers know when it is safe to omit parentheses. However,
this may be error prone for operators that have different
meaning/precedence in different languages, and hence such tables are
often intentionally incomplete. This is another reason why not to look
into the parser implementation to learn about operator precedence. R's
precedence table in ?Syntax is fairly complete and in many cases using
parentheses where the table gives precedence would improve readability
of the code.
Best
Tomas
On 1/10/20 11:59 AM, Konrad Rudolph wrote:
The documentation (help("Syntax")) gives the operator precedence of the
assignment operators and help, from highest to lowest, as:
‘<- <<-’ assignment (right to left)
‘=’assignment (right to left)
‘?’help (unary and binary)
If I understand correctly this implies that `a = b ? c` and `a <- b ? c`
should parse identically. Or, if using the unary version, `?a = b` and `?a
<- b` should parse identically.
However, as noted by Antoine Fabri on Stack Overflow [1], they have
different parses (on R 3.5.3 and 3.6.1, at least), which puts the
precedence of `?` *between* that of `<-` and `=`. In fact, src/main/gram.y
[2] appears to show the same precedence table as the documentation;
presumably the parser at some point rewrites the parse tree manually.
At any rate, should this be fixed in the documentation? Or is the
documentation “correct”, and there’s a bug in the parser (in some versions
of R)?
[1] <
https://stackoverflow.com/questions/1741820/51564252#comment105506343_51564252
[2] <
https://github.com/wch/r-source/blob/386c3a93cbcaf95017fa6ae52453530fb95149f4/src/main/gram.y#L384-L390
--
Konrad Rudolph
[[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
Re: [Rd] ?Syntax wrong about `?`'s precedence ?
For reference, this has been fixed so that the precedence of "?" is
lower than "=", as documented.
Tomas
On 8/30/19 7:45 PM, peter dalgaard wrote:
> ...and 14955, which seems to have the explanation (but was marked as
> closed/fixed??). The parser does list '?' as lower precedence than '=', but
> '='-assignments are not normal 'expr's which can appear as arguments to '?'.
> (Presumably because of named arguments: f(a=b) differs from f(a<-b).)
>
> Other tokens which have lower precedence than assignments are flow-control
> items, IF ELSE WHILE FOR REPEAT, but I don't see any way to confuse them in
> the same way as '?'.
>
> It might be possible to resolve the situation by specifying '?' syntax
> explicitly as
> expr_or_assign '?' expr_or_assign, but, well, "There be Tygers here"...
>
> -pd
>
>
>> On 30 Aug 2019, at 18:32 , Kevin Ushey wrote:
>>
>> See also: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16710
>>
>> On Fri, Aug 30, 2019 at 9:02 AM William Dunlap via R-devel
>> wrote:
>>> Precedence is a property of the parser and has nothing to do with the
>>> semantics assigned to various symbols. Using just core R functions you can
>>> see the precedence of '?' is between those of '=' and '<-'.
>>>
# '=' has lower precedence than '?'
str(as.list(parse(text="a ? b = c")[[1]]))
>>> List of 3
>>> $ : symbol =
>>> $ : language `?`(a, b)
>>> $ : symbol c
str(as.list(parse(text="a = b ? c")[[1]]))
>>> List of 3
>>> $ : symbol =
>>> $ : symbol a
>>> $ : language `?`(b, c)
# '<-' has higher precedence than '?'
str(as.list(parse(text="a ? b <- c")[[1]]))
>>> List of 3
>>> $ : symbol ?
>>> $ : symbol a
>>> $ : language b <- c
str(as.list(parse(text="a <- b ? c")[[1]]))
>>> List of 3
>>> $ : symbol ?
>>> $ : language a <- b
>>> $ : symbol c
>>>
>>> Bill Dunlap
>>> TIBCO Software
>>> wdunlap tibco.com
>>>
>>>
>>> On Fri, Aug 30, 2019 at 4:41 AM Stephen Ellison
>>> wrote:
>>>
> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Ant F
> Sent: 29 August 2019 12:06
> To: r-devel@r-project.org
> Subject: [Rd] ?Syntax wrong about `?`'s precedence ?
> ...
> See the following example :
>
> `?` <- `+`
I'm curious; What did you expect to happen if you replace the function '?'
with the operator '+' ?
? is surely now being evaluated as a user-defined function and not as an
operator.
Would you expect the results of doing that to be the same as evaluation
without replacement?
S Ellison
***
This email and any attachments are confidential. Any u...{{dropped:10}}
>>> __
>>> 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
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] matplot.Date & matplot.POSIXct
Maybe I'm missing something really obvious here, but I was unable to create a matrix out of POSIXct object(s). Perhaps that deserves a separate discussion...? Regarding your other comments/questions: (1) You should *NOT* mask functions from the graphics package (or base, stats, etc), except possibly for personal use. (2) The xlab and ylab are fine. B. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] matplot.Date & matplot.POSIXct
Thanks for the reply.
On 2020-01-27 19:56, Abby Spurdle wrote:
Maybe I'm missing something really obvious here, but I was unable to
create a matrix out of POSIXct object(s).
Perhaps that deserves a separate discussion...?
Can you provide an example?
The standard matplot application that concerns me is with
matplot(x, y, ...) where x has class Date or POSIXct and y is a matrix.
The "fda" package on CRAN includes a "matplot" help page with examples
that worked when I tested them recently.
If you have an example that you think should work but doesn't I'd
like to know. Maybe it should be added to the examples in
fda::matplot.Rd file, then the code should be modified until it works.
Regarding your other comments/questions:
(1) You should *NOT* mask functions from the graphics package (or
base, stats, etc), except possibly for personal use.
(2) The xlab and ylab are fine.
In most situations, I agree with your comment that, "You should
*NOT* mask functions from the graphics package (or base, stats, etc)".
However, when the behavior of the function in graphics, base, or
stats seems patently inappropriate and not adequately considered, then I
think that someone should mask the function in the core distribution
with one whose behavior seems more consistent with what most users would
most likely want.
Ten or twelve years ago, I concluded that the behavior of
graphics::matplot(x, y, ...) was inappropriate when x is either of class
Date or POSIXct. Specifically, it labeled the horizontal axis the same
as graphics::matplot(as.numeric(x), y, ...). I think it should instead
be labeled the same as graphics::plot(x, y[,1], ...) in such cases. To
fix this problem, I made fda::matplot generic; graphics::matplot is not
generic. And a coded methods for x of class numeric, matrix, Date and
POSIXct plus a default. Each calls either graphics::matplot or matlines
as appropriate after first setting up the horizontal axis properly if x
is of class Date or POSIXct.
For specific examples, consider the following taken from
fda::matplot.Rd:
invasion1 <- as.Date('1775-09-04')
invasion2 <- as.Date('1812-07-12')
earlyUS.Canada <- c(invasion1, invasion2)
Y <- matrix(1:4, 2, 2)
graphics::matplot(earlyUS.Canada, Y)
# horizontal axis labeled per as.numeric(earlyUS.Canada),
# NOT as Dates
fda::matplot(earlyUS.Canada, Y)
# problem fixed.
# POSIXct
AmRev.ct <- as.POSIXct1970(c('1776-07-04', '1789-04-30'))
graphics::matplot(AmRev.ct, Y)
# horizontal axis labeled per as.numeric(AmRev.ct),
# NOT as POSIXct
fda::matplot(AmRev.ct, Y)
# problem fixed.
Comments?
Thanks again for the reply.
Spencer Graves
B.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] class() |--> c("matrix", "arrary") -- and S3 dispatch
> Pages, Herve
> on Tue, 21 Jan 2020 17:33:01 + writes:
> Dear Martin,
> What's the ETA for _R_CLASS_MATRIX_ARRAY_=TRUE to become the new
> unconditional behavior in R devel? Thanks!
> H.
Thank you, Hervé, for asking / reminding.
It has been made so now, 3 days ago (svn r77714).
Martin
> On 11/21/19 08:57, Martin Maechler wrote:
>>
>> TLDR: This is quite technical, still somewhat important:
>> 1) R 4.0.0 will become a bit more coherent: a matrix is an array
>> 2) Your package (or one you use) may be affected.
>>
>>
>>> Martin Maechler
>>> on Fri, 15 Nov 2019 17:31:15 +0100 writes:
>>
>>> Pages, Herve
>>> on Thu, 14 Nov 2019 19:13:47 + writes:
>>
>> >> On 11/14/19 05:47, Hadley Wickham wrote:
>> >>> On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler ... wrote:
>>
>> []
>>
>> > Note again that both "matrix" and "array" are special [see ?class]
as
>> > being of __implicit class__ and I am considering that this
>> > implicit class behavior for these two should be slightly
>> > changed
>> >
>> > And indeed I think you are right on spot and this would mean
>> > that indeed the implicit class
>> > "matrix" should rather become c("matrix", "array").
>>
>> I've made up my mind (and not been contradicted by my fellow R
>> corers) to try go there for R 4.0.0 next April.
>>
>> >>> I can't seem to find the previous thread, so would you mind being a
>> >>> bit more explicit here? Do you mean adding "array" to the implicit
>> >>> class?
>>
>> >> It's late in Europe ;-)
>>
>> >> That's my understanding. I think the plan is to have class(matrix())
>> >> return c("matrix", "array"). No class attributes added to matrix or
>> >> array objects.
>>
>> >> It's all what is needed to have inherits(matrix(), "array") return
TRUE
>> >> (instead of FALSE at the moment) and S3 dispatch pick up the foo.array
>> >> method when foo(matrix()) is called and there is no foo.matrix method.
>>
>> > Thank you, Hervé! That's exactly the plan.
>>
>> BUT it's wrong what I (and Peter and Hervé and ) had assumed:
>>
>> If I just change the class
>> (as I already did a few days ago, but you must activate the change
>> via environment variable, see below),
>>
>> S3 dispatch does *NOT* at all pick it up:
>> "matrix" (and "array") are even more special here (see below),
>> and from Hadley's questions, in hindsight I now see that he's been aware
>> of that and I hereby apologize to Hadley for not having thought
>> and looked more, when he asked ..
>>
>> Half an hour ago, I've done another source code commit (svn r77446),
>> to "R-devel" only, of course, and the R-devel NEWS now starts as
>>
>>
>>
>> CHANGES IN R-devel:
>>
>> USER-VISIBLE CHANGES:
>>
>> • intention that the next non-patch release should be 4.0.0.
>>
>> • R now builds by default against a PCRE2 library
>> ...
>> ...
>>
>> • For now only active when environment variable
>> _R_CLASS_MATRIX_ARRAY_ is set to non-empty, but planned to be the
>> new unconditional behavior when R 4.0.0 is released:
>>
>> Newly, matrix objects also inherit from class "array", namely,
>> e.g., class(diag(1)) is c("matrix", "array") which invalidates
>> code (wrongly) assuming that length(class(obj)) == 1, a wrong
>> assumption that is less frequently fulfilled now. (Currently
>> only after setting _R_CLASS_MATRIX_ARRAY_ to non-empty.)
>>
>> S3 methods for "array", i.e., .array(), are now also
>> dispatched for matrix objects.
>>
>>
>> (where only the very last 1.5 lines paragraph is new.)
>>
>> Note the following
>> (if you use a version of R-devel, with svn rev >= 77446; which
>> you may get as a binary for Windows in about one day; everyone
>> else needs to compile for the sources .. or wait a bit, maybe
>> also not much longer than one day, for a docker image) :
>>
>>
>>> Sys.unsetenv("_R_CLASS_MATRIX_ARRAY_") # ==> current R behavior
>>> class(m <- diag(1))
>> [1] "matrix"
>>> Sys.setenv("_R_CLASS_MATRIX_ARRAY_" = "BOOH !") # ==> future R behavior
>>> class(m)
>> [1] "matrix" "array"
>>>
>>> foo <- function(x) UseMethod("foo")
>>> foo.array <- function(x) "made in foo.array()"
>>> foo(m)
>> [1] "made in foo.array()"
>>> Sys.unsetenv("_R_CLASS_MATRIX_ARRAY_")# ==> current R behavior
>>> foo(m)
>> Error in UseMethod("foo") :
>> no applicable
