Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions inst/tests/froll.Rraw
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ if (exists("test.data.table", .GlobalEnv, inherits=FALSE)) {

exact_NaN = isTRUE(capabilities()["long.double"]) && identical(as.integer(.Machine$longdouble.digits), 64L)
if (!exact_NaN) {
cat("\n**** Skipping 7 NaN/NA algo='exact' tests because .Machine$longdouble.digits==", .Machine$longdouble.digits, " (!=64); e.g. under valgrind\n\n", sep="")
cat("\n**** Skipping 8 NaN/NA algo='exact' tests because .Machine$longdouble.digits==", .Machine$longdouble.digits, " (!=64); e.g. under valgrind\n\n", sep="")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could do something like nskip for foreign messages to avoid incrementing this manually

if (foreign && nskip > 0L) catf("Skipped %d tests for translated messages. ", nskip) # nocov

# for Matt when he runs valgrind it is 53, but 64 when running regular R
# froll.c uses long double and appears to require full long double accuracy in the algo='exact'
}
Expand Down Expand Up @@ -1450,7 +1450,7 @@ test(6001.729, frollvar(adaptive=TRUE, c(1:2,NA), c(2,0,2), algo="exact", na.rm=
test(6001.730, frollvar(adaptive=TRUE, c(1:2,NA), c(2,0,2), fill=99, algo="exact", na.rm=TRUE), c(99,NA,NA))
y = c(1e8+2.980232e-8, 1e8, 1e8, 1e8) # CLAMP0 test
test(6001.731, frollvar(y, 3)[4L], 0)
test(6001.732, frollsd(y, 3)[4L], 0)
if (exact_NaN) test(6001.732, frollsd(y, 3)[4L], 0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the other cases are all using algo='exact', so this would be the first case being skipped with algo='fast'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's also v. interesting that frollvar(y, 3)[4L], which per glancing the implementation only differs by applying sqrt(), does not have this numerical difference issue

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sqrt must be causing this rounding error

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could possibly use all.equal here instead... Then no need to escape test

test(6001.733, frollvar(y, c(3,3,3,3), adaptive=TRUE)[4L], 0)
test(6001.734, frollsd(y, c(3,3,3,3), adaptive=TRUE)[4L], 0)
test(6001.740, frollvar(c(1.5,2.5,2,NA), c(3,3)), list(c(NA,NA,0.25,NA), c(NA,NA,0.25,NA)), output="running sequentially, because outer parallelism has been used", options=c(datatable.verbose=TRUE)) # ensure no nested parallelism in rolling functions #7352
Expand Down
Loading