>>>>> Uwe Ligges
>>>>> on Sun, 7 Aug 2016 09:51:58 +0200 writes:
> On 06.08.2016 17:30, Duncan Murdoch wrote:
>> On 06/08/2016 10:18 AM, Martin Maechler wrote:
[.]
>>> Of course, an ifelse2() should also be
<- if (!missing(exclude) && is.null(exclude)) "ifany" # was "always"
which would not even contradict documentation, as indeed you
mentioned above, the exact action here had not been documented.
The change above at least does not break any of the standard R
tests ('make check-
>>>>> Martin Maechler
>>>>> on Tue, 9 Aug 2016 15:35:41 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono via R-devel
>>>>> on Sun, 7 Aug 2016 15:32:19 + writes:
> > This is an example from
> > https://
points:
> Could R 2.7.2 behavior of table(, exclude = NULL) be brought
back? But R 3.3.1 behavior is in R since version 2.8.0, rather long.
you are right... but then, the places / cases where the behavior
would change back should be quite rare.
> If not, I suggest changing summary()
Excuse for the delay; I had waited for other / additional
comments and reactions (and been distracted with other urgent issues),
but do want to keep this thread alive [inline] ..
>>>>> Duncan Murdoch
>>>>> on Sat, 6 Aug 2016 11:30:08 -0400 writes:
&g
>>>>> Martin Maechler
>>>>> on Fri, 12 Aug 2016 10:12:01 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono via R-devel
>>>>> on Thu, 11 Aug 2016 16:19:49 + writes:
>> I stand corrected. The part &quo
the 8000+) CRAN packages
which I am investigating now and probably will be in contact with the
package maintainers after that.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> Martin Maechler
>>>>> on Mon, 15 Aug 2016 11:07:43 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono
>>>>> on Sun, 14 Aug 2016 03:42:08 + writes:
>> useNA <- if (missing(useNA) && !missing(excl
>>>>> Martin Maechler
>>>>> on Mon, 15 Aug 2016 12:35:41 +0200 writes:
>>>>> Martin Maechler
>>>>> on Mon, 15 Aug 2016 11:07:43 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono
>>>>> o
i.e., return the 4th possible result
> table(d.patho, ..)
d.patho
123
21 0 2
From a UI point of view, this should probably be achieved by a
forth 'useNA' option
but then, I'm *not* jumping to doing that right now
but *will* update the
But if the axis is reversed that should be:
> keep <- z <= range[1L] & z >= range[2L]
yes, something like that, you are right.
Thank you very much, William, for the succinct report and diagnosis!
I'm going to fix this.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
> Suharto Anggono Suharto Anggono via R-devel
> on Sun, 21 Aug 2016 10:44:18 + writes:
> In R devel r71124, if 'x' is a factor, droplevels(x) gives
> factor(x, exclude = NULL) . In R 3.3.1, it gives
> factor(x) .
> If a factor 'x' has NA and levels of 'x' doesn't
ummary()es, or then a numeric matrix .. in
both cases have a good print() method)
because when you return a character matrix, all the numbers are
already rounded, ... and if we follow the above approach they
would have to be rounded further... ``the horror''
I wonder how much code out th
>>>>> 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
dentically ... but currently don't
> I filed this is as a bug because it's undocumented, and inconsistent
> with how other arguments typically passed through `plot.default` are
> handled.
> I'll be happy to do the patch myself -- I just need to kno
>>>>> 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
k),
and leads to behavior which is much closer to the documentation,
notably for your two examples above would give what one would
expect.
(( If the R-Hub would support experiments with branches of R-devel
from R-core members, I could just create such a branch and R Hub
would run 'R CMD c
>>>>> 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
>>>>> robin hankin
>>>>> on Thu, 8 Sep 2016 10:05:21 +1200 writes:
> Martin I'd like to make a comment; I think that R's
> behaviour on 'edge' cases like this is an important thing
> and it's great that you are worki
I'd be for it being an error even if y is length 1,
>> though I do acknowledge this is more likely (though still quite unlikely
>> imho) to be the intended behavior.
>>
>> ~G
>>
>>>
>>> I.e., I think the type check shou
>>>>> 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 gi
atrix' case
[[1]]
[1] 3.141593
[[2]]
'mpfr1' 0.14285714285714285714285708
>
Yes, it would be very nice if c(.) could be used to
concatenate quite arbitrary R objects into one long atomic
vector, but I don't see how to achieve this easily.
The fact, that c() just bu
ntirely correct.
I'm amazed that table(*, exclude = *) seems so rarely used / tested,
that this has gone undetected for almost four weeks.
It is fixed now with svn r71230.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
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
>>>>> William Dunlap
>>>>> on Tue, 13 Sep 2016 09:06:00 -0700 writes:
> While you are editing that, you might change its name from 'stderr'
> to standardError (or standard_error, etc.) so as not to conflict with
> base::stderr
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
entation lag.
Thank you, Karl and David,
yes it is a documentation glitch ... and a bit more: Experts know that
print()ing of primitive functions is, eehm, "special".
I've committed a change to R-devel ... (with the intent to port
to R-patched).
Martin
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
functions
'c.Date',
>>>> 'c.POSIXct' and 'c.difftime'.
You are right, Suharto, that methods for c() currently have no
such argument.
But again because c() is primitive and has a '...' at the
beginning, this does not explicitly hurt, currently,
; 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
>>>>> Henrik Bengtsson
>>>>> on Sat, 24 Sep 2016 11:31:49 -0700 writes:
> Martin, did you post your code for withAutoprint() anywhere?
> Building withAutoprint() on top of source() definitely makes sense,
> unless, as Bill says, source() it
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.
ygen2 documentation, unit tests, using
version control, etc... in a completely incremental way. At the end of
it all, I'll still install and use my package with
devtools::install("myutils")
foo()
maybe graduating to
devtools::install_github("mtmorgan/myutils")
librar
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
tant for dealing with function
argument lists much more transparently than the
as.list() things below:
formals()
formals() <- # and
alist()
for creating / modifying function argument lists (which are
pairlists, but the user does not need to know really).
Or did you imply, Henrik,
(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
.2.2 RC' (RC
:= Release candidate; release in ca 5 days)
(R-bugzilla would have been fine, too. It's slightly more work
for you and R core, but in general things there should less
easily fall between the cracks)
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
sfsmisc::primes(3e+07) : reached elapsed time limit
Timing stopped at: 0.538 0.132 0.671
This *is* embarrassing a bit; .. probably too late to be fixed
for 3.3.2 .. (and something I'd rather leave to others to fix).
It may be that this has never worked on Linux, or then worked in
Linuxen wh
"
> library(ggplot2)
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
es gibt kein Paket namens ‘gtable’
Fehler: Laden von Paket oder Namensraum für ‘ggplot2’ fehlgeschlagen
>
c) Japanase :
> Sys.setenv("LANGUAGE"="ja"); Sys.setloc
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
>>>>> Jan Gorecki
>>>>> on Fri, 4 Nov 2016 11:20:37 + writes:
> Martin, I submitted very simple patch on
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17176
> Herve, While I like your idea, I prefer to keep my patch
>>>>> 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:
h-closed-connections
> on memory usage over time
> PS2 the issue doesn't seem to be due to writing more data in the first
> R app compared to what the second R app can handle, as I tried the
> same with adding a Sys.sleep(0.01) in the first app and that's
ory leak.
I'm testing ('make check-all') currently and then (probably) will
commit the patch R-devel only for the time being.
Martin
> FYI,
> Gabor
>
> Index: src/main/connections.c
> ===
>
ch( ,
error = function(e)
dump.frames(to.file = TRUE, include.GlobalEnv = TRUE))
Using R-devel is nice and helpful for the R community, as you
will help finding bugs/problems in the new features (and
possibly changed features) we've introduced there.
Best regards,
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> nospam@altfeld-im de
>>>>> on Tue, 15 Nov 2016 01:15:46 +0100 writes:
> Martin, thanks for the good news and sorry for wasting your (and others
> time) by not doing my homework and query bugzilla first (lesson learned!
> ).
>
> I have t
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
>>>>> Gabriel Becker
>>>>> on Tue, 15 Nov 2016 11:56:04 -0800 writes:
> All,
> Martin: Thanks for this and all the other things you are doing to both
> drive R forward and engage more with the community about things like this.
>
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
>
RUE, FALSE, NA, TRUE), lt, lt-100)
> is an example of mixed class.
good; thank you for the hint.
> * The part of function 'chkIfelse' in
> for(i in seq_len(nFact))
> uses 'NA.' function argument. That makes error when 'chkIfelse' is
applied to fu
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
at(d)
--
I have now committed a "minimal" patch (to the C code) which for
the above two cases gives a sensible error rather than a
seg.fault :
> d <- as.POSIXlt("2016-12-06"); d$zone <- 1 ; f <- format(d)
Error in format.POSIXlt(d) :
invalid 'zone&#x
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
.3.1. Similar behavior is found in 3.4.0. It seems to include all
functions and methods. I imagine something is being passed to "grep"
without being escaped.
Exactly; I've fixed this in r71763 (R-devel).
Martin Morgan
I hope I didn't miss something in the documentation, and
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
7;usetz' too). This/these would be (an) extra
argument(s) rather than passing '...' not just to print() but
also to format()rathere
My personal preference would tend to add both
tz = ""
and usetz = TRUE
to the formal arguments of print.POSIXct and pass the
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
8")
[1] 4.407213e-280
>
> as.double("0x1.p-927") # works
[1] 8.814426e-280
but then adding more zeros before "p-927" also underflows.
--> I have created an R bugzilla account for you; so you now
can submit bug reports (including patch proposals to the source (hint!) ;-)
Thank you, Florent!
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
, so you need to provide the
complete compilation output.
Did you do this on a version of the package that did not have any
previous build artifacts (e.g., via biocLite() or from a fresh svn
checkout)?
Martin
On 12/21/2016 12:00 PM, lejeczek via R-devel wrote:
I'm not sure if I should b
compiler output into an email message, avoding
attachments.
Martin
On 21/12/16 17:06, Martin Morgan wrote:
mzR is a Bioconductor package, so better to ask on the Bioconductor
support forum
https://support.bioconductor.org
Oh, I see you did, and then the advice is to avoid cross-postin
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/librar
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
') for 'FUN'. The new function would be
> str(tapply)
function (X, INDEX, FUN = NULL, ..., init.value = NA, simplify = TRUE)
where the '...' are passed FUN(), and with the new signature,
'init.value' then won't be passed to FUN "anymore" (
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
Dear Florent,
thank you for striving to clearly disentangle and present the
issue below.
That is a nice "role model" way of approaching such topics!
>>>>> Florent Angly
>>>>> on Fri, 27 Jan 2017 10:24:39 +0100 writes:
> Martin, I agree
somewhat inefficient and ugly.
> There is an old related discussion starting on
https://stat.ethz.ch/pipermail/r-devel/2007-November/047338.html .
Thank you, indeed, for finding that. There Andrew Robinson did
raise the same issue, but his proposed solution was not much
back compatib
>>>>> 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"
>> >
701 - 800 of 2292 matches
Mail list logo
