Fixed in R-devel (74418).
Tomas
On 03/15/2018 08:57 PM, Tomas Kalibera wrote:
On 03/15/2018 05:25 PM, Henrik Bengtsson wrote:
On Thu, Mar 15, 2018 at 3:39 AM, wrote:
Thank you for your answer!
I agree with you except for the 3 (Error) example and
I realize now I should have started with that
R uses long double type for the accumulator (on platforms where it is
available). This is also mentioned in ?sum:
"Where possible extended-precision accumulators are used, typically well
supported with C99 and newer, but possibly platform-dependent."
Tomas
On 03/16/2018 06:08 PM, Pierre Chau
> On Mar 16, 2018, at 9:19 AM, Serguei Sokol wrote:
>
> Le 16/03/2018 à 17:10, David Hugh-Jones a écrit :
>> Hi all,
>>
>> I expect I'm getting something wrong, but
>>
>> cat("foo bar baz foo bar baz foo bar baz", fill = 10)
>>
>> should be broken into lines of width 10, whereas I get:
>>
>
My simple functions were to compare the result with the gfortran
compiler sum() function. I thought that the Fortran sum could not be
less precise than R. I was wrong. I am impressed. The R sum does in fact
match the result if we use the Kahan algorithm.
P.
I am glad to see that R sum() is m
Agreed. Perhaps this is a documentation issue:
fill: a logical or (positive) numeric controlling how the output is
broken into successive lines. If ‘FALSE’ (default), only
newlines created explicitly by ‘"\n"’ are printed.
Otherwise, the output is broken into lin
Le 16/03/2018 à 17:10, David Hugh-Jones a écrit :
Hi all,
I expect I'm getting something wrong, but
cat("foo bar baz foo bar baz foo bar baz", fill = 10)
should be broken into lines of width 10, whereas I get:
cat("foo bar baz foo bar baz foo bar baz", fill = 10)
foo bar baz foo bar baz foo
Hi all,
I expect I'm getting something wrong, but
cat("foo bar baz foo bar baz foo bar baz", fill = 10)
should be broken into lines of width 10, whereas I get:
> cat("foo bar baz foo bar baz foo bar baz", fill = 10)
foo bar baz foo bar baz foo bar baz
This is on R 3.4.3, but I don't see menti
Thanks. Fix committed to R-devel in r74417.
Best,
luke
On Sat, 10 Mar 2018, Henrik Bengtsson wrote:
Great.
For the record of this thread, I've submitted patch PR17391
(https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17391). I've
patched it against the latest R-devel on the SVN, passes
Install the gmp package, run your code, and then try this:
bu <- gmp::as.bigq(u)
bs4 <- bu[1] + bu[2] + bu[3] + bu[4] + bu[5]
s4 <- as.double(bs4)
s1 - s4
## [1] 0
s2[[2]] - s4
## [1] 7.105427e-15
s3 - s4
## [1] 7.105427e-15
identical(s1, s4)
## [1] TRUE
`bs4` is the exact sum of the binary
Pierre,
It's comforting to think that the same simple summation loop implemented in
R, C, and Fortran would give bit-wise identical results, but that isn't the
case in practice. Floating-point results depend on lots of things: the
chip used, the compiler used, the optimization flags, etc. For ex
Hi all,
I found a discrepancy between the sum() in R and either a sum done in C
or Fortran for vector of just 5 elements. The difference is very small,
but this is a very small part of a much larger numerical problem in
which first and second derivatives are computed numerically. This is
part
Thanks, Joris,
This clarifies at least where exactly it comes from. I still find the
high-level behavior of 'predict' very counter-intuitive as the estimated
model contains no coefficients in 'z', but I think we agree on that.
I am not sure how much trouble it would be to improve this behavior, b
Technically it is used as a predictor in the model. The information is
contained in terms :
> terms(x ~ . - z, data = d)
x ~ (y + z) - z
attr(,"variables")
list(x, y, z)
attr(,"factors")
y
x 0
y 1
z 0
attr(,"term.labels")
[1] "y"
attr(,"order")
[1] 1
attr(,"intercept")
[1] 1
attr(,"response")
[1
Joris, the point is that 'z' is NOT used as a predictor in the model.
Therefore it should not affect predictions. Also, I find it suspicious that
the error only occurs when the response variable conitains missings and 'z'
is unique (I have tested several other cases to confirm this).
-Mark
Op vr
It's not a bug per se. It's the effect of removing all observations linked
to a certain level in your data frame. So the output of lm() doesn't
contain a coefficient for level a of z, but your new data contains that
level a. With a small addition, this works again:
d <- data.frame(x=rnorm(12),y=rn
Dear R-developers,
In the 'lm' documentation, the '-' operator is only specified to be used
with -1 (to remove the intercept from the model).
However, the documentation also refers to the 'formula' help file, which
indicates that it is possible to subtract any term. Indeed, the following
works wi
16 matches
Mail list logo
