>>>>> Martin Maechler
>>>>> on Tue, 23 Aug 2016 14:33:58 +0200 writes:
>>>>> Dirk Eddelbuettel
>>>>> on Fri, 19 Aug 2016 11:40:05 -0500 writes:
>> It is the old story of defined behaviour and expected outcomes. Hard
axis"), col.axis = par("col.axis"),
> And at the end of the body we se the call to plotts (including the "dots")
> So I would suggest using par-settings.
> par(cex=0.5)
> plot(y, type = 'b', pch = 16)
as a workaround, yes, thank you David
>>>>> John Mount
>>>>> on Wed, 24 Aug 2016 07:25:50 -0700 writes:
>> On Aug 24, 2016, at 2:36 AM, Martin Maechler
>> wrote:
>>
>>>>>>>
>>
>> [Talking to myself .. ;-)] Yes, but tha
> Gregory Werbin
> on Thu, 25 Aug 2016 15:21:05 -0400 writes:
> I've had a chance to read the source more thoroughly. The chain of
> events is as follows:
> 1. Local function `plotts()` is defined with argument `cex` that
> defaults to `par("cex")`
> 2. `...` is
>>>>> Martin Maechler
>>>>> on Fri, 26 Aug 2016 09:31:41 +0200 writes:
>>>>> Gregory Werbin
>>>>> on Thu, 25 Aug 2016 15:21:05 -0400 writes:
>> I've had a chance to read the source more thoroughly. The chain o
> Suharto Anggono Suharto Anggono via R-devel
> on Sat, 27 Aug 2016 03:17:32 + writes:
> In R devel r71157, 'droplevels' documentation, in "Arguments" section,
says this about argument 'exclude'.
> passed to factor(); factor levels which should be excluded from the
resul
>>>>> Martin Maechler
>>>>> on Sat, 27 Aug 2016 18:55:37 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono via R-devel
>>>>> on Sat, 27 Aug 2016 03:17:32 + writes:
>> In R devel r71157, 'droplevels
On R-help, with subject
'[R] source() does not include added code'
> Joshua Ulrich
> on Wed, 31 Aug 2016 10:35:01 -0500 writes:
> I have quantstrat installed and it works fine for me. If you're
> asking why the output of t(tradeStats('macross')) isn't being printed,
>
> Gabriel Becker
> on Thu, 1 Sep 2016 08:34:31 -0700 writes:
> I wonder how useful a (set of?) "time machine" functions
> which look up /infer things like this based on a date
> would be. Could ease the pain of changes generally, though
> not remove it completely.
Suc
ULL)
RNGkind ( kind = NULL, normal.kind = NULL)
functions.
(There, currently I'd guess we would not change the default).
---
Note that the above includes my guess that R-core would not take
action unless we get patch proposals.
(But then, I'm happy if my guess is wrong here ...)
Martin Maechler,
ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
, you should explicitly coerce it to a vector,
either ("self-explainingly") by as.vector(.), or as I did in
the nls case by c(.) : The latter is much less
self-explaining, but nicer to read in mathematical formulae, and
currently also more efficient because it is a .Primitive.
Please
>>>>> Martin Maechler
>>>>> 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/relation
>>>>> Martin Maechler
>>>>> on Wed, 7 Sep 2016 11:49:11 +0200 writes:
>>>>> Martin Maechler
>>>>> on Tue, 6 Sep 2016 22:26:31 +0200 writes:
>> Yesterday, changes to R's development version were committed, r
lot, Robin, (and Oliver) !
Yes, the above is such a case where the new behavior makes much sense.
And this behavior remains identical after the 71222 amendment.
Martin
> Best wishes
> Robin
> On Wed, Sep 7, 2016 at 9:49 PM, Martin Maechler
> wrote:
>>
intended? I have trouble thinking of a
case
>>>> where that less-than didn't carry an implicit assumption that y was
>>>> non-NULL. I can say that in my own code, I've never hit that behavior
>>>> in a
>>>> case that wasn't an error.
> Radford Neal
> on Thu, 8 Sep 2016 17:11:18 -0400 writes:
> 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
I have been asked (by Roger; thank you for the good question,
and I hope it's fine to answer to the public) :
> with Pi a sparse matrix and x,y, and ones
> compatible n-vectors — when I do:
>> c(t(x) %*% Pi %*% ones, t(ones) %*% Pi %*% y )
> [[1]] 1 x 1
> Suharto Anggono Suharto Anggono
> on Sat, 10 Sep 2016 02:36:54 + writes:
> Looking at the code of function 'table' in R devel r71227, I see that the
part "remove NA level if it was added only for excluded in factor(a,
exclude=.)" is not quite right.
> In
> is.na(a)
that do_c()
fails to dispatch here, and hence the problem was with our C
function that has carried the comment
| * To call this an ugly hack would be to insult all existing ugly hacks
| * at large in the world.
and I don't think I would be able to correctly patch that
infamous function (
>
>> > 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
>>>>> Martin Maechler
>>>>> on Sat, 10 Sep 2016 21:49:37 +0200 writes:
>>>>> John Chambers
>>>>> on Sat, 10 Sep 2016 09:16:38 -0700 writes:
>> (Brief reply, I'm traveling but as per below, this is on
> Suharto Anggono Suharto Anggono via R-devel
> on Fri, 9 Sep 2016 16:52:01 + writes:
> In "An Introduction to R" Version 3.3.1, in "4.2 The function tapply()
and ragged arrays", after
> stderr <- function(x) sqrt(var(x)/length(x)) ,
> there is a note in brackets:
),
ordered))
if (missing(labels))
levels(x) <- levels
else levels(x) <- labels
x
}
and already contained that line.
Nevertheless, simplifying factor() by removing that line (or those
2 lines, now!) seems to only have advantages
I'm
().
oh yes.. blush! ..
Martin
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
> On Tue, Sep 13, 2016 at 8:55 AM, Martin Maechler
> wrote:
>> >>>>> Suharto Anggono Suharto Anggono via R-devel
>> >>>>> on Fr
e (!) to x %*% x ~= 100.
indeed!
Still, it gives exactly 0 on my platform(s), where I'm using R's
own version of BLAS / Lapack.
Are you perhaps using an "optimized" BLAS / LAPACK , i.e, one
that is fast but slightly less so accurate
cbind(sprintf("%a", c(x%*%x, crossprod(x), sum(x^2
[,1]
[1,] "0x1.9e09ea598568fp+6"
[2,] "0x1.9e09ea598568fp+6"
[3,] "0x1.9e09ea598568ep+6"
>
> Regards,
> Alexis Sarda.
> On Tue, Sep 20, 2016 at 5:27 PM, Martin Maechle
> David Winsemius
> on Tue, 20 Sep 2016 23:46:48 -0700 writes:
>> On Sep 20, 2016, at 7:18 PM, Karl Millar via R-devel
wrote:
>>
>> 'c' has an undocumented 'use.names' argument. I'm not sure if this is
>> a documentation or implementation bug.
> It came up on
don't see any way around the "mis-feature" that all "input"
expressions are in the end shown twice in the "output" (the
first time by showing the withAutoprint(...) call itself).
The function *name* is "not bad" but also a bit longish;
maybe there ar
> Karl Millar via R-devel
> on Fri, 23 Sep 2016 11:12:49 -0700 writes:
> I'd expect that a lot of the performance overhead could be eliminated
> by simply improving the underlying code. IMHO, we should ignore it in
> deciding the API that we want here.
I agree partially.
; its a
base function, hence not hidden ..
As mentioned before, 'use.names' is used in unlist() in quite a
few places, and such an argument also exists for
lengths() and
all.equal.list()
and now c()
>
> On Sa
[...]
> }
I think my approach is nicer insofar it does not seem to need
such an argument I'm sure you'll try to disprove that ;-)
Martin
> Just some thoughts
> /Henrik
> On Sat, Sep 24, 2016 at 6:37 AM, Martin Maechler
> wrote:
&
ld print in R.
Currently it prints like what I say should just be the default
method.
Honestly, I'm not sure if it would be straightforward or even
just relatively painless to go to '1) + 2)' ... may change
r71349 (to the S4 generic definition of "c") had dramatical
effect
>>>>> Henrik Bengtsson
>>>>> on Sun, 25 Sep 2016 12:38:27 -0700 writes:
> On Sun, Sep 25, 2016 at 9:29 AM, Martin Maechler
> wrote:
>>>>>>> Henrik Bengtsson on
>>>>>>> Sat, 24 Sep 2016 11:31:49 -
>>>>> Martin Maechler
>>>>> on Mon, 26 Sep 2016 18:26:25 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono
>>>>> on Mon, 26 Sep 2016 14:51:11 + writes:
>> By "an argument named 'use.names' is
>>>>> Martin Maechler
>>>>> on Tue, 13 Sep 2016 18:33:35 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono via R-devel
>>>>> on Fri, 2 Sep 2016 16:10:00 + writes:
>> I am basically fine with the change.
their remark 1 is very relevant and promising faster /
more reliable convergence.
I'd be "happy" if optim() could gain a new option, say, "L-BFGS-B-2011"
which would incorporate what they call "modified L-BFGS-B".
However, I did not fi
> Michael Lawrence
> on Wed, 12 Oct 2016 15:21:13 -0700 writes:
> Thanks, this was what I expected. There is a desire to
> eliminate the usage of pairlist from user code, which
> suggests the alternative of allowing for function
> arguments to be stored in lists. That'
(and we would then use that),
but that has never happened according to my knowledge.
Thank you for the 'heads up'.
Martin Maechler
ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
> Ben Bolker
> on Mon, 24 Oct 2016 19:26:35 -0400 writes:
> The URL listed under
> https://svn.r-project.org/R/trunk/share/licenses/license.db for the ACM
> license,
> http://www.acm.org/publications/policies/softwarecrnotice ,
> gives a 404 error. I think this
> Spencer Graves
> on Tue, 25 Oct 2016 22:02:29 -0500 writes:
> On 10/25/2016 9:44 PM, Henrik Bengtsson wrote:
>> setTimeLimit(elapsed=1) causes a timeout error whenever a call takes
>> more than one second. For instance, this is how it works on Windows
>> (R 3.3.1):
> Duncan Murdoch
> on Mon, 24 Oct 2016 14:54:16 -0400 writes:
> On 24/10/2016 1:51 PM, Kevin Ushey wrote:
>> Hi R-devel,
>>
>> One of the more common issues that new R users see, and become stumped
>> by, is error messages during package load of the form:
>>
source code should basically all be in
src/library/tools/R/testing.R
Note that this may be complicated, also because "parallel"
checking is available in parts, via the TEST_MC_CORES
environment variable ((which is currently only quickly
documented in
tible with all the other options you see
from 'R CMD check --help'),
please speak up.
Martin
> Regards, Jan
> On 3 November 2016 at 17:25, Hervé Pagès
> wrote:
>>
>> Hi Martin, Jan,
>>
>> On 11/03/2016 03:45 AM, Martin Maechler
>>>>> Brian G Peterson
>>>>> on Fri, 4 Nov 2016 10:37:18 -0500 writes:
> On Fri, 2016-11-04 at 16:24 +0100, Martin Maechler wrote:
>> >>>>> Jan Gorecki >>>>> on Fri, 4
>> Nov 2016 11:20:37 + write
>>>>> Dirk Eddelbuettel
>>>>> on Fri, 4 Nov 2016 10:36:52 -0500 writes:
> On 4 November 2016 at 16:24, Martin Maechler wrote: | My
> proposed name '--no-stop-on-error' was a quick shot; if |
> somebody has a more concise or
>>>>> Oliver Keyes
>>>>> on Fri, 4 Nov 2016 12:42:54 -0400 writes:
> On Friday, 4 November 2016, Martin Maechler
> wrote:
>> >>>>> Dirk Eddelbuettel >
>> >>>>> on Fri, 4 Nov 2016 10:36:52
>>>>> Hervé Pagès
>>>>> on Mon, 7 Nov 2016 14:37:15 -0800 writes:
> On 11/05/2016 01:53 PM, Martin Maechler wrote:
>>>>>>> Oliver Keyes
>>>>>>> on Fri, 4 Nov 2016 12:42:54 -0400 writes:
> Gergely Daróczi
> on Thu, 10 Nov 2016 16:48:12 +0100 writes:
> Dear All,
> I'm developing an R application running inside of a Java daemon on
> multiple threads, and interacting with the parent daemon via stdin and
> stdout.
> Everything works perfectly fine exc
> Gábor Csárdi
> on Sun, 13 Nov 2016 20:49:57 + writes:
> Using dup() before fdopen() (and calling fclose() on the connection
> when it is closed) indeed fixes the memory leak.
>
Thank you, Gábor!
Yes I can confirm that this fixes the memory leak.
I'm testing ('make check-all')
> nospam@altfeld-im de
> on Sun, 13 Nov 2016 13:11:38 +0100 writes:
> Dear R friends, to allow post-mortem debugging In my
> Rscript based batch jobs I use
>tryCatch( , error = function(e) {
> dump.frames(to.file = TRUE) })
> to write the called frames into a
t; in your example.
Martin
> The semantic difference is that the global variable "g" is visible
> within the function "f" in the first version, but not in the second
> version.
>
> If I dump to a file and load and debug it then the search path through
> the
>
sting of 2 files
- ifelse-def.R : Functions definitions only, basically all the current
proposals, called ifelse*()
- ifelse-checks.R : A simplistic checking function
and examples calling it, notably demonstrating that my
ifelse2() does work with
"
bug fixes?
--> I'm BCC'ing this to one place at least.
Best,
Martin Maechler ETH Zurich
> On Thu, Nov 17, 2016 at 2:28 PM, Laviolette, Michael <
> michael.laviole...@dhhs.nh.gov> wrote:
>> The packages "readxl" and "haven" (and
good look at my ifelse2() proposal.
I really would like an alternative to ifelse() in *addition* to
the current ifelse(), but hopefully in the future being used in
quite a few places instead of ifelse()
efficiency but for changed semantics, namely working for considerably
more "vector like
the issue: I also don't see what your point is.
R works with these so libraries as intended in all cases as
far as we know, and so I don't understand why anything needs to
be changed.
All these libraries "belong to R" and are tied to a specific
version of R and are not b
> Related to the length of 'ifelse' result, I want to say that "example of
> different return modes" in ?ifelse led me to perceive a wrong thing in the
> past.
> ## example of different return modes:
> yes <- 1:3
> no <- pi^(0:3)
> typeof(ifelse(NA,yes, no)) # logical
>
(or truncated) 'yes'.
> It uses 'rep' on the index and subsetting as a substitute for 'rep' on
the value.
> It requires 'length' method that is compatible with subsetting.
> Additionally, it uses the same idea as dplyr::if_else, or more p
the following
>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45)
> [1] 1 0 0
> Please try whether the following becomes all right.
[..]
Yes, it does -- the fix will be in all future versions of R.
Thank you very much Ei-ji Nakama, for t
>>>>> Martin Maechler
>>>>> on Thu, 1 Dec 2016 09:36:10 +0100 writes:
>>>>> Ei-ji Nakama
>>>>> on Thu, 1 Dec 2016 14:39:55 +0900 writes:
>> Hi,
>> i try sin, cos, and tan.
>>> sapply(c(co
t Microsoft be the institution who can best
judge how to do that, now that they sell a "Microsoft R" ??
!??!?!??!?!??!?
(trying again with BCC; next time, I'll use CC).
(a slowly increasingly frustrated)
Martin Maechler
ETH Zurich
> Best,
> Evan
> On Wed
> Joshua Ulrich
> on Tue, 6 Dec 2016 09:51:16 -0600 writes:
> On Tue, Dec 6, 2016 at 6:37 AM, wrote:
>> Hi all,
>>
>> I ran into a segfault while playing with dates.
>>
>> $ R --no-init-file
>> ...
>> > library(lubridate); d=as.POSIXlt(floor_date(Sy
is possibly only for you!
Note that I do *not* see problems on Linux (in ESS; did not try RStudio).
Please also indicate in which form you are running R.
Here it does depend if this is inside RStudio, ESS, the "Windows
GUI", the "Windows terminal", ...
Martin Maechler,
ETH Zur
As R is sophisticated enough to track leap seconds,
?.leap.seconds
we'd need to update our codes real soon now again:
https://en.wikipedia.org/wiki/Leap_second
(and those of you who want second precision in R in 2017 need to start
working with 'R patched' or 'R devel' ...)
_
>>>>> Martin Maechler
>>>>> on Wed, 14 Dec 2016 17:04:22 +0100 writes:
> As R is sophisticated enough to track leap seconds,
> ?.leap.seconds
> we'd need to update our codes real soon now again:
> https://en.wikipedia.org/wik
> Jennifer Lyon
> on Thu, 15 Dec 2016 09:33:30 -0700 writes:
> On the documentation page for DateTimeClasses, in the Examples section,
> there are the following two lines:
>
> format(.leap.seconds) # the leap seconds in your time zone
> print(.leap.seconds, tz = "PST8PDT") #
to me... in so far as the
general feeling is that memory should be cheap and limits should
not be low.
(In spite of Brian Ripleys good reasons against it, I'd still
aim for a *dynamic*, i.e. automatically increased list here).
Martin Maechler
> Regards,
> Steve Bronder
> Florent Angly
> on Tue, 20 Dec 2016 13:26:36 +0100 writes:
> Hi all,
> I have noticed incorrect parsing of very small hexadecimal numbers
> like "0x1.dp-987". Such a hexadecimal representation can
> can be produced by sprintf() using the %a flag. The retu
st option would be
3/ The help page for I() could note what happens in the NULL case.
That would be the least work for everyone,
but at the moment, I tend to agree that '1/' is worth the pain to
have R's structure() become more consistent.
Martin Maechler
ETH Zurich
> My s
ic that
do.NULL = FALSE is relatively slow?
Shorter code *is* nicer than longer code, so I need a bit more
conviction why we should add more code for that special case ..
Martin Maechler, ETH Zurich
> On 20 December 2016 at 01:27, Jan Gorecki wrote:
> > Hello,
> >
> > col
>>>>> Martin Maechler
>>>>> on Thu, 22 Dec 2016 10:24:43 +0100 writes:
>>>>> Florent Angly
>>>>> on Tue, 20 Dec 2016 13:42:37 +0100 writes:
>> Hi all,
>> I believe there is an issue with passing NULL to the
You are right (though picky). I have updated it now.
Thank you Henrik!
Martin
> Should utils::ls.str() be updated as:
> svn diff src/library/utils/R/str.R
> Index: src/library/utils/R/str.R
> ===
> --- src/library/utils/R/str.R (re
o) : default method not implemented for type 'symbol'
which I find a very appropriate and helpful message
> seq.int(to=quote(b), by=2)
> Error in seq.int(to = quote(b), by = 2) :
> 'to' cannot be NA, NaN or infinite
which is true, as well, and there
>>>>> Mick Jordan
>>>>> on Wed, 4 Jan 2017 08:15:03 -0800 writes:
> On 1/4/17 1:26 AM, Martin Maechler wrote:
>>>>>>> Mick Jordan
>>>>>>> on Tue, 3 Jan 2017 07:57:15 -0800 writes:
>> > This i
> Mick Jordan
> on Wed, 4 Jan 2017 12:49:41 -0800 writes:
> On 1/4/17 8:15 AM, Mick Jordan wrote:
> Here is another difference that I am guessing is unintended.
>> y <- seq.int(1L, 3L, length.out=2)
>> typeof(y)
> [1] "double"
>> x <- seq.default(1L, 3L, lengt
>>>>> Martin Maechler
>>>>> on Thu, 5 Jan 2017 12:39:29 +0100 writes:
>>>>> Mick Jordan
>>>>> on Wed, 4 Jan 2017 08:15:03 -0800 writes:
>> On 1/4/17 1:26 AM, Martin Maechler wrote:
>>>>>>>&g
cite above, the current
implementation was triggered by a nasty BLAS bug .. actually
also showing up only on some platforms, possibly depending on
runtime libraries in addition to the compilers used.
Do you have R code (including set.seed(.) if relevant) to show
on how to generate the large square matri
>>>>> Milan Bouchet-Valat
>>>>> on Thu, 19 Jan 2017 13:58:31 +0100 writes:
> Hi all,
> I know this issue has been discussed a few times in the past already,
> but Martin Maechler suggested in a bug report [1] that I raise it here.
>
> Basicall
t here... but of course we can continue
discussing here if you like.
Martin Maechler
ETH Zurich and R Core
> and the R head() and tail() functions are modeled after
> their GNU counterparts, I would expect the R functions to
> distinguish between +0 and -0
>> tai
Last week, we've talked here about "xtabs(), factors and NAs",
-> https://stat.ethz.ch/pipermail/r-devel/2017-January/073621.html
In the mean time, I've spent several hours on the issue
and also committed changes to R-devel "in two iterations".
In the case there is a *Left* hand side part to xt
mode(ans[[1]]))
else NA
.
A colleague proposed to use the shorter argument name 'default'
instead of 'init.value' which indeed maybe more natural and
still not too often used as "non-first" argument in FUN(.).
Thank you for the constructive feedbac
advantages are not even getting close to counter-weigh the drawbacks.
> On 26 January 2017 at 16:51, William Dunlap wrote:
>> In addition, signed zeroes only exist for floating point numbers - the
>> bit patterns for as.integer(0) and as.integer(-0) are identical.
inde
> Suharto Anggono Suharto Anggono via R-devel
> on Fri, 27 Jan 2017 16:36:59 + writes:
> The "no factor combination" case is distinguishable by 'tapply' with
simplify=FALSE.
>> D2 <- data.frame(n = gl(3,4), L = gl(6,2, labels=LETTERS[1:6]), N=3)
>> D2 <- D2[-c(1,5), ]
>>>>> Henrik Bengtsson
>>>>> on Fri, 27 Jan 2017 09:46:15 -0800 writes:
> On Fri, Jan 27, 2017 at 12:34 AM, Martin Maechler
> wrote:
>>
>> > On Jan 26, 2017 07:50, "William Dunlap via R-devel"
>> >
> Suharto Anggono Suharto Anggono via R-devel
> on Tue, 31 Jan 2017 15:43:53 + writes:
> Function 'aggregate.data.frame' in R has taken a different route. With
drop=FALSE, the function is also applied to subset corresponding to combination
of grouping variables that doesn't
> Avraham Adler
> on Tue, 31 Jan 2017 16:07:20 -0500 writes:
> On Tue, Jan 31, 2017 at 3:30 PM, peter dalgaard wrote:
>>
>>> On 31 Jan 2017, at 18:56 , Avraham Adler
wrote:
>>>
>>> Hello.
>>>
>>> When trying to unpack today's version of R-patched,
> Mikko Korpela
> on Wed, 1 Feb 2017 12:16:49 +0200 writes:
> I found some trivial typos, mostly unmatched parentheses, in the R
> manuals. More information and suggested fixes are in the attached diff
file.
Thank you very much!
They have been applied to the R-devel and R-pa
e mode (0 for raw) is automatically used."
After some thought (and experiments), I have reverted and no
longer use if(missing). You are right that it is not needed
(and even potentially confusing) here.
Changes are in svn c72106.
Martin Maechler
> --
> Suharto Anggono Suharto Anggono via R-devel
> on Sat, 4 Feb 2017 10:18:33 + writes:
> Function 'stopifnot' in R devel r72104 has this.
> head <- function(x, n = 6L) ## basically utils:::head.default()
> x[if(n < 0L) max(length(x) + n, 0L) else min(n, length
> Henric Winell
> on Tue, 7 Feb 2017 13:37:42 +0100 writes:
> Hi, On 2017-02-07 13:12, Benjamin Tyner wrote:
>> Hello
>>
>> When loading a package, I'm wondering if it's frowned
>> upon for the package to alter the state of the random
>> number generator? I g
s with NaN/Inf.
-----
Last but not least :
If you are not afraid of +/- Inf, but really only of NA/NaN's (as the OP said),
then note that "THE manual" (= "Writing R Extensions") does mention
ISNAN(.) almost in the same place as the first occurence of
R_FINITE(.).
Best regards,
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
> Therneau, Terry M , Ph D
> on Thu, 9 Feb 2017 12:56:17 -0600 writes:
> Martyn,
> No, that didn't work.
> One other thing in the mix (which I don't think is the issue) is that I
call one of the
> C-entry points of expm. So the DESCRIPTION file imports expm, the
NA
the help page of devices doesn't explain that there are any limits or how
> they are determined. The wording of the error message could also be improved,
> to explain that the resolution is too high or the dimensions are too large.
If one/some of those who can reproduce the problem in
> Hin-Tak Leung
> on Sat, 11 Feb 2017 19:30:26 + writes:
> I haven' t touched R for some 18 months, and so I have no
> idea if this is a recent problems or not; but it certainly
> did not segfault two years ago. Since it has been
> crashing (segfault) under 'make
>
> The issue is that without an extensible derivative table or the proposed
> extensions, it is not possible to automatically produce (without manual
> modification of the deriv3 output) a function that avoids catastrophic
> cancellation regardless of the working range.
> Manual modification i
> Ben Bolker
> on Thu, 16 Feb 2017 15:37:13 -0500 writes:
> A querent on StackOverflow asked about the with() function
>
http://stackoverflow.com/questions/42283479/why-when-to-use-with-function#42283479
> and asked about the example in ?with
> library(MASS)
> w
> Mikko Korpela
> on Thu, 23 Feb 2017 14:02:58 +0200 writes:
> With new R releases soon to come, I suggest updating the
> Rcopyright macro in "doc/manual/R-defs.texi" to use year
> 2017.
Now this is an e-mail that *REALLY* does not fit to the R-devel
mailing list ... even
> On Thu, Feb 23, 2017 at 03:23:10PM +0100, Martin Maechler wrote:
> > >>>>> Mikko Korpela
> > >>>>> on Thu, 23 Feb 2017 14:02:58 +0200 writes:
> >
> > > With new R releases soon to come, I suggest updating the
> &
out
bug report, and your proposal to make the simple case rep(s, list(7))
work as previously seems ok to me.
However, for all this, we will concentrate on R-devel (to become
R 3.4.0).
Best regards,
Martin Maechler
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
king any code".
In spite of all that *and*
the perennial drawback that a '...' will allow argument name
typos to go unnoticed
I agree you have a good argument nowadays, that median() should
be the same as many similar "basic statistics" R
> Peter Simons
> on Mon, 27 Feb 2017 10:30:39 +0100 writes:
> Hi, I tried compiling the latest pre-release for R 3.3.3
> for the NixOS Linux distribution [1], but the build fails
> during the "make check" phase because of the following 2
> issues:
> 1) The "tools"
601 - 700 of 1759 matches
Mail list logo
