From jeroenooms at gmail.com  Sat Jan 21 13:10:44 2017
From: jeroenooms at gmail.com (Jeroen Ooms)
Date: Sat, 21 Jan 2017 13:10:44 +0100
Subject: [Rd] How to handle INT8 data
In-Reply-To: <CAECWziKVhF93xSFdxFN2Gvc4JuG8ms1TrDTNJC-cTzr7+cZA7Q@mail.gmail.com>
References: <20170120143335.GE9661@aphp.fr>
	<CADwqtCONJBR+N_skH2ONWLBPvimNKyyCTDPzLbxvONxKPJfdeA@mail.gmail.com>
	<CAECWziKyK2_EW9M7s-6qz6GOyWWRXZpAoTo8aroCWwkoOrBbMA@mail.gmail.com>
	<CAECWziL2yBNBPpbj2-nQaCMv4W+C7ncGK_23Eh146R3F5BvM-A@mail.gmail.com>
	<CAECWziKVhF93xSFdxFN2Gvc4JuG8ms1TrDTNJC-cTzr7+cZA7Q@mail.gmail.com>
Message-ID: <CABFfbXsgiyNKuaAw1JtZRM5KZAyHef_M-xJLbbEV0ZQLM7W5EQ@mail.gmail.com>

On Fri, Jan 20, 2017 at 6:09 PM, Murray Stokely <murray at stokely.org> wrote:
> The lack of 64 bit integer support causes lots of problems when dealing
> with certain types of data where the loss of precision from coercing to 53
> bits with double is unacceptable.
>
> Two packages were developed to deal with this:  int64 and bit64.

Don't forget packages for large arbitrary large numbers such as Rmpfr
and openssl.

  x <- openssl::bignum("12345678987654321")
  x^10

The risk of storing int64 as a double (e.g. in bit64) is that it might
easily be mistaken for a completely different value via unclass() or
Rf_isNumeric() or so.



[Rd] How to handle INT8 data
Jeroen Ooms