I sure do appreciate the time that you've spent analyzing the code.
(Addressing your suggestions)
1.)(a) you will not get rescued by your "goto Straight_Log"
The boat comes to rescue me in the if statement following the "goto Straight_Log" if statement. However, it sails away laughing. It only saves me most of the time. (epiphany came after reading part (c) of your suggestions)
(b) goto has you jumping out of the FINDRADIUS function, apparently never to come back
I've tried to modify an existing routine and somehow forgot that line. Thanks!
I will make changes to incorporate the Straight_Log function
(c) Referring to if yDiff2 and yDiff1 are BOTH tiny
You're correct that this if, then situation will not catch an error.
Hypothetically speaking the yDiff1=0.00015 will be acceptable, but the yDiff2=-0.00007 could give me problems. I ran some tests and with both yDiffs so close to zero the intersecting lines intersect in some far off distance of no importance to my analysis. Now abs(yDiff1-yDiff2)=0.00021 and 0.00021>.0002, which causes the code to miss the Straight_Log parameters. But the very next if (absYDiff1<=.00015) would catch the small yDiff1, throw (+ or -)20,000 into the slope, m1, and then find the slope for m2---------------I'm seeing your point :p (light bulbs ? ? ?)
You are sooo right, this will not be caught by goto statement, but will be caught by the first if yDiff1<=0.00015. It will pick 20,000 for the first slope, but calculate the slope as if everything were fine and dandy for the second slope. I can catch that with a nested if, (right again) :)
(d) make consts out of them
Will do.
2) m1 and m2 could both be zero if the z's are all equal
In this situation the z's will never be zero. This is in a scanning environment with everything based upon movement. As the data is scanned it is set up to take a measurement around every three inches. Even if production stops, the scanners will wait untill movement resumes to take a measurement to ensure that no z's are the same. (ie: the measurements taken will only be recorded as the z increases incrementally b/c it's motion based scaning)
even if m1 and m2 are not both zero, they might still be equal, so your Zradius formula could end up dividing by zero
I probably need a check for this!
Theoretically if the m1 and m2 are equal this should have been caught by the straight log scenario. The m1 and m2 being equal should only occur if the data is straight or, mathematically, has a constant slope along the interval. In this scenario, since the delta z's can never be zero, it would indicate that the yDiff1=yDiff2 (approximately). Again, theoretically, this should have been caught by the first If statement, if (abs(yDiff1-yDiff2)<=0.0002). But your right too many theoretical webs weave trouble or potential trouble!
3) I'll check it out!
Problem
with this is that the DLL currently fitting data through process of polynomial regression doesn't provide coefficients of the equation. So f' and f'' had to be skirted for now. I recently found one that yields coeff's and am considering making some changes in the near future to make things somewhat more readable to an outside coder. I might just write my own if I get brave.
Have you ever messed around with a Vadermonde Matrix?
Have a great day! Hope you get to read my response so you'll know how much I appreciate your time!