Displaying 4 results from an estimated 4 matches for "qnan0".
Did you mean:
qnan
2018 May 28
2
to R Core T: mle function in 32bits not respecting the constrain
...R 32 bits it
fails. (same numbers, all equal!)
The call is:
*mle(minuslogl = p.est,start = beta,method =
"L-BFGS-B",lower=llim*reduction)*
lower = -0.01570427
The optimizer (optim function in 32 bits) display:
-0.015704 -loglik 48.690236
-0.015704 -loglik 48.690236
-0.017704 -loglik 1.#QNAN0
And it is not respecting the lower constrain.
Could anyone explain me why this? Maybe I am misunderstunding of lower
parameter meaning.
Is this because the 'lower' is for the estimate but not for the hessian
calculations internally? In such a case, why in 64 bits is different from
32 bit...
2002 May 14
2
NaN/NA and sprintf double format
...fine for NA:
> sprintf("%.2f", NA)
[1] "0.00"
> sprintf("%.2f", NaN)
[1] "-1.#J"
Not specifying the decimal precision lets both print garbage:
> sprintf("%f", NaN)
[1] "-1.#IND00"
> sprintf("%f", NA)
[1] "-1.#QNAN0"
Is this a bug or a feature?
Dirk
--
According to the latest figures, 43% of all signatures are totally worthless.
--
According to the latest figures, 43% of all signatures are totally worthless.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r...
2018 May 28
0
to R Core T: mle function in 32bits not respecting the constrain
...;
> The call is:
> *mle(minuslogl = p.est,start = beta,method =
> "L-BFGS-B",lower=llim*reduction)*
> lower = -0.01570427
>
> The optimizer (optim function in 32 bits) display:
> -0.015704 -loglik 48.690236
> -0.015704 -loglik 48.690236
> -0.017704 -loglik 1.#QNAN0
>
> And it is not respecting the lower constrain.
>
> Could anyone explain me why this?
FAQ 7.31 is a likely suspect.
You might need a `safe' lower bound. Perhaps, adding a small positive constant to it will fix it.
HTH,
Chuck
2002 May 16
0
Re: [R] NaN/NA and sprintf double format (PR#1561)
...rintf("%.2f", NaN)
> > [1] "-1.#J"
> >
> > Not specifying the decimal precision lets both print garbage:
> >
> > > sprintf("%f", NaN)
> > [1] "-1.#IND00"
> > > sprintf("%f", NA)
> > [1] "-1.#QNAN0"
> >
> > Is this a bug or a feature?
>
> Remember that NA is logical, so this is not correct usage. Not that the
> correct usage works very much better ....
>
> The C code says
>
> /* Simple wrapper for C sprintf function: does very little checking to
>...