Anova updates (added inverse student t, confidence calcs)

40 views
Skip to first unread message

theBrad

unread,
May 30, 2012, 2:52:12 PM5/30/12
to accor...@googlegroups.com
Awesome work btw. I've added the Inverse T distribution, modified the MultLinearRegression object to return the MS/SS,R calculations as part of the Coefficient calculation and redefined the Anova to match more of what users I've seen use it for (including confidence calcs) for both with and without Y intercept. The only setback I'm having in the RSquared Adjust for no Y intercept seems to be off. I've included my changes in case you'd like to include them. My Accord.Math.Tools may be modified so that the AForge link isnt necessary but I only added 2 functons (IsEquivalent for float and double) since equality doesn't apply to floating point.
 
Most of the users I deal with are used to Anova looking like the Excel addin's they use so that's the reason I created this anova style result object (w/confidence results)
 
Hope this is useful.
 
Thanks
Brad
 
changes-2.6.1.zip

theBrad

unread,
May 30, 2012, 3:28:20 PM5/30/12
to accor...@googlegroups.com
Actually the RSquared and RSquaredAdj should return NaN if the compuation is not valid...fixed that
 
MultipleLinearRegression.cs

César

unread,
May 30, 2012, 3:52:04 PM5/30/12
to accor...@googlegroups.com
Wow, this is amazing. Many thanks, Brad. I will be taking a look on the changes and see if they can be incorporated in the next release. 

I have some questions, though. I see you have created a MaxRealNumber constant representing the value of 1e300. In the original Cephes library, I believe this value was set to 1.7976931348623158E308, which is about the same as Double.MaxValue. Was there any specific reason for not using Double.MaxValue? (I still haven't tested it with Double.MaxValue instead, perhaps you have found something I am not currently aware, hence the question).

I also see you have replaced the equality comparisons on Moshier's code by "within tolerance" comparisons. I am aware that in most occasions floating-point numbers shouldn't be compared by equality, and I know why you did that. However, I also know that Moshier is very good on writing numeric precise code, and I couldn't find those checks on his code. Did you find a case in which those tolerance margins were indeed necessary? I am only asking so I can write some better suited unit tests for those.

Again, many thanks for your contribution!

Best regards,
César

theBrad

unread,
Jun 1, 2012, 1:11:35 PM6/1/12
to accor...@googlegroups.com
Hi  César,

Old C/C++ habits - but really the floating point spec doesn't support equivalence only >,<, and != (where != is always true). Sometimes compiler writers try to "help" by putting in hidden support for comparison of equality but I've been burnt too many times by it (gcc, intel, ms, CUDA, etc). Never know what to expect so I prefer to define it. You can compare two constants with very little issue in floating point but not necessarily computed values.

As for the 1e300, I think that might be a carry over from a port in C from years ago (I had this in C code) and knew it worked in that environment as is. Other than that, no good reason. At that large a value it's almost noise in the far end of the bits for the fractional part....

Feel free to test/update it. I thought this might be useful for others and glad to help out where I can
Brad

Reply all
Reply to author
Forward
0 new messages