On Fri, May 04, 2007 at 05:43:00PM -0500, Robert Kern wrote:
Stefan van der Walt wrote:
On Fri, May 04, 2007 at 09:44:02AM -0700, Christopher Barker wrote:
Example of the first line of my data file : 0.0 inf 13.9040914426 14.7406669444 inf 4.41783247603 inf inf 6.05071515635 inf inf inf 15.6925185021 inf inf inf inf inf inf inf I'm pretty sure fromfile() is using the standard C fscanf(). That means
Matthieu Brucher wrote: that whether in understands "inf" depends on the C lib. I'm guessing that the MS libc doesn't understand the same spelling of "inf" that the gcc one does. There may indeed be no literal for the IEEE Inf.
It would be interesting to see how Inf and NaN (vs. inf and nan) are interpreted under Windows.
I'm pretty sure that they are also rejected. "1.#INF" and "1.#QNAN" might be accepted though since that's what ftoa() gives for those quantities.
So, from some googling, here's the "special" strings for floats, as regular expressions. The case of the letters doesn't seem to matter. positive infinity: [+]?inf [+]?Infinity 1\.#INF negative infinity: -Inf -1.#INF -Infinity not a number: s?NaN[0-9]+ (The 's' is for signalling NaNs, the digits are for diagnostic information. See the decimal spec at http://www2.hursley.ibm.com/decimal/daconvs.html) -1\.#IND 1\.#QNAN (Windows quiet NaN?) There may be more. If we wish to support these, then writing our own parser for them is probably the only way. I'll do it, I just need a complete list of what we want to accept :-) On the other side of the coin, I'd argue the string representations of our float scalars should also be platform-agnostic (standardising on Inf and NaN would be best, I think). -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca