Menu
Logged-In As
ACCOUNTNot Logged In
Investigate and fix source of rounding errorBRL-CAD
Status: ClosedTime to complete:
120 hrs
Mentors: Sean
Investigate the source of rounding error in the new ray generator function, and resolve/explain the difference with the math that rt was previously performing. It may help to print the first 3 ray values and all intermediate steps that led up to their values for before and after comparisons, so any deviation can be pinpointed to minimal lines of code.
Submit a written report that explains the deviation and/or a patch that fixes the deviation.
Uploaded Work
| File name/URL | File size | Date submitted | |
|---|---|---|---|
| task-57-fix-rounding-error.diff | 8.6 KB | January 16 2015 06:47 UTC | |
| new-rt-perspective-rendering.log.gz | 11.4 MB | January 16 2015 06:54 UTC |
I would like to work on this task.
This task has been assigned to Andromeda Galaxy. You have 82 hours to complete this task, good luck!
The work on this task is ready to be reviewed.
Your patch contains more than 3 lines, i.e. is not trivial. That's why some lines with explanations would be useful.
One of the mentors has sent this task back for more work. Talk to the mentor(s) assigned to this task to satisfy the requirements needed to complete this task, submit your work again and mark the task as complete once you re-submit your work.
Much of this patch is still work from the earlier tasks to convert rt to using the bundle generation functions, since I generally try to base my patches off of a committed HEAD. The change from the previous patch is to the way that the perspective angle fed into rt_gen_frustum() is calculated; it has to be different from the original angle because of rt_gen_frustum()'s closed-set behavior (see comment in source file). The old method of calculating the new angle involved atan(tan(...)...), which resulted in highly inaccurate results since trig functions are not guaranteed to be particularly accurate; this change converts it to eliminate the inner tan() call, which makes the error acceptable to the current regression tests.
The work on this task is ready to be reviewed.
Congratulations, this task has been completed successfully.
This is very reassuring! Looking at the values, most are either identical, or matching within double-floating point precision (probably 1ulp off) at 15 digits after the decimal.
As this was an issue you had to investigate in detail, that implies a comment is warranted to document and warn others about the sensitivity issue. You do have a comment that says calculating the angle is complicated, but you don't explain what that means in lay terms. Basically, there needs to be some warning that says these calculations are sensitive to trigonometric accuracy so care must be taken to ensure calculated rays do not have or accumulate error.
Looking at the line counts, this does increase the counts by about 20 lines which is pretty minor and probably okay to commit now that the results are matching. However, the data remarshalling does make me think that returning an xrays list is not the best approach. in fact, ideally the _gen_ functions shouldn't be allocating memory dynamically too, giving the user the option of creating memory dynamic or on the stack and passing that in to be used.
That makes sense... As we discussed earlier, I'll submit some new apis for the gen_* functions as my work for https://www.google-melange.com/gci/task/view/google/gci2014/5256821832941568 (first version nearly completed).