Closed mroughan closed 12 years ago
lamestllama
commented
12 years ago Have you got a set of parameters that can give this result ?
On 06/09/2012, at 11:40 AM, Matthew Roughan wrote:
Can return a (very small) negative number -- it should always be non-negative. This must be just a numerical error, but still we should fix
— Reply to this email directly or view it on GitHub.
mroughan
commented
12 years ago Easy, I just did it for [1,2], and calculated the PDF over the range of the support. I suspect the problem is at one end or the other, e.g., where g(t)=0, but the actual calculation has a numerical error.
It might be solved just by putting in a check, but I would rather know why the error occurs.
Cheers, Matt
On 06/09/12 11:54, Eric Parsonage wrote:
Have you got a set of parameters that can give this result ?
On 06/09/2012, at 11:40 AM, Matthew Roughan wrote:
Can return a (very small) negative number -- it should always be non-negative. This must be just a numerical error, but still we should fix
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/mroughan/LinePicking/issues/26#issuecomment-8320442.
lamestllama
commented
12 years ago I am going to look at that right now
On 06/09/2012, at 12:00 PM, Matthew Roughan wrote:
Easy, I just did it for [1,2], and calculated the PDF over the range of the support. I suspect the problem is at one end or the other, e.g., where g(t)=0, but the actual calculation has a numerical error.
It might be solved just by putting in a check, but I would rather know why the error occurs.
Cheers, Matt
On 06/09/12 11:54, Eric Parsonage wrote:
Have you got a set of parameters that can give this result ?
On 06/09/2012, at 11:40 AM, Matthew Roughan wrote:
Can return a (very small) negative number -- it should always be non-negative. This must be just a numerical error, but still we should fix
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/mroughan/LinePicking/issues/26#issuecomment-8320442.
— Reply to this email directly or view it on GitHub.
lamestllama
commented
12 years ago How did you specify the points you passed to it ? i.e. what was the increment you used ? I want to find the exact calculation that cause the problem
On 06/09/2012, at 12:00 PM, Matthew Roughan wrote:
Easy, I just did it for [1,2], and calculated the PDF over the range of the support. I suspect the problem is at one end or the other, e.g., where g(t)=0, but the actual calculation has a numerical error.
It might be solved just by putting in a check, but I would rather know why the error occurs.
Cheers, Matt
On 06/09/12 11:54, Eric Parsonage wrote:
Have you got a set of parameters that can give this result ?
On 06/09/2012, at 11:40 AM, Matthew Roughan wrote:
Can return a (very small) negative number -- it should always be non-negative. This must be just a numerical error, but still we should fix
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/mroughan/LinePicking/issues/26#issuecomment-8320442.
— Reply to this email directly or view it on GitHub.
mroughan
commented
12 years ago It happens for a few of them, but only for very specific parameters, usually right at the upper end of the support, and only for parameters that aren't pretty.
e.g. for the prism geodesic. LinePickingPDF(1, 8, [2,1]/sqrt(b^2+(a/2)^2))
lamestllama
commented
12 years ago Matt,
I have looked at these they are all errors caused by floating point representations.
so here is part of the calculation in the prism geometric
j2 = (-2 * w) / L2
j2 =
-2.124999999999999
j3 = ( 4 * w * sqrt(w2 - L2)) / (L2 * P)
j3 =
2.124999999999975
here w = sqrt(L2 + (P/2)^2)
so j2 = -2 sqrt(L2 + (P/2)^2) / L2
and j3 = ( 4 * sqrt(L2 + (P/2)^2) * sqrt(L2 + (P/2)^2 - L2)) / (L2 * P) = ( 4 * sqrt(L2 + (P/2)^2) * (P/2) ) / (L2 * P) = ( 2 * sqrt(L2 + (P/2)^2) ) ) / L2 = j2
same result in C as in matlab whilst these two won't cancel out we are in trouble I have rearranged the calculation and halved the error.
Do you want to resort to making negative values 0 ?
On 06/09/2012, at 4:51 PM, Matthew Roughan wrote:
It happens for a few of them, but only for very specific parameters, usually right at the upper end of the support, and only for parameters that aren't pretty.
e.g. for the prism geodesic. LinePickingPDF(1, 8, [2,1]/sqrt(b^2+(a/2)^2))
— Reply to this email directly or view it on GitHub.
mroughan
commented
12 years ago I think we do have to truncate negative values -- returning negatives for a PDF is obviously wrong, but the best way to do it might be to truncate v.small values, say less than 10^-12 or so, and flag some kind of error if they are more negative than this?
Cheers, Matt
On 06/09/12 21:25, Eric Parsonage wrote:
Matt,
I have looked at these they are all errors caused by floating point representations.
so here is part of the calculation in the prism geometric
j2 = (-2 * w) / L2
j2 =
-2.124999999999999
j3 = ( 4 * w * sqrt(w2 - L2)) / (L2 * P)
j3 =
2.124999999999975
here w = sqrt(L2 + (P/2)^2)
so j2 = -2 sqrt(L2 + (P/2)^2) / L2
and j3 = ( 4 * sqrt(L2 + (P/2)^2) * sqrt(L2 + (P/2)^2 - L2)) / (L2 * P) = ( 4 * sqrt(L2 + (P/2)^2) * (P/2) ) / (L2 * P) = ( 2 * sqrt(L2 + (P/2)^2) ) ) / L2 = j2
same result in C as in matlab whilst these two won't cancel out we are in trouble I have rearranged the calculation and halved the error.
Do you want to resort to making negative values 0 ?
On 06/09/2012, at 4:51 PM, Matthew Roughan wrote:
It happens for a few of them, but only for very specific parameters, usually right at the upper end of the support, and only for parameters that aren't pretty.
e.g. for the prism geodesic. LinePickingPDF(1, 8, [2,1]/sqrt(b^2+(a/2)^2))
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/mroughan/LinePicking/issues/26#issuecomment-8329873.
Can return a (very small) negative number -- it should always be non-negative. This must be just a numerical error, but still we should fix