Test failure on some non-x86 systems about nanotime

[eddelbuettel]

That just looks like a lack of precision beyond the '4', ie .987654 is agreed upon.

I am guessing here but those system may just not have the nanosecond resolution the C++ chrono type can provide if the compiler / host / os support it.

In short, that looks like a CCTZ issue on that platform. You could report it as a short (five or so lines should do) C++ program at the CCTZ GitHub repo.

For nanotime, I suggest to relax the comparison precision on those platforms.

[QuLogic]

The problem appears to be here:

> d <- RcppCCTZ::parseDouble("2120-01-01T00:00:59.987654321+00:00", fmt="%Y-%m-%dT%H:%M:%E9S%Ez", tz="UTC")
> d
           [,1]      [,2]
[1,] 4733510459 987654321

> as.integer64(d[,1]) * 1e9
integer64
[1] 4733510459000000512

> as.integer64(d[,1]) * as.integer64(1e9)
integer64
[1] 4733510459000000000

I don't know if that qualifies as a bug in bit64 or just the usual floating-point issues, but it appears easily fixable here.

[QuLogic]

Also working:

> as.integer64(d[,1]) * 1000000000L
integer64
[1] 4733510459000000000

> as.integer64(d[,1]) * 1e9L
integer64
[1] 4733510459000000000

[eddelbuettel]

Nice catch, clearly on my side. That point is where we can loose precision between 53-bit doubles and the 64 bit ints we don't "really" have in R. But I like that idea a bit. @lsilvest do you see anything wrong this, or should be try this?

[eddelbuettel]

Looking your example again:

R> d <- RcppCCTZ::parseDouble("2120-01-01T00:00:59.987654321+00:00", 
+                             fmt="%Y-%m-%dT%H:%M:%E9S%Ez", tz="UTC")        
R> d 
           [,1]      [,2]           
[1,] 4733510459 987654321       
R>  

So far, so good. We specified something at 18 digits precision, and we got 18 digits back.

But in the rest, you are demonstrating that doubles only have 15 digits, which is what we know.
Also my amd64 seems to be kinder:

R> suppressMessages(library(bit64))
R> as.integer64(d[,1]) * 1000000000L
integer64
[1] 4733510459000000000
R> as.integer64(d[,1]) * 1e9L
integer64
[1] 4733510459000000000
R> as.integer64(d[,1]) * 1.0e9
integer64
[1] 4733510459000000000
R> as.integer64(d[,1]) * 1e9
integer64
[1] 4733510459000000000
R> 

Here I can scale out clearly because bit64 helps. But in general we will loose precision when
going to R's representation so I still think we should just not do those tests on platforms which are
less generous to us than amd64.

[QuLogic]

IIRC, x86 has some extended registers (80-bit) that can be a bit more forgiving in some circumstances. I'm not totally familiar with the ppc64 system, so I do find it odd that LE is fine but BE is not.

In any case, when working with large numbers like this, it seems best to avoid fp math altogether.

[eddelbuettel]

Yes. nanotime is a compromise as R does not have native int64_t so corner cases appear.

But it is very useful on some platforms, and we made the package way more robust (via a S4 rewrite, thanks to @lsilvest ) than it was before, and it fills a need.

Let me know if you need upstream help to turn some tests off on those platforms. On Debian, we tend to build everything everywhere (ie every package on every platforms where it compiles) and we can aid that here by suppressing some tests that would puke on some of those systems.

[QuLogic]

I'm not quite sure I understand why it's preferable to change tolerances or disable tests rather than add the integer L suffix (or as.integer64) on the few used constants? 1e9 is within a 32-bit integer so the lack of a 64-bit integer type is not super important as far as the constant is concerned (and it's multiplied by a bit64::integer64 anyway.) And using as.integer(1000000000) is already done for the 'reverse' operation in format.nanotime.

[eddelbuettel]

Slow down. No tests are disabled.

I showed your issue was not reproducable at my end, hence "ball in your court". And I am not sure why you are arguing endlessly with me. Propose a clean, small, ... pull request, ideally with a new test and folks may listen.

Anyway, try this branch with two new casts.

[QuLogic]

Yes, thank you, that branch works on all arches.

[eddelbuettel]

Thanks for reporting back. It has since been released to CRAN as new version 0.2.1, see https://cloud.r-project.org/web/packages/nanotime/index.html