>
> Mike,
>
> this is all nice, but AFAICS the first part misses the point that there is no
> 64-bit integer type in the API so there is simply no alternative at the
> moment. You just said that you don't like it, but you failed to provide a
> solution ... As for the second part, the idea i
Mike,
this is all nice, but AFAICS the first part misses the point that there is no
64-bit integer type in the API so there is simply no alternative at the moment.
You just said that you don't like it, but you failed to provide a solution ...
As for the second part, the idea is not new and is n
Thanks,
http://cran.r-project.org/doc/manuals/R-ints.html#Future-directions
Normally I'd take more time to digest these things before commenting but
a few things struck me right away. First, use of floating point or double
as a replacement for int strikes me as "going the wrong way" as often
Mike,
Neither bigmemory nor ff are "drop in" solutions -- though useful,
they are primarily for data storage and management and allowing
convenient access to subsets of the data. Direct analysis of the full
objects via most R functions is not possible. There are many issues
that could be discus
We keep getting questions on r-help about memory limits and
I was curious to know what issues are involved in making
common classes like dataframe work with disk and intelligent
swapping? That is, sure you can always rely on OS for VM
but in theory it should be possible to make a data structure