Chord length test

[nukenukenukelol]

We find the expected chord length by calculating t2-t1 from the initialization phase. We also add an accumulator to keep track of the total time we spend on traversal. Right now, Different inputs result in fluctuations of the accumulator compares to the expected chord length. The problem might lie in failing to properly print out acc.

[cgyurgyik]

I added Matt to get his input. This will be even more necessary in the 3d case where visualizing ray traversal through spherical coordinates is very difficult.

[cgyurgyik]

We find the expected chord length by calculating t2-t1 from the initialization phase. We also add an accumulator to keep track of the total time we spend on traversal. Right now, Different inputs result in fluctuations of the accumulator compares to the expected chord length. The problem might lie in failing to properly print out acc.

Can you clarify what you mean by different inputs result in fluctuations of the accumulators? How much does it fluctuate? Is the fluctuation correlated to the # of traversals, or worsened by radial vs angular hit?

Also, what do you mean by failing to properly print out acc.?

[nukenukenukelol]

We find the expected chord length by calculating t2-t1 from the initialization phase. We also add an accumulator to keep track of the total time we spend on traversal. Right now, Different inputs result in fluctuations of the accumulator compares to the expected chord length. The problem might lie in failing to properly print out acc.

Can you clarify what you mean by different inputs result in fluctuations of the accumulators? How much does it fluctuate? Is the fluctuation correlated to the # of traversals, or worsened by radial vs angular hit?

Also, what do you mean by failing to properly print out acc.?

Fluctuations mean sometimes near the end the acc is bigger than expected. Sometimes, near the end acc is smaller than expected. The way of displaying acc is to print out the value during each while loop iteration. I do notice that near the end of while loop iterations, some acc value isn't printed out. So I was thinking the "fluctuation" for the acc value could be that the acc actually reach the target, but we just fail to print it out. I apologize for not being clear enough.

[cgyurgyik]

We find the expected chord length by calculating t2-t1 from the initialization phase. We also add an accumulator to keep track of the total time we spend on traversal. Right now, Different inputs result in fluctuations of the accumulator compares to the expected chord length. The problem might lie in failing to properly print out acc.

Can you clarify what you mean by different inputs result in fluctuations of the accumulators? How much does it fluctuate? Is the fluctuation correlated to the # of traversals, or worsened by radial vs angular hit? Also, what do you mean by failing to properly print out acc.?

Fluctuations mean sometimes near the end the acc is bigger than expected. Sometimes, near the end acc is smaller than expected. The way of displaying acc is to print out the value during each while loop iteration. I do notice that near the end of while loop iterations, some acc value isn't printed out. So I was thinking the "fluctuation" for the acc value could be that the acc actually reach the target, but we just fail to print it out. I apologize for not being clear enough.

Ok can you dig a little deeper and see why this occurring? Maybe try setting tMaxTheta to inf (and similar to tMaxR) and see if its worse with one case than another. I'm not sure how much error the fluctuation is, so its hard to help here. If its something like 10e-10, then its probably just floating point error. If its bigger, then we need to try and find out why.

We'll want to write tests as well using chord length, so making a generalized testing function for chord length comparison will help us a lot as well.

[ak-2485]

Quick note, sorry to take so long. When you use t2 and t1 from the init phase of the alg., you are using the full chord length of the ray (time of the ray on the grid). Most of our test cases have the ray starting outside of the grid or inside of the grid; that means the values you are measuring will be either greater than or less than the actual chord length of the ray on the grid. So, include a conditional. For the case when the ray starts inside the grid, use t_begin - t2 as the baseline comparison. For the case when the ray starts outside the grid, t2 - t1 is fine.

[nukenukenukelol]

My reading of this is that it's correct. Do we have a verification setup, to compute what the expected chord length should be? I don't currently see that. The simplest case would be if your ray passes through the origin, it should be very close to 2*R.

So the t1 and t2 in the codes represent the entrance time and exit time for the ray to the grid. We calculated t1 and t2 in the initialization phase in order to find out if the ray intersects with the grid. I then just use t2 - t1 as the expected chord length. I also add the conditional statement just in case when the ray begins inside the grid (t_begin > t1).