ities
such as alist() would continue to work unchanged.
I have no idea (and no time currently to investigate) if such
warnings would be too disruptive for the current R code base or not.
Martin
*) "matched" in that case effectively means "dropped" as we have
seen
) ~= 1 :
> ppois(15:19, lambda=0.9)
[1] 1 1 1 1 1
> ppois(15:19, lambda=0.9, lower.tail=FALSE)
[1] 3.801404e-15 2.006332e-16 1.000417e-17 4.727147e-19 2.122484e-20
>
... and if you compare with
> ppois(15:19, lambda=0.9, log.p=TRUE)
and notice how similar the numbers a
the development sources to
see if a URL problem has already been addressed.
Still, of course "thank you!" for noticing and caring about it!
Best,
Martin
--
*) the only official source, everything else is a mirror
__
R-devel@r-project.org mai
D" instead of "E"):
> ## collation order is aAbBcCdDe ...
Indeed, now fixed. Thank you Mikko!
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
t;ä" "ö" # Linux
I can confirm the problem on Windows,
also for a recent version of R-devel.
Why not filing this as a proper bug report at R's bugzilla?
There's still no certainty that it will be fixed quickly, but
the bug PR's there are less easily forgotten.
ry they can contain up to"
> cheers
> Ben Bolker
Thank you, Ben! (I've chosen the more formal one)
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
next one, we have the pretty clear comment
### less simple examples in "See Also" above
I'm not convinced (but you can try more) we should change those
examples or add more there.
Martin
> On Fri, 14 Dec 2018 at 14:51, S Ellison
> wrote:
>> F
function
>
--
Is anyone aware of Free Software implementations of these,
ideally in C ?
... yes, I think I've found the Julia source code for these,
nicely written in Julia itself...
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
tra attributes but no special class or is it just
> an oversight?
May guess is "oversight" || "well let's keep it simple"
Do you (all readers) see situation where it could harm now (with
the 20'000 packages on CRAN+BIoc+...) to do as SV4 (S version 4) has been do
>>>>> Fox, John
>>>>> on Fri, 21 Dec 2018 16:16:40 +0000 writes:
> Dear Martin,
> Since no one else has picked up on this, I’ll take a crack
> at it:
Thank you, John
> The proposal is to define the S3 class of model-frame
lt;- "formula"
> f
> }
There's quite a bit of code looking for attr(*, "terms")
anyway in our code base, so indeed, this would be internally
consistent with the existing code base and hence probably the
best way to solve the original problem.
I'll
your code
and liked it, and I have committed it to R-devel aka "the trunk"
(svn rev 75890).
So this should become part of the R x.y.0 release around April 2019.
Thanking you once more ...
merry Christmas and happy holidays !
Martin
> I am happy to update the patch as needed.
vis builds of Bioconductor packages
https://stat.ethz.ch/pipermail/bioc-devel/2019-January/014506.html
and elsewhere
Martin Morgan
On 1/3/19, 7:05 PM, "R-devel on behalf of Duncan Murdoch"
wrote:
On 03/01/2019 3:37 p.m., Duncan Murdoch wrote:
> I see this too; by bisection, it see
g per se,
as the help page *does* mention that the acuracy there is reduced.
Still, I have created an R bugzilla account for you to report
there, i.e., https://bugs.r-project.org/
Best,
Martin
> Using R version 3.5.2.
> Cheers
> Mark
> [DELETED ATTACHMENT SmallR
to become NA_integer_
but changes are that would break code that has relied on the
current behavior {on "all but your computer" ;-)} ?
> Michael Chirico
Thank you for the report,
Martin Maechler
ETH Zurich and R Core Team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Martin Maechler
>>>>> on Fri, 11 Jan 2019 09:44:14 +0100 writes:
>>>>> Michael Chirico
>>>>> on Fri, 11 Jan 2019 14:36:17 +0800 writes:
>> Identified as root cause of a bug in data.table:
>> ht
>>>>> Michael Chirico
>>>>> on Sat, 12 Jan 2019 17:34:03 +0800 writes:
> Thanks Martin. For what it's worth, this extremely
> representative, highly scientific Twitter poll suggests
> the Mac/Linux split is pretty stark (NA on Mac,
> Travers Ching
> on Tue, 15 Jan 2019 12:50:45 -0800 writes:
> I have a toy alt-rep string package that generates
> randomly seeded strings. example: library(altstringisode)
> x <- altrandomStrings(1e8) head(x) [1]
> "2PN0bdwPY7CA8M06zVKEkhHgZVgtV1"
> "5PN2qmWqBlQ
s://svn.r-project.org/R-packages/trunk/nlme
in addition to 'nlme', at least 'foreign', 'mgcv' and
'cluster' are also maintained there.
Thank you for the question:
I do think "we" should add the corresponding svn URL t
ally compiling a list
of
> functions without long vector support. These days I frequently work with
> big enough matrices that I need it.
Thank you, Kasper, Duncan and Gabriel!
I agree with Duncan about "probably be useful to R Core".
Best,
Martin
> On Mon,
n relative difference: 5.534757e-07"
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
[1] "Mean relative difference: 1.816536e-12"
> abs( opt$objective - f(xhat) ) < 1e-4 ## Must be TRUE
[1] TRUE
>
for me. Maybe others can quickly run the above 7
>>>>> Berend Hasselman
>>>>> on Fri, 1 Feb 2019 15:59:58 +0100 writes:
>> On 1 Feb 2019, at 10:00, Martin Maechler
wrote:
>>
>>
>>>> sessionInfo()
>>> R version 3.5.2 (2018-12-20)
>>
> peter dalgaard
> on Mon, 4 Feb 2019 16:48:12 +0100 writes:
> Does either of you have a patch against current R-devel?
> I tried the obvious, but the build dies with
> building package 'tools'
> all.R is unchanged
> ../../../../library/tools/libs/x86_64/tools.so
hink) BLAS, but
no Lapack routines.
Still, I don't have much further clues, currently I think.
The only "failure" case, where R was 'self compiled' has been by
Kasper where he even found out that he could solve the prob
code{x} as a list. There is a
> replacement method which checks \code{value} for the correct number
> of rows, and replicates it if necessary.
Thanks a lot, Suharto, for finding and reporting this!
I've added a 2 x 2 words of explanation to make it easier to understand.
Now changed
ot matched, returning NULL;
all as it has always been and well documented in ?Extract.
Martin
>
> On Fri, 15/2/19, Martin Maechler
> wrote:
> Subject: Re: [Rd] Extract.data.frame.Rd about
> $.data.frame
> C
f0e99da345c6fb259
<https://github.com/wch/r-source/commit/b59a1526085d1b4375b184d35118c6fd6f003912#diff-12de104c9320556f0e99da345c6fb259>
> Best,
> Lionel
Yes, indeed... part of patches that Lionel had proposed himself!
Best,
Martin
>> On 21 Feb 2019, at 00:07
ople can use it to easily compute confidence intervals (or
p-values if really desired) for other levels than 95% / 5% ..
So adding another component to the list returned by t.test()
seems fine to me, and hopefully saves us future e-mails on the topic
[... well almost surely there will be those as
in the
reference manuals (:= union of all help pages).
{good useRs knowning that 'matrix' and 'arrays' are atomic
vectors, too .. as was mentioned.}
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
nings(.) ...
I see a version of the patch using old style indentation which
makes the diff even "considerably" smaller -- no need to submit
this different, though --
and I plan to test that a bit, and commit eventually to R-devel,
possibly in a 5 days or so.
Thank you Ben for the su
>>>>> Fox, John
>>>>> on Fri, 22 Feb 2019 17:40:15 +0000 writes:
> Dear Martin and Ben, I agree that a warning is a good idea
> (and perhaps that wasn't clear in my response to Ben's
> post).
> Also, it would be nice to c
the return value...
and that's what I'm planning to commit (to the sources).
With thanks for the suggestion and considerations to
Thomas, John and Peter!
Martin
> Getting such information printed by print.htest is more tricky, although
it might be possible to (ab)use the $estima
")))
Error in log("a") : non-numeric argument to mathematical function
as opposed to [ R version >= 3.5.0 ] :
> stopifnot(is.na(log("a")))
Error in is.na(log("a")) : non-numeric argument to mathematical function
---
s unneeded, I
think we'd all be more than happy.
> Another thing: currently,
> stopifnot(exprs=TRUE)
> fails.
good catch - indeed!
I've started to carefully test and try the interesting nice
patch you've provided below.
Thank you very much for your careful
out.fail
file) I could help you.
Note (by the way) that this may be yet another example showing
that OpenBLAS may be faster but less accurate than the
(plain+ minor tweaks) version of BLAS that ships with R.
Martin
> Thanks, Erin
> Erin Hodgess, PhD mailto: erinm.hodg...@gma
>>>>> Suharto Anggono Suharto Anggono via R-devel
>>>>> on Sat, 2 Mar 2019 08:28:23 + writes:
>>>>> Suharto Anggono Suharto Anggono via R-devel
>>>>> on Sat, 2 Mar 2019 08:28:23 + writes:
> A private reply b
ode you show above,
replace in line 1470
set.seed(42)
by
set.seed(42); suppressWarnings(RNGversion("3.5.0"))
It will use a different missingness pattern for that
multivariate AR example, i.e., different data.
Best, Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Martin Maechler
>>>>> on Tue, 5 Mar 2019 12:45:36 +0100 writes:
>>>>> Berwin A Turlach
>>>>> on Tue, 5 Mar 2019 16:54:09 +0800 writes:
>> G'day all,
>> I have daily scripts running to install th
> If so, maybe add a case for 'cl', like
> else if(is.expression(exprs))
> as.call(c(quote(expression), exprs))
that seems simple indeed, but at the moment, I cannot see one example
where it makes a difference ... or then I'm "blind" ..
>>>>> Martin Maechler
>>>>> on Tue, 5 Mar 2019 21:04:08 +0100 writes:
>>>>> Suharto Anggono Suharto Anggono
>>>>> on Tue, 5 Mar 2019 17:29:20 + writes:
>> Another possible shortcut definition:
>> asser
)
structure(NA_real_, class = "Date")
structure(NaN, class = "Date")
structure(110957, class = "Date")
structure(410957, class = "Date")
structure(1e+100, class = "Date")
structure(1.79769313486232e+308, class = "Date")
>
-
What if we left NA ( NA_character_ specifically ) as result for format(),
but changed the print() method so it gives better information
here ?
I would argue that -Inf and Inf should show differently than
true NA's or NaN's .. not the least because infinitely past and
infinitely into the future are different concepts.
Martin Maechler
ETH Zurich (and R Core team)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Martin Maechler
>>>>> on Wed, 6 Mar 2019 11:51:33 +0100 writes:
>>>>> Gabriel Becker
>>>>> on Tue, 5 Mar 2019 22:01:37 -0800 writes:
>> On Tue, Mar 5, 2019 at 9:54 PM Richard White wrote:
>>>
rst, about your make.names() "inconsistency", I'd say
it *is* consistent because e.g. ... can be used without quotes
and hence is a valid name (mostly ;-).
OTOH, make.names() being used to construct "valid" data frame
column names, maybe make.names() could be changed,
me() be
influenced
by a global option
[and we should've tried harder to keep things purely functional
(R remaining as closely as possible a "functional language"),
e.g. by providing wrapper functions the same way we have such
wrappers for versions of read.table() with different
As the topic came up on R-help
(as side issue in 'density vs. mass for discrete probability functions')
and Rui mentioned this old thread:
https://stat.ethz.ch/pipermail/r-help/2019-March/461989.html
I'm taking up this 5.5 years old thread from R-devel:
> peter dalgaard
> on Sat
Thank you, Robert for raising this here !
> Robert McGehee
> on Thu, 21 Mar 2019 20:56:19 + writes:
> R developers,
> Seems I get a bad result ("%#4.0-1e" in particular) when trying to use
prettyNum digits=0 with scientific notation. I tried on both my Linux box and
on
64-bit)
is slightly "better":
d=10 d=7 d=2 d=1 d=0
[1,] "123456" "123456" "123456" "1e+05" "1.234560e+05"
[2,] "12345.6""12345.6""12346" "12346" &quo
lso good thing that you have to read and
understand and then even e-talk to a human in the process.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
users have to visually scan 20 or 50 numbers? In
modern Data analysis they should never have to but rather look
at a visualization of those numbers. ... and that's what
significance stars are, not more, nor less.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
s extension/specialization to the already existing
class.
---
... and then, I do agree with Gabe that (in some cases), using
formal (aka "S4") classes is really what one should do in order
to get a clean interface.
Martin Maechler
ETH Zurich and R Core Team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
ge forever, emptyenv() really does not belong
> This is in R 3.4.4 but I can’t find an indication that this behaviour
> was ever changed.
Indeed... and as I mentioned I had never actively noticed the
use of topenv() at all...
Martin
> Cheers
> --
> Konrad
(configured?) far from ideal), you'd also find bug PR#17359
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17359
which was reported already on Nov 2017 .. and only fixed
yesterday (in the "cleanup old bugs" process that happens
often before the big new spring release
> Suharto Anggono Suharto Anggono via R-devel
> on Sun, 31 Mar 2019 15:26:13 + writes:
> Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval'
> inside 'for' makes compiled version behave like
> non-compiled version.
Ah.. ... thank you for detecting that " eval(
s rather surprising and annoying and doesn't add
clarity. Yes, stop() gives the same. But, in this case, just "Error", like in R
before version 3.5.0, feels better to me. If
> stop(simpleError(msg, call = if(p <- sys.parent()) sys.call(p)))
> were used in 'stopifnot&#x
>>>>> Tierney, Luke
>>>>> on Mon, 1 Apr 2019 12:41:08 + writes:
> On Mon, 1 Apr 2019, Martin Maechler wrote:
>>>>>>> Suharto Anggono Suharto Anggono via R-devel
>>>>>>> on Sun, 31 Mar 2019 15:26:13
t it would
> be worthwhile.
I think it would be worthwhile to add to the docs a bit.
[With currently just your and my vote, we have a 100% consensus
;-)]
Martin
> One workaround to the OP's problem is below (may be worth including
> as an example in docs)
>> z &
nix 'file' to determine that your 'foo.diff' file is plain text.
{{ .. and we all know that Windows is sillily using file extensions
to determine file type and only knows Windows-extensions plus
those added explicitly by software installed; so nowadays *.rda
is marked as
he above two seem interesting and relevant to R itself.
As we've recently just fixed a buglet in reformulate() --
probably unrelated to your problem -- I'd really be interested to see a
repr.ex. (reproducible example) for the above two statements.
... and if you want also a proposal on how
quot;all versions" of R (I did not look far back, but these things
haven't changed much).
The cleanest would probably be to define an all.equal.terms()
method, as I think there may be more code relying on the
behavior of all.equal.formula() to only look at the formulas
themselves and not their attributes...
but you (Duncan) and others may have a different opinion.
Martin Maechler
ETH Zurich and R Core Team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Martin Maechler
>>>>> on Fri, 5 Apr 2019 17:33:54 +0200 writes:
>>>>> Duncan Murdoch
>>>>> on Fri, 5 Apr 2019 11:12:48 -0400 writes:
>> On 05/04/2019 10:46 a.m., Therneau, Terry M., Ph.D. wrote:
>>>
R 3.6.0 that'll come in 8 days, not the
least thanks to Ben's patch (earlier in this thread).
Martin Maechler
> cheers
> Ben Bolker
> On 2019-04-18 7:30 a.m., Saren Tasciyan wrote:
>> Hi,
>>
>> Sorry for writing this late, I was very
bug report with patch PR#17556 :
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17556
I cannot easily build R for windows from the sources either, but
committed Duncan's fix to the R-devel sources for now,
in svn rev 76434, so we can all install a binary version of
R-devel for Windows (>= rev 76434) in a day or two
from CRAN https://cran.r-project.org/bin/windows/base/rdevel.html
thanks to Jeroen Ooms' autobuilder.
If that confirms the problem fixed, we will of course port it to
R 3.6.0 patched, so it will be in R 3.6.1 (which is *not* scheduled yet).
Martin Maechler
ETH Zurich and R Core Team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
should be increased from 0,5.0 to
> 0,6.0. I confirmed this resolves the problem. Could somebody commit
> this please?
> See also:
http://www.jrsoftware.org/is6help/index.php?topic=setup_minversion
Thank you, Avi and Jeroen!
I've now committed the change (in 4 places) to
ve R-help "workaround" goes back to 2005, and I
find it amazing this has never been taken up.
I've committed fix to this bug avoiding the misleading
substitute() and deparse() altogether in this case.
The plan is to port the bug fix also to "R 3.6.0 patche
-->
Error in if (!ordered && is.unsorted(x, na.rm = na.rm)) { :
missing value where TRUE/FALSE needed
> approx(x2, x2, method="constant", na.rm=FALSE)
Error in if (!ordered && is.unsorted(x, na.rm = na.rm)) { :
missing value where TRUE/FALSE ne
4.0
linear TRUENA 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.0
FALSE NA 1.0 NA NA NA 3.0 3.5 4.0 4.0
CN constant TRUE 1.0 1.0 1.0 1.0 1.0 3.0 3.0 4.0 NA
FALSE 1.0 1.0 1.0 NA NA 3.0 3.0 4.0 NA
linear TRUE 1.0 1.0 1.5 2.0 2.5 3.0 3.
me", ylab="poison")
> Best, Ulrike
Yes, indeed. Thank you, Ulrike, belatedly.
I've committed a corresponding change to R-devel yesterday, svn r 75503,
and will port that to "R 3.6.0 patched" (so it will make it into R 3
, 'by column' (generalized for arrays to "earlier dimensions vary faster
than later one") has been chosen, not the least because this had
been adapted for Fortran (first, AFAIK) and all related ABIs
dealing with Matrix vector arithmetic for very good (numerical,
performance, know
>>>>> Gabriel Becker
>>>>> on Fri, 17 May 2019 01:06:11 -0700 writes:
> Hi Martin,
> Thanks for chiming in. Responses inline.
> On Fri, May 17, 2019 at 12:32 AM Martin Maechler
> wrote:
>> >>>>> Gabriel Be
ot;atomic"
fast method, instead of using any(is.na(.)).
This may break existing code in packages, but the maintainers of
that code could solve the problems by providing anyNA(.)
methods for their objects.
Other opinions / ideas ?
Martin Maechler
ETH Zurich / R Core Team
--
*) in Sprin
unction (x, ...)
> Was this intentional?
No, it was not. ... and I've been the one committing the wrong change.
... Related to the NEWS entries which start
"Changes in print.*() "
Thank you Bill, for reporting
It's amazing this has not been detected earlier b
d objects with no print() method (but possibly a show() one).
Adding an option for autoprinting would render R even less
strictly functional, depending on yet another powerful global option,
and typical R usage would become more different from
'R --vanilla' even more --- really not a good
>>>>> Martin Maechler
>>>>> on Wed, 22 May 2019 09:50:10 +0200 writes:
>>>>> William Dunlap
>>>>> on Tue, 21 May 2019 12:11:45 -0700 writes:
>> Letting a user supply the autoprint function would be nice also. In a
> Simon Urbanek
> on Wed, 22 May 2019 11:54:49 -0400 writes:
> More to the point: the custom search function is currently broken anyway
- it just gives me 404.
> Should we just get rid of it? If people want to use Google they can just
say
> site:developer.r-project.org
ing bug report, apologies if I
missed it (am trying to follow the advice here:
https://www.r-project.org/bugs.html)<https://www.r-project.org/bugs.html>.
> Best, Paul
Thank you, Paul!
The typo is fixed in the sources of both "R-devel" and "R 3.6.0
patched"
to get confirmation etc
if what you see is a bug;
2) then ideally, you'd do a formal bug report at
https://bugs.r-project.org/
(for which you need to get an "account" there to be created
once only by a bugzilla admin, typically an R core member).
In this case, t
t; brings behaviour in line with the docs.
>
> -- Jenny
>
> [[alternative HTML version deleted]]
Thank you, Jenny -- and Jeroen for confirmation!
I've now found the time to read up a bit on this, notably ?writeClipboard
and the underlying source code,
and just from that readi
g
comments) and committed the fix to R-devel rev 76612 , planned
to be ported to R 3.6.0 patched a bit later.
Thank you once more!
Martin
--
Martin Maechler
ETH Zurich and R Core Team
>>>>> Joshua Ulrich
>>>>> on Sat, 21 Jan 2017 11:58:18 -0600 writes:
> Juan Telleria Ruiz de Aguirre
> on Thu, 30 May 2019 18:46:29 +0200 writes:
>Thank you Gabriel for valuable insights on the 64-bit integers topic.
>In addition, my statement was wrong, as Python3 seems to have unlimited
>(and variable) size integers.
If you are
))
[,1] [,2]
[1,] "2.5""3.1"
[2,] "2.50" "3.14"
[3,] "2.500" "3.142"
[4,] "2.5000" "3.1416"
[5,] "2.5""3.14159"
[6,] "2.50&
6.x series ... and I have no idea if it would affect much more
than R's own tests/reg-tests-* ...
Even though the argument name 'evaluated' was chosen for
withAutoprint(), I don't find it a very good name anymore, and -
if the change should happen - would probably prefer some
mp : int 67 72 74 62 56 66 65 59 61 69 ...
> $ Month : int 5 5 5 5 5 5 5 5 5 5 ...
> $ Day : int 1 2 3 4 5 6 7 8 9 10 ...
> Regards
> David Scott
Thank you, David!
Already fixed in the sources (R-devel & R-patched).
Best,
Martin
__
>>>>> Juan Telleria Ruiz de Aguirre
>>>>> on Mon, 3 Jun 2019 06:50:17 +0200 writes:
> Thank you Martin for giving to know and developing 'Rmpfr' library for
> unlimited size integers (GNU C GMP) and arbitrary precision floats (GNU C
roducts such as Microsoft
or Google (below) is really ridiculous.
They have lots of money to spend and pay many many work hours to
pay.
We don't want to: Given such (and potentially many more similar) e-mail
threads plus the issues mentioned above (plus Virus scanners,
plus broken fil
>>>>> Martin Maechler
>>>>> on Mon, 3 Jun 2019 18:14:15 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono
>>>>> on Thu, 30 May 2019 14:45:22 + writes:
>>>>> Suharto Anggono Suharto Anggono
>>>&
f FALSE will skip the simplification
>> step.
>> Any thoughts? One particular question that Martin raised is whether the
>> UI should be just a single logical argument, or something else.
> Firstly, note that the constructor for formula objects behaves d
-devel, e.g.,
> formula(c("y~ ", " x"))
y ~ x
Warning message:
Using formula(x) is deprecated when x is a character vector of length > 1.
Consider formula(paste(x, collapse = " ")) instead.
> formula("{y ~ x}")
y ~ x
Warning message:
invalid fo
> Sarah Goslee
> on Thu, 20 Jun 2019 09:56:44 -0400 writes:
> I can reproduce this.
> It has to do with whether the value rounds down to 9 or up to 10, and
> thus needs another space, I think. I agree that it shouldn't happen,
> but at least you can get rid of the spac
Software
> wdunlap tibco.com
Yes, indeed, thank you, Bill!
But they *have* been in use by core R functions for a long time
in pgamma, pbeta and related functions.
[and I have had changes in *hyper.c where logspace_add() is used too,
for several years now (since 2015) but I no longer kno
ficiently for the vector and matrices cases,
Source code from source file copula/R/special-func.R
(in svn at R-forge :
-->
https://r-forge.r-project.org/scm/viewvc.php/pkg/copula/R/special-func.R?view=markup&root=copula
)
{Ye
bles found for ‘colMeans’
> sessionInfo()
R Under development (unstable) (2019-06-20 r76729)
(similarly with other versions of R >= 3.6.0).
So, even though R core has fixed this now in the sources, it
would be nice to have an "as simple as possible" repr.ex. for this.
Ma
> Karolis K
> on Fri, 21 Jun 2019 18:00:36 +0300 writes:
> In specific cases fligner.test() can produce a small p-value even when
both
> groups have constant variance.
> Here is an illustration:
> fligner.test(c(1,1,2,2), c("a","a","b","b"))
> # p-value = NA
>>>>> Martin Maechler
>>>>> on Fri, 5 Oct 2018 12:16:37 +0200 writes:
>>>>> Hilmar Berger
>>>>> on Fri, 5 Oct 2018 10:17:49 +0200 writes:
>> Dear all, I just found this issue:
>> I just found this issue:
NA # now have an omittedSig with {T, F, NA}
> iSig <- seq_along(omittedSig)[omittedSig]
> sign2[iSig] <- "missing"
> signatures[omittedSig] <- "missing"
> identical(sign2, signatures)
[1] TRUE
>
so I still don't see the case where it makes a differe
piece of using trace() .. and the above
is useful for solving the issue -- I can work with that.
I'm already pretty sure the wrong code starts with
omittedSig <- sigNames %in% fnames[omitted] #
-
*Still* I cannot understand why in my case (and probably Peter,
as he also said he can't reproduce),
the conformMethod() function is not even called when I run
loadNamespace("oligo").
As conformMethod() is *only* called from setMethod(), I've
started trace()ing setMethod() and indeed, it is *only* called one,
and not with oligo methods/generics,...
Henrik, do you per chance not install packages in the usual way,
i.e., do you install them without saving all the pre-computed
classes and methods tables etc,
and that would be *why* these setMethod() etc are only called at
this point in time ?
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> peter dalgaard
>>>>> on Fri, 28 Jun 2019 16:20:03 +0200 writes:
> > On 28 Jun 2019, at 16:03 , Martin Maechler
> > wrote:
> >
> >>>>>> Henrik Bengtsson
> >>>>>>on Thu, 27 Jun 2019 16:00
>>>>> Martin Maechler
>>>>> on Sat, 29 Jun 2019 10:33:10 +0200 writes:
>>>>> peter dalgaard
>>>>> on Fri, 28 Jun 2019 16:20:03 +0200 writes:
>> > On 28 Jun 2019, at 16:03 , Martin Maechler
wrote:
>> &g
>>>>> Martin Maechler
>>>>> on Sat, 29 Jun 2019 12:05:49 +0200 writes:
>>>>> Martin Maechler
>>>>> on Sat, 29 Jun 2019 10:33:10 +0200 writes:
>>>>> peter dalgaard
>>>>> on Fri, 28 Jun
e call .local(object, target) would be
> appropriate if "subset" was missing also from the
> signature of the function object (the latter would be
> illegal here). Alternatively, it could be named, as in
> .local(object, target = target) or maybe even
> .local(object, , target)
cial"
conformMethod() call.
Still, of course, it's wrong and should be corrected.
I've started to test changes .. maye not get to commit (with
enough confidence) before taking the train to
useR! 2019 @ Toulouse (France).
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
201 - 300 of 2292 matches
Mail list logo
