Error in voxdims of im3d objects, when using large origin coordinates?

[Magnus Marius Rohde]

Hi,


I have run into a problem with voxel dimensions when I use large numerical values in the origin of the im3d object. voxdims() on my object returns values close to, but not exactly the same as the correct values. Example:

> test_1 <- im3d(dims = c(83,83,83), voxdims = c(25.3, 25, 0.25), origin = c(573015.5,6222512.5,-33) )

does not give the expected voxel dimensions of 25.3, 25 and 0.25:

> voxdims(test_1)
[1] 25.2926829 25.0000000 0.2560976

When I change the coordinates of the origin: 

> test_2 <- im3d(dims = c(83,83,83), voxdims = c(25.3, 25, 0.25), origin = c(15.5,12.5,-33) )

I get the expected result.

> voxdims(test_2)

[1] 25.30 25.00  0.25

This happens when one of the origin coordinates is above 3160227

test_3 <- im3d(dims = c(83,83,83), voxdims = c(25.3, 25, 0.25), origin = c(573015.5,3160227,-33) )

voxdims(test_3)

is ok, but 

test_4 <- im3d(dims = c(83,83,83), voxdims = c(25.3, 25, 0.25), origin = c(573015.5,3160227,-33) )

voxdims(test_4)

is not.

Is this behavior expected or is it a bug? 

I can reproduce this behaviour on Windows 10 and MacOS catalina. on (Microsoft) R 3.5 with nat version 1.8.11 and 1.10.2.

Regards,

Magnus

[Magnus Marius Rohde]

Well I have solved my own problem...

It was caused by rounding of the coordinates in order to remove floatingpoint errors. In the final lines of function makeboundingbox():

"
# zap small gets rid of FP rounding errors

structure(zapsmall(x), class = "boundingbox") 
"

The function zapsmall() uses the option "digits" to specify the number of digits. This option defaults to 7, and setting it to a higher number (I used 13) solves the issue for me:

 

> options(digits = 13)

Regards,

Magnus

[Greg Jefferis]

Well done for finding that! I didn't have time to respond earlier but I did remember that zapsmall call, which I have debated in the past. It it is there because sometimes people did not like it when origin/voxdims/bounding box ended up having things like 0.000001 etc. You can use a package called withr to set options temporarily if that helps.

withr::with_options(list(digits=13), voxdims(test_1))

If you don't mind maybe you could make an issue here and I could think if there's any workaround.

https://github.com/natverse/nat/issues

All the best,

Greg.

[Magnus Marius Rohde]

Thank you for your reply, I will make an issue on github.

The solution could involve some variation of zapsmall(x, digits = .Machine$double.digits %/% 4), but it depends on the source of the data with rounding errors. 

Regards, 

Magnus