Mark Connolly wrote:
Does .BigInt always exist and always contain the appropriate divisor
regardless of the architecture? If not, does it exist _only_ for
64-bit architectures?
It always exists, and gives the right number for division - platform
dependent. Using a system constant wouldn't make the object portable
across architectures, assuming someone would want to do this of course.
Is the result of the operation always an offset, regardless of the
architecture? (I am presuming yes, but I don't have access to a
32-bit machine right now).
Yes. (It is 2^16 on 32 bits machines)
If I am writing R code to extract left and right appropriately, I'd
like to make sure it is portable across architectures. I am presuming
that this is the best way to get left and right. Capturing the
results of print(variogramCloud) seems kludgy.
Better method than both of these available?
Update your gstat package; the newer has an as.data.frame.variogramCloud
method, which avoids this kludge; just do an
as.data.frame(obj)
On 02/28/2010 10:37 AM, Edzer Pebesma wrote:
Well, they're called first and second, and a bit later they're named
"left" and "right", it nowhere says that "left" is first, or second.
As you say, there's little point in making the distinction anyway;
give me a case where it is confusing and I'll change it.
--
Edzer
Mark Connolly wrote:
Thanks. That works better.
It looks as though the documentation has left and right (implicitly)
switched? I am drawing line segments in 3D space using rgl, and I
don't care so much about the order. Might be confusing in some cases.
On 02/28/2010 09:49 AM, Edzer Pebesma wrote:
Mark, the documentation falsely assumes all computers have 32 bits
integers; yours seems not -- compare the .BigInt with sqrt(2^64).
To see how the point pairs are obtained, look at:
> gstat:::as.data.frame.variogramCloud
function (x, row.names, optional, ...)
{
.BigInt = attr(x, ".BigInt")
x$left = x$np%%.BigInt + 1
x$right = x$np%/%.BigInt + 1
x$np = NULL
class(x) = "data.frame"
x
}
so the .BigInt attribute is the divisor; 1 is added because the
arrays are set up in the C code, starting at 0.
--
Edzer
Mark Connolly wrote:
gstat reference states
If cloud is TRUE: an object of class variogramCloud, with the
field np encoding the numbers of the point pair that contributed
to a variogram cloud estimate, as follows. The first point is
found by the integer division of np by 2^16, the second point by
the remainder of that division.
For
Classes ‘variogramCloud’ and 'data.frame': 3275 obs. of 6 variables:
$ np : num 8.59e+09 8.00 8.59e+09 1.29e+10 1.29e+10 ...
$ dist : num 18.8 79.2 77.8 78.7 100.1 ...
$ gamma : num 0.781 0.845 12.903 5.611 0.344 ...
$ dir.hor: num 0 0 0 0 0 0 0 0 0 0 ...
$ dir.ver: num 0 0 0 0 0 0 0 0 0 0 ...
$ id : Factor w/ 1 level "var1": 1 1 1 1 1 1 1 1 1 1 ...
- attr(*, "direct")='data.frame': 1 obs. of 2 variables:
..$ id : Factor w/ 1 level "var1": 1
..$ is.direct: logi TRUE
- attr(*, ".BigInt")= num 4.29e+09
v[1,] yields:
dist gamma dir.hor dir.ver id left right
1 18.75474 0.78125 0 0 var1 6 3
v$np[1] %/% 2^16 yields:
131072
Which is != 6
Am I misinterpreting the documentation?
--
Edzer Pebesma
Institute for Geoinformatics (ifgi), University of Münster
Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251
8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de
http://www.52north.org/geostatistics [email protected]
_______________________________________________
R-sig-Geo mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
