Coordinate rounding or incorrect averaging(?)

As the questionmark in the title already indicates, I was not quite sure how to describe the phenomenon I’m now running into.

In short, I’m feeding a custom set of coordinates (determined using cnt and rcalc) to rtrace , which is then averaged using ‘total -m’ and then converted (partially) by rcalc. The context: I’m trying to calculate spherical illuminance (using a modified version of Greg’s example code from link: Spherical sensor).

As can be seen in the code below, the coordinates should result (in this example) in max 2 decimals behind the comma (or dot) and should take incremental steps of 0.1. However, for some reason, at the end of the chain when the coordinates are saved to the output, I get 10 decimals with an odd figure at the end. For example, one row of the output looks like: 0.0500000007 0.0500000007 0.550000012 478.717706 (which should have read 0.05 0.05 0.55 478.717706 - I dont mind the digits for the last one).

Now, my theory is that it might have something to do with the averaging step at the end. The averaging is setup so that every 10.000 rows of each column are average, which corresponds to the number of rays used per sampling point.

Now, for the code used: I use Python (on a linux cluster) to script, but I think its quite readable without python knowledge. For those unfamiliar with Python, the ‘os.system’ is simply the system call, and the ‘f’ before the radiance code indicates its an f-string which can contain variables, where each variable is enclosed in { } but refers to the variables set at the top of the code.

#room dimensions
room_x = 4 
room_y = 2
room_z = 2
#number of rays per calculation point
N=10000
#distance between calculation points
deltax = 0.1
deltay = 0.1
deltaz = 0.1
#number of points in each direction (to feed into cnt)
ptx = room_x/deltax
pty = room_y/deltay
ptz = room_z/deltaz

os.system(f"cnt {ptx} {pty} {ptz} {N} | rcalc -of -e 'Dz=1-2*($1+rand(.77-.61*recno))/'{N} \
    -e 'phi=2*PI*($1+rand(-.10+.39*recno))'/{N} \
    -e 'rxy=sqrt(1-Dz*Dz);Dx=rxy*cos(phi);Dy=rxy*sin(phi)' \
    -e '$1=$1*{deltax}+0.5*{deltax}; $2=$2*{deltay}+0.5*{deltay};$3=$3*{deltaz}+0.5*{deltaz};$4=Dx;$5=Dy;$6=Dz' \
    | rtrace -n 10 -ff -ab 8 -aa 0.5 -h -oov scene.oct \
    | total -if6 -{N} -m \
    | rcalc -e '$1=$1;$2=$2;$3=$3;$4=179*4*PI*(.265*$4+.670*$5+.065*$6)'> output/multitest.dat")

Any thoughts why I get the 10 decimals, with odd figures?

What you’re seeing is floating point imprecision. A number like 0.05 doesn’t have an exact representation in binary, just like 2/3 doesn’t have an exact representation in decimal (it’s either 0.66666 or 0.66667). So when your program prints out the value, it has the rounding error at the end.

Thanks for the quick response! That’s a direction I would not have thought about… Happy to hear there wasn’t an error in the code itself :slight_smile:

Having said that, I was wondering why the original code used binary input as I think it would/should also work with regular in/output, correct? My guess was it probably had a speed implication and (as I’m still testing the code) left it in for now.

Yup, you get about 7 significant digits with the -of 32-bit float representation. If you switched to -od you would see a slight difference in calculation time, but much greater accuracy, not that it matters in the end. Using text i/o is much slower, as conversion between floating point and ASCII is very time-consuming.

Thanks once more for the clarifying remarks and support!

I did a quick test with -od instead of -of throughout the code (missed one and got some quite odd results at first :slight_smile: ) and it resultated indeed in a small increase in time, but did result in the needed rounding (at least, looking at the data in python). If at some point I run into this issue again I might just round the values to 2 digits behind the comma which should also solve this issue! But for now, the -od solved it!