On Fri, 24 Aug 2018 at 19:53, Edzer Pebesma
wrote:
>
> In plotmath expressions, R's degree symbol, e.g. shown by
>
> plot(1, main = parse(text = "1*degree*C"))
>
> has sunk to halfway the text line, instead of touching its top. In older
> R versions this looked much better.
I can confirm this pro
Dear Farid,
Try using the ASCII notation. letters_fa <- c("\u0627", "\u0641"). The full
code table is available at https://www.utf8-chartable.de
Best regards,
ir. Thierry Onkelinx
Statisticus / Statistician
Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RES
I have to disagree, I think one of the advantages of '||' (or &&) is the lazy
evaluation, i.e. you can use the first condition to "not care" about the second
(and stop errors from being thrown).
So if I want to check if x is a length-one numeric with value a value between 0
and 1, I can do 'clas
I have to agree with Emil here. && and || are short circuited like in C and
C++. That means that
TRUE || c(TRUE, FALSE)
FALSE && c(TRUE, FALSE)
cannot give an error because the second part is never evaluated. Throwing a
warning or error for
c(TRUE, FALSE) || TRUE
would mean that the operator gi
Hi,
I absolutely second Henrik's suggestion.
On 08/30/2018 01:09 PM, Emil Bode wrote:
I have to disagree, I think one of the advantages of '||' (or &&) is the lazy evaluation,
i.e. you can use the first condition to "not care" about the second (and stop errors
from being thrown).
I do not t
On 08/30/2018 01:56 PM, Joris Meys wrote:
I have to agree with Emil here. && and || are short circuited like in C and
C++. That means that
TRUE || c(TRUE, FALSE)
FALSE && c(TRUE, FALSE)
cannot give an error because the second part is never evaluated. Throwing a
warning or error for
c(TRUE,
On Thu, Aug 30, 2018 at 2:09 PM Dénes Tóth wrote:
> Note that `||` and `&&` have never been symmetric:
>
> TRUE || stop() # returns TRUE
> stop() || TRUE # returns an error
>
>
Fair point. So the suggestion would be to check whether x is of length 1
and whether y is of length 1 only when needed.
Okay, I thought you always wanted to check the length, but if we can only check
what's evaluated I mostly agree.
I still think there's not much wrong with how length-0 logicals are treated, as
the return of NA in cases where the value matters is enough warning I think,
and I can imagine some co
I think this is an excellent idea as it eliminates a situation which
is almost certainly user error. Making it an error would break a small
amount of existing code (even if for the better), so perhaps it should
start as a warning, but be optionally upgraded to an error. It would
be nice to have a f
On Thu, Aug 30, 2018 at 3:11 AM Thierry Onkelinx
wrote:
>
> Dear Farid,
>
> Try using the ASCII notation. letters_fa <- c("\u0627", "\u0641").
... as recommend in the manual:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Encoding-issues
Best,
Ista
The full
> code table is availab
Should the following two functions should always give the same result,
except for possible differences in the 'call' component of the warning
or error message?:
f0 <- function(x, y) x || y
f1 <- function(x, y) if (x) { TRUE } else { if (y) {TRUE } else { FALSE }
}
And the same for the 'and' v
> Joris Meys
> on Thu, 30 Aug 2018 14:48:01 +0200 writes:
> On Thu, Aug 30, 2018 at 2:09 PM Dénes Tóth
> wrote:
>> Note that `||` and `&&` have never been symmetric:
>>
>> TRUE || stop() # returns TRUE stop() || TRUE # returns an
>> error
>>
>>
Hello,
Inline.
Às 16:44 de 30/08/2018, William Dunlap via R-devel escreveu:
Should the following two functions should always give the same result,
except for possible differences in the 'call' component of the warning
or error message?:
f0 <- function(x, y) x || y
f1 <- function(x, y) if
On Thu, Aug 30, 2018 at 5:58 PM Martin Maechler
wrote:
>
> I agree "in theory".
> Thank you, Henrik, for bringing it up!
>
> In practice I think we should start having a warning signalled.
>
I agree. I wouldn't know who would count on the automatic selection of the
first value, but better safe t
On Thu, Aug 30, 2018 at 10:58 AM Martin Maechler
wrote:
>
> > Joris Meys
> > on Thu, 30 Aug 2018 14:48:01 +0200 writes:
>
> > On Thu, Aug 30, 2018 at 2:09 PM Dénes Tóth
> > wrote:
> >> Note that `||` and `&&` have never been symmetric:
> >>
> >> TRUE || stop() # re
On Thu, Aug 30, 2018 at 2:11 AM Thierry Onkelinx
wrote:
>
> Dear Farid,
>
> Try using the ASCII notation. letters_fa <- c("\u0627", "\u0641"). The full
> code table is available at https://www.utf8-chartable.de
It's a little easier to do this with code:
letters_fa <- c('الف','ب','پ','ت','ث','ج',
Hi, I'd like to test whether a (localhost) PSOCK cluster node is still
running or not by its PID, e.g. it may have crashed / core dumped.
I'm ok with getting false-positive results due to *another* process
with the same PID has since started.
I can the PID of each cluster nodes by querying them fo
On Fri, Aug 31, 2018 at 1:18 AM Henrik Bengtsson
wrote:
[...]
> pid_exists <- function(pid) as.logical(tools::pskill(pid, signal = 0L))
>
> returns TRUE for existing processes and FALSE otherwise, but I'm not
> sure if I can trust this. It's not a documented feature in
> ?tools::pskill, which a
18 matches
Mail list logo
