> It's hard for the decode routine to discover that a number of
> excessive size has been provided, because to do so you have to decode
> the number!
That's why I called it a feature. In some sense the value is beyond the
single-precision range, and so minus infinity is reasonable.
> a smaller range than double (i.e. as well as lower precision). What's
> more, I would guess that chr_ctor calls chr_ctod, so picks up the OK
> status and then gets the overflow when the conversion to real takes place.
No; it simply uses an internal READ statement with format BN,G<count>.0,
where count is the length of the string.
> The cure is for the application to arrange its units so it never goes
> outside say 1E+/-38.
I'd recommend using the PRM_PAR ranges. Alan will still have to parse
the string to some extent to extract the exponent before converting.
> text = "-0.15732190062648830795+164"
>
> is OK, with no D or E preceding the exponent. (Nor did I know that the
> Fortran compilers supported strings delimited by double quotes.)
The missing D or E was my first thought. How is *that* going to work?
Yet looking down at the results, the CHR_CTOD produces a sensible
result.
Malcolm
|