I got a Float64 number from the p-value of a GLM model. I could NOT show the fitted model with the following error:
ERROR: p-values must be in [0; 1]
 error(::String) at ./error.jl:33
 StatsBase.PValue(::Float64) at /Users/Thomas/.julia/packages/StatsBase/EA8Mh/src/statmodels.jl:430
after some investigations, I found that some p-value floats are strange:
julia> p = (GLM.coeftable(mod).cols) # mod is a model from GLM.lmI()
julia> p == 0
julia> p >= 0
julia> 1 >= p >= 0
julia> 0 <= p <= 1 # strange !!!
julia> p == 0.0 # strange !!!
in particular, that strange false from 0 <= p <= 1 is the cause of the error messages inside StatsBase.PValue().
I don’t know if it’s a bug from GLM or a more general and subtle bug in Julia? I’m using v1.5.3, thanks.
This is so far from reasonable that you don’t need to worry about the M. Any complete and working example which can reliably reproduce the output from your first message at the end would be good enough.
Pretty much the only ways to explain those results are:
It’s not actually the same p everywhere.
Someone has committed an absolutely heinous act of type piracy and redefined floating point comparisons.
is it possible for me to save the data as a file and attach here?
it IS the same p everywhere. That’s why it’s “strange”.
I saved the design matrix X and response vector y into a .jld (by using JLD).
Then in a fresh session I loaded them and called mod = GLM.lm(X, y, true); and now the problem has gone?! that means I could not reproduce the bug by uploading the data…
now I know the cause of the problem: --math-mode=fast
I understand that any operation on NaN is unpredictable in fastmath mode, we need an important exception: isnan(NaN).
now in fastmath mode:
and this failure to detect NaN is the cause of all confusions. In this case, the following isnan(v) fails to catch the NaN and throws an error:
struct PValue <: Real
0 <= v <= 1 || isnan(v) || error("p-values must be in [0; 1]")
we often have no control whether a package would produce NaN, and on the other hand, the package has no control if the user is doing fastmath or not. I strongly recommend that isnan(NaN) to return true even in fastmath mode!
Next thing you will get some other error somewhere else because of another assumption of IEEE math in another package. It’s just completely unsafe to use this globally for running code you do not control 100% yourself.