.html#Files-and-directories
> I've attached a patch against revision 72974 to change this to dir.create.
Thank you, John! -- fixed in the sources now.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
n1" in R-devel but interestingly is "UTF-8" in R 3.4.1,
indeed independently of the locale.
I would argue R-devel (and current R-patched) is more faithful
by keeping the Encoding "latin1" that was set for names(x) also
in the names(c(x)) .
I could revert R-patched'
is is a general problem, or only a problem on my machine.
It is not a problem on 64-bit I think. This is related to the
bug and bugfix for PR#17274
( https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17274 )
which I had handled.
Now I see the above, I can well imagine that I had made
as
inating those that
appear on both sides of the '~'.
This has been documented on the help page [ ?model.matrix ] for
(almost exactly 14) years, the "Details:" section ending with
_> By convention, if the response variable also appears on the
_> right-hand side of the formula i
ath.data.frame group methods (about which I have not always
been so happy, but they are inheritance from S),
and as the Math methods work too, we should get this boundary
case working as well for the Ops.
Martin Maechler
ETH Zurich and R Core
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
So as often there is more to it than you first think.
Let's consider this an RFC (for experienced long time R users) :
>>>>> Martin Maechler
>>>>> on Wed, 9 Aug 2017 10:45:56 +0200 writes:
>>>>> William Dunlap via R-devel
>>>>
at anything will change, unless someone
provides a (small footprint) patch towards the (R-devel aka
"trunk") sources *and* reproducible R code that depicts the
problem.
Still: Thank you for trying to make R better by contributing with
careful bug reports !
Best,
Martin
>
d in the mean time,
namely in svn r51095 | 2010-02-03
Usually we are cautious / reluctant to change such things w/o
any bug that we see to fix.
OTOH, we did have bug cases we'd wanted to amend for seq() /
seq.int();
and I'll look into updating the "pretty - epsilon" also to
1e-10.
Thank you for your analysis and suggestions!
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Martin Maechler
>>>>> on Wed, 9 Aug 2017 12:39:26 +0200 writes:
> So as often there is more to it than you first think.
> Let's consider this an RFC (for experienced long time R users) :
>>>>> Martin Maechler
>>&g
>>>>> Martin Maechler
>>>>> on Mon, 14 Aug 2017 11:46:07 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono via R-devel
>>>>> on Fri, 11 Aug 2017 17:11:06 + writes:
>>>>> Suharto Anggono Suharto Anggono vi
led)
I just did that and both versions of R behaved identically,
i.e., returned the same 'll'
(I've tried with different versions of Copy regions from excel;
my version of Windows (2008 Server R2, fully uptodate with
updates) is very different than yours; Office is said to be
O
hat led to
change of 'seq' fuzz, is
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15137
>
> On Tue, 15/8/17, Martin Maechler wrote:
> Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c
> To: "Martin Maechler"
> @r-p
, Suharto.
I subsequently have amended NEWS and added such regression tests
(in svn r73108 | 2017-08-19).
Martin
> ----
> On Sat, 19/8/17, Martin Maechler
> wrote:
> Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c
&
ave used,
including 3.3.3.
>
> Any suggestions? Is this a known bug with 3.4.1?
Thank you, Peter!
I can confirm what you are seeing (on Linux) in R version 3.4.0,
3.4.1, and "R devel", and also that this had worked w/o a
problem in earlier versions of R, where I've looked at
R version 3.3.3 and 3.2.5.
I do think this is a bug, but it was not known till now.
For ease of use, I attach the two R files to easily reproduce.
Note I use writeLines() instead of print() as its output is "nicer".
Best regards,
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Martin Maechler
>>>>> on Wed, 23 Aug 2017 09:10:20 +0200 writes:
>>>>> Peter Bosa
>>>>> on Tue, 22 Aug 2017 14:39:50 + writes:
>> Hello, I've noticed the following error using repeat{} / break
==
> --- src/library/base/man/rank.Rd (revision 73116)
> +++ src/library/base/man/rank.Rd (working copy)
...
Thank you, Jon.
Seems my mistake, I'm going to correct it.
Martin Maechler
ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
the full distribution for that
case.
I would have expected to see all possible values in 0:100
instead of such a "normal like" distribution with carrier only
in [34, 67].
There are newer publications and maybe algorithms.
So maybe the algorithm is "flawed by design" for really large
>>>>> Peter Dalgaard
>>>>> on Fri, 25 Aug 2017 11:43:40 +0200 writes:
>> On 25 Aug 2017, at 10:30 , Martin Maechler
wrote:
>>
> [...]
>>
https://stackoverflow.com/questions/37309276/r-r2dtable-contingency-tables-are-
> Thomas Levine <_...@thomaslevine.com>
> on Fri, 28 Jul 2017 18:53:16 + writes:
> The attached patch corrects a dead link in the treering
> documentation. The URL in the manual [1] refers to a
> personal home page belonging to Christine Hallman (user
> "hallman")
ss this must be specific to your platform.
Did you try the same thing with R 3.4.1?
Did you install both in the same way -- from the sources ??
Best,
Martin
> Here is the script of a job. A pdf graph is fine. I use xubuntu as the
windowing system.
> tmt-local1334% R --vanilla
understand what you mean. From the little I
understand about English intricacies and with my not
fully developed gut feeling of good English (which I rarely
speak but sometimes appreciate when reading / listening),
I would indeed
prefer 'Native Language'
to 'Natural Language'
ens
at package load time, and then _not_ using `::` in the package
sources itself.
Many people seem to forget that every use of `::` is an R
function call and using it is ineffecient compared to just using
the already imported name.
Best,
Martin Maechler
ETH Zurich and R Core Team
> Best
> Simon Barthelme
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
d that "things may behave differently" after the use '::', because
loading a namespace does have an effect on the R session ...,
(and I still think `::` is much "over used")
Martin
>> On 1 sept. 2017, at 12:57, Simon Barthelmé
wrote:
>>
>>>>> Thomas Levine <_...@thomaslevine.com>
>>>>> on Fri, 1 Sep 2017 13:23:47 + writes:
> Martin Maechler writes:
>> There may be one small problem: IIUC, the wayback machine
>> is a +- private endeavor and really gr
<- file.create(to)
if(ok) ok <- file.append(to, from)
return(ok)
Since you get FALSE when I get TRUE, it is not quite sure if in
your case file.append() is called at all... but I'd guess so.
I think the bug is that file.append(to, from) does not give an
error in our case wh
R-devel on CRAN, a test
> run on version as old as r73150 does manifest this bug
>
(https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-gcc/httptest-00check.html),
> so the timing does suggest that those changes could be related.
I'm sure they are (and it is
> Fox, John
> on Wed, 13 Sep 2017 22:45:07 + writes:
> Dear Terry,
> Even the behaviour of lm() and glm() isn't entirely consistent. In both
cases, singularity results in NA coefficients by default, and these are
reported in the model summary and coefficient vector, but
>>>>> Martin Maechler
>>>>> on Thu, 14 Sep 2017 10:13:02 +0200 writes:
>>>>> Fox, John
>>>>> on Wed, 13 Sep 2017 22:45:07 + writes:
>> Dear Terry,
>> Even the behaviour of lm() and glm() isn't e
c/main/bind.c has been identical in R-devel and R-patched
(i.e. 3.4.2 beta) for quite some time, and the NEWS entries must
be moved to 3.4.2 beta.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Martin Maechler
>>>>> on Tue, 19 Sep 2017 09:18:46 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono via R-devel
>>>>> on Mon, 18 Sep 2017 16:11:53 + writes:
>> Previous mentions:
>> - htt
nk you, Lukas, for the report!
I'll fix it .. but of course too late for R version 3.4.2 which
has been released about one hour ago (!).
Martin Maechler
ETH Zurich
> Best,
> Lukas
> [[alternative HTML version deleted]]
&g
> Jan van der Laan
> on Fri, 6 Oct 2017 12:13:39 +0200 writes:
> It is actually model.matrix that crashes, not glm. Same
> crash occurs with e.g. lm.
> model.matrix(dob_mon ~ dob_day*dob_mon, data = tab)
> also crashes R.
Yes, segmentation fault.
It only happens wh
e of the timezone in R with a shell
> pipeline, e.g.: system("find /usr/share/zoneinfo/ -type f | xargs md5sum
> | grep $(md5sum /etc/localtime | cut -d ' ' -f 1) | head -n 1 | cut -d
> '/' -f 5,6"), but the last part of t
>>>>> Martin Maechler
>>>>> on Mon, 16 Oct 2017 19:13:31 +0200 writes:
>>>>> Stephen Berman
>>>>> on Sun, 15 Oct 2017 01:53:12 +0200 writes:
> > (I reported the test failure mentioned below to R-help but was advise
na(x)] returns a "nice"
(typically atomic) vector .. which is the case for such data frames.
The consequence, that in R-devel, currently
factor(mtcars)
just "works", is indeed unexpected or even "shocking", and I
still don't know what the most elega
>>>>> Stephen Berman
>>>>> on Thu, 19 Oct 2017 17:12:50 +0200 writes:
> On Wed, 18 Oct 2017 18:09:41 +0200 Martin Maechler
wrote:
>>>>>>> Martin Maechler
>>>>>>> on Mon, 16 Oct 2017 19:13:31 +0200 writ
ables in R. For that reason, using the language
keywords TRUE and FALSE is much preferred in such cases. For
some tests we'd even use
T <- FALSE
or even
delayedAssign("F", stop("do not use 'F' when programming with R"))
before running the tests -- just d
described in the list signup page:
> https://stat.ethz.ch/mailman/listinfo/r-devel )
> Regards,
> Brian
Yes, indeed!
Thank you Brian.
Morkus: Do *STOP* using the R-devel mailing list for now, and
use R-help instead. You are absolutely misusing R-devel currently!
Martin Maech
et
>>
>> But Intel MKL also seems to be free*:
>> https://software.intel.com/en-us/articles/free-mkl
> install.packages("rmsfact")
> sub(".*because ", "", rmsfact::rmsfact(8))
"Amen"!
...
>>>>> Fox, John
>>>>> on Thu, 14 Sep 2017 13:46:44 +0000 writes:
> Dear Martin, I made three points which likely got lost
> because of the way I presented them:
> (1) Singularity is an unusual situation and should be made
> more
ell you are close in your R code, but not if you load 50
packages and do how-knows-what before running the example,
you RNGkind() and many other things could have been changed ...)
Since you run ubuntu, you know the shell and you could
(after installing a current version of R) put your MRE in a
small *.R script and do
R CMD BATCH --vanilla MRE.R
which will produce MRE.Rout with all input/output
BTW: Even on Windoze you can do similarly, once you've found the
location of 'Rcmd.exe':
..\Rcmd BATCH --vanilla MRE.R
should work there as well and deliver MRE.Rout
- - - - -
After doing all this, your problem may still be just
because you are using much too large integers for the 'seed'
argument of set.seed()
I really really strongly believe you should have used R-help
instead of R-devel.
Best,
Martin Maechler
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
uggested by Suharto Anggono, and as "promised" on
R-devel list, Nov 26, 2016
----
> On Mon, 28/11/16, Martin Maechler wrote:
> Subject: Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?
>>>>> Martin Maechler
>>>>> on Thu, 2 Nov 2017 21:59:00 +0100 writes:
>>>>> Fox, John
>>>>> on Thu, 14 Sep 2017 13:46:44 + writes:
>> Dear Martin, I made three points which likely got lost
>> be
>>>>> Fox, John
>>>>> on Tue, 7 Nov 2017 22:09:03 +0000 writes:
> Dear Martin, I think that your plan makes sense. It's too
> bad that aov() behaved differently in this respect from
> lm(), and thus created more work, but it's no
all you show and say seems very convincing to me,
notably the fix as well.
I'll deal with this, after a little testing.
If the effect is small in "package - space", it may be ported to
R-patched to become R 3.4.3 in three weeks.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
'd:/Rcompile/CRANpkg/lib/3.4/rockchalk'
all of these these are names of Matrix-package objects..
and I know that yesterday Matrix package version changes (1.1-11
--> 1.1-12) happened on CRAN and hence in servers which update..
So it *could* be this is all just a temporary p
examples in
base/R/dates.R alone and am trying to find more in other places.
[maybe this used to be necessary for very early different
versions of NextMethod() which were not yet optimized using .Class etc]
Thank you very much,
Hadley!
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Cons"
are related to "there must 100's of 1000s of R code lines using
str(), and so there will be 100s of places where the output
changes, ( ... but then I'd guestimate that the change would be
to the better in most cases).
Martin
--
Martin Maechler, ETH Zurich
> _
o the main thread), also easy enough to incorporate at
the C level using the BH package as source for relevant boost header.
Martin
-Winston
On Tue, Nov 21, 2017 at 12:42 PM, wrote:
On Tue, 21 Nov 2017, Winston Chang wrote:
Is it safe to call Rprintf and REprintf from a background thread
u very much, Aaron.
This is indeed a bug, and it looks that I had caused it when
introducing the internal str_parse() utlity.
It's too bad this is so close before release of R 3.4.3 and the
fix to the bug is not trivial (not very hard either) such that
it most probably will not make it into 3.4.3.
Martin Maechler
ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Martin Maechler
>>>>> on Thu, 16 Nov 2017 22:00:16 +0100 writes:
> [This is a "re-post" -- for some reason it never appeared
> on R-devel]
>>>>> Etienne Sanchez
>>>>> on Tue, 14 Nov 2017 19:33:07 +01
> Iñaki Úcar
> on Thu, 30 Nov 2017 14:32:12 +0100 writes:
> 2017-11-30 14:13 GMT+01:00 Suzen, Mehmet :
>> On 30 November 2017 at 14:04, Iñaki Úcar wrote:
>>>
>>> Am I supposed to read every reference on a man page just to know what
>>> to expect from a function?
nstead of inherits(, "data.frame").
No, that is not true as is.data.frame() is not generic, and base
functions call base, so there can't be a difference.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
-level bug somewhere.
- Either in 'stringr' or 'stringi' in their C code using
things they should not (because not in R's API),
which now shows in R-devel where many "inner workings" have been
modified (key "ALTREP")
- or in R-devel .. in these new &
part[i] <- list(recurse(part[[i]]))
> }
> part
>}
>body(fn) <- recurse(body(fn))
>fn
> }
>
> # test
> ( testNoSrc2 <- rmSource(testSrc) )
> testNoSrc2()
>
>
> Regards,
> Denes
Thank you very much, Denes. This is indeed a b
ssociated with lines of code
svn annotate doc/manual/R-exts.texi | less
A quick google search (svn diff visual display) lead me to
svn diff --diff-cmd meld -c73909
for my platform, which pops up the diffs in a visual context.
Martin Morgan
And your description seems wrong:
there is now a
of us
> who are SVN users, but probably harder for Git users.
> Duncan Murdoch
As you know I had setup (the first few versions of) the svn at
https://svn.r-project.org/
at the time, I wanted to keep that machine protected as much as
possible and had decided not to install any other a
>>>>> Hervé Pagès
>>>>> on Tue, 26 May 2020 12:38:13 -0700 writes:
> Hi Martin, On 5/26/20 06:24, Martin Maechler wrote: ...
>>
>> What about remaining back-compatible, not only to R 3.y.z
>> with default recycle0=F
>>>>> Martin Maechler
>>>>> on Wed, 27 May 2020 13:35:44 +0200 writes:
>>>>> Hervé Pagès
>>>>> on Tue, 26 May 2020 12:38:13 -0700 writes:
>> Hi Martin, On 5/26/20 06:24, Martin Maechler wrote: ...
>
not happened (yet?):
Because of vectorization working differently in the current R
code of the r*(*, ncp=*) functions and the corresponding C
code, this would lead to different random numbers in this
case... and so such a change --- to make Rmathlib "complete" ---
is something t
undocumented R internals), it
should be reproducible with a very small dummy package instead
of data.table. ... or actually reproducible with relatively
simple R code calling unique() not envolving any non base package.
Martin
>> Exact environment where I am reproducing this issue is
ironment("package:utils"),
>> as.environment("package:methods") )
>> unique(env_list)
> Thanks ... but the above work fine for me. E.g.,
R> l = list(a=new.env(), b=new.env())
R> unique(l)
> [[1]]
> [[2]]
and it is required to use --enable-strict-barrier to
> reproduce the issue.
No, I (and Kurt probably, too) had overlooked the extra flags
setting you'd used
Thank you and Deepayan for checking more there.
I now agree this is something we (R Core) should address one way
or the othe
me .Internal with
r7885 | ripley | 2000-01-31 08:58:59 +0100
i.e. about 4 weeks *before* release of R 1.0.0
Changes made to both 'R-devel' and 'R-patched'.
Martin
> Cole Miller
> P.S. During research, my favorite `help()` is
> `?.Internal()`
(I don't see lapply / vapply referenced as primitive in the original text
changed by the commit).
Martin Morgan
On 7/10/20, 3:52 AM, "R-devel on behalf of Martin Maechler"
wrote:
>>>>> Cole Miller
>>>>> on Thu, 9 Jul 2020 20:38:10
improvement there,
deprecating 'giveCsparse = TRUE'
and replacing it by 'repr = "C"'
the latter allowing all three kind of sparseMatrix formats
("C", "R", "T") instead of just Csparse* and Tsparse*.
Best regards,
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
behavior of some
Matrix functions, notably Matrix::Matrix() which in that next version
of Matrix will produce "diagonalMatrix" instead of
"CsparseMatrix" objects in more cases a good thing, but not
what those packages have assumed...
@Spencer: Are you actively using &#x
2e-09
## $ iter : int 47
## $ init.it : int NA
## $ estim.prec: num 7.28e-12
--
so, in principle the C-internal search() function really should be
improved for such ( somewhat extreme!! ) cases.
or ... ?? ... a different approximat
>>>>> Constantin Ahlmann-Eltze
>>>>> on Fri, 21 Aug 2020 11:51:13 +0200 writes:
> Hi Martin, thanks for verifying. I agree that the
> Cornish-Fisher seems to struggle with the small size
> parameters, but I also don't have a good idea
ys use a consistent subset (not rely on the coercion
> e.g. from characters).
> Best
> Tomas
Indeed.
Further note that most arithmetic/math *fails* on
character vectors, so if a change would have to be made, it
should rather be such that cumsum() also rejects char
and get that error?
or is it a platform you've been running 'make check' on R-devel
for a while and only now you "suddenly" get that error?
Best,
Martin
> Best regards,
> Mikko Korpela
> Maanmittauslaitos | National Land Survey of Finland
> Opastinsilta 12 C, 00520 Helsinki, Finland
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Korpela Mikko (MML)
>>>>> on Mon, 31 Aug 2020 08:46:55 + writes:
> Thank you for the introduction to these recent changes, Martin.
> I think this was the second time I ran "make check" on that platform
(Raspberry Pi 32-bit),
ath library' has been a good name,
notably because there's a lot of applied math routines in there,
99% related to (applied) probability which is part of math.
If 'Rust' and other re-implementors think they must add
"stat(s)" somewhere --- which is understandable, since t
> Hugh Parsonage
> on Tue, 8 Sep 2020 18:08:11 +1000 writes:
> I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2):
> $> R --vanilla
> x <- c(0L, -2e9:2e9)
> # > Segmentation fault
> Tried to reproduce on Linux but the above worked as expected.
>>>>> Martin Maechler
>>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes:
>>>>> Hugh Parsonage
>>>>> on Tue, 8 Sep 2020 18:08:11 +1000 writes:
>> I can only reproduce on Windows, but reliably (both 4
>>>>> luke-tierney
>>>>> on Tue, 8 Sep 2020 09:42:43 -0500 (CDT) writes:
> On Tue, 8 Sep 2020, Martin Maechler wrote:
>>>>>>> Martin Maechler
>>>>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes:
>>
27;m happy if you create a formal bug report, possibly "wishlist"
as it is documented behavior, for this infelicity...
and then I will probably add the 'HELPWANTED' keyword.
Martin
> -Original Message-
> Message: 19 Date: Tue, 8 Sep 2020 22:04:44 -040
2, 1));
allocates a vector of length 2 at
SEXP out = PROTECT(Rf_allocVector(INTSXP, nc));
but writes three elements (the 0th, 1st, and 2nd) at
for (int i = 0; i != nr; ++i) {
out_int[i] = int_mat_int[n - 1 + i * nr];
}
Martin Morgan
On 9/11/20, 9:30 PM, &q
te
'not yet initialized' and distinct from character(0) or NA_character_, but want
to mention those often appropriate alternatives.
With
setClassUnion("maybeNumber", c("numeric", "logical"))
every instance of numeric _is_ a maybeNumber, e.g.,
>
haracter", "numeric"))
Error in setOldClass(c("character", "numeric")) :
inconsistent old-style class information for "character"; the class is
defined but does not extend "numeric" and is not valid as the data part
In addition: Warning message:
In
> Kasper Daniel Hansen
> on Thu, 1 Oct 2020 20:31:12 +0200 writes:
> The return value of Sys.time() today with a timezone of US/Eastern is
> unchanged between 4.0.3-patched and devel, but on devel the following test
> fails
> all.equal(x, as.POSIXlt(x))
> with
>>>>> mb706
>>>>> on Sun, 18 Oct 2020 22:14:55 +0200 writes:
>> From my side: it would be great if you (or R core) could prepare a
patch, it would probably take me quite a bit longer than you since I don't have
experience creating patches for R
e 2: Error in showDefault(object) :
cannot get a slot ("slots") from an object of type "NULL"
>
> Unfortunately there is a bunch of code around that calls I() on S4
> objects, admittedly not necessarily for very good reasons, but it
> happens. Would it be pos
(csym, psym);
+ UNPROTECT(1);
}
return class;
}
seems to remove the warning; I'm guessing that the other SEXP already exist so
don't need protecting?
Martin Morgan
On 10/29/20, 12:47 PM, "R-devel on behalf of luke-tier...@uiowa.edu"
wrote:
nrik (or anyone): Is there a small repr.ex. I could add to
parallel/tests/*.R which will show the advantage of allowing an
empty 'user' here?
Martin Maechler
> On 07/11/2020 1:39 p.m., Henrik Bengtsson wrote:
>> FWIW, there are indeed a few low hanging bug fixes in
&g
rked quite a bit at
that, too long ago to remember details, but the relevant svn log
entry is
r66640 | maechler | 2014-09-18 22:10:20 +0200 (Thu, 18 Sep 2014) | 1 line
more sophisticated all.equal.environment(): no
> Ben Bolker
> on Mon, 30 Nov 2020 16:33:23 -0500 writes:
> The 'offset' argument description is blank ...
> maybe 'additive adjustment to each of the (red, green, blue, alpha)
> values defining the colors, after adjustment by the corresponding
> \code{.f} factor' ..
1 ist nicht TRUE
>
For now I'd claim the bug is in the underlying C code of
gettext() , ngettext() ...
It would we good to report this in R's bugzilla, please,
see https://www.r-project.org/bugs.html
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Martin Maechler
>>>>> on Tue, 1 Dec 2020 10:31:36 +0100 writes:
>>>>> Bill Dunlap
>>>>> on Mon, 30 Nov 2020 13:41:54 -0800 writes:
>> To make the comparison more complete,
>> all.equal.environment
>>>>> Martin Maechler
>>>>> on Thu, 3 Dec 2020 18:29:58 +0100 writes:
>>>>> Martin Maechler
>>>>> on Tue, 1 Dec 2020 10:31:36 +0100 writes:
>>>>> Bill Dunlap
>>>>>
, IMO.
> I say that as someone who routinely does both type of
> thing.
> ~G
I agree with Gabe here.
Also, R allows the user to remove their own home directory, it
should also allow to get a .libPaths() which contains nothing compulsory
but R's own .Library {as only that can con
when used, check that it is at least '1'
But then some scripts / examples of some people *will* change
..., e.g., because they preferred to have a global setting of digits=5
so I'm guessing it may make more people unhappy than other
people happy if we change this now, after close to
probably almost only
from the fact .C() and .Fortran() now compulsorily *copy* their
arguments, whereas with .Call() you are enabled to shoot
yourself in both feet .. ;-)
Martin
> On 12/23/20 3:57 AM, Koenker, Roger W wrote:
>> Thanks to all and best wishes for a better 2021
onstant")
> > +if (var(abs(x)) == 0)
> > +stop("absolute residuals from the median are essentially constant")
>
> > a <- qnorm((1 + rank(abs(x)) / (n + 1)) / 2)
> > STATISTIC <- sum(tapply(a, g, "sum")^2 / tapply(a, g, &q
> Ben Bolker
> on Sun, 27 Dec 2020 15:02:47 -0500 writes:
> There is a recurring issue with installing from source into paths
> that contain single quotes/apostrophes. "Why would anyone do that??" is
> certainly a legitimate response to such a problem, but I would also s
e Arguments section.
> Duncan Murdoch
Yes, indeed, Duncan, it is as you think (above).
It is "official" in the sense that we've used this for a long
time in order to keep the 'Usage' section cleaner, when some
defaults are sophisticated, and a help page re
> Best,
> Wolfgang
I think John Nash and you misunderstood -- or then I
misunderstood -- the original proposal:
I've been understanding that there should be a "central repository" of URL
exceptions that is maintained by volunteers.
And rather *not* that package
or then I
>> misunderstood -- the original proposal:
>>
>> I've been understanding that there should be a "central repository" of
URL
>> exceptions that is maintained by volunteers.
>>
>> And rather *not* that package aut
Thank you, Ivan,
I've updated the source now,
Martin
> On line 105, "&\\hellip;" should probably be "…":
> Index: Rd2HTML.R
> ===
> --- Rd2HTML.R (revision 79833)
> +++ Rd2HTML.R
> Abby Spurdle (/əˈbi/)
> on Mon, 1 Feb 2021 19:50:32 +1300 writes:
> I'm a little surprised that the following doesn't trigger an error or a
warning.
> matrix (1:256, 8, 8)
> The help file says that the main argument is recycled, if it's too short.
> But doesn't say
901 - 1000 of 2287 matches
Mail list logo
