ditch negative zero in ftest output

[palday]

closes #461.

I also updated some docstring tests so that they would pass. (cf. also #469)

[codecov-commenter]

Codecov Report

Base: 87.08% // Head: 87.09% // Increases project coverage by +0.01% 🎉

Coverage data is based on head (5b7defe) compared to base (7299d18).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #501      +/-   ##
==========================================
+ Coverage   87.08%   87.09%   +0.01%     
==========================================
  Files           7        7              
  Lines         929      930       +1     
==========================================
+ Hits          809      810       +1     
  Misses        120      120              

Impacted Files	Coverage Δ
src/ftest.jl	100.00% <100.00%> (ø)
src/GLM.jl	50.00% <0.00%> (-16.67%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[nalimilan]

Thanks. Just another though: maybe we should apply rounding only in show? The advantage is that we know we use 4 digits, so we can change -0.0000 to 0.0000 safely without applying an arbitrary threshold.

This wouldn't fix tests that check internal fields directly, but anyway if we only clamp small negative values to zero, we have to use isapprox with some tolerance to handle small positive values.

[palday]

Can do, but mathematically this is non-adjusted R2, so should be strictly non-negative. Negative zero is just a floating point issue.

[nalimilan]

Yes, I agree, but the choice of an arbitrary threshold is annoying, and it seems safer to just store whatever r2 returns to avoid hiding potential bugs in implementations.