Double precision data in Fortran (where the E+- convention originated)
calls for D+- as the exponent key for floating point data.
The current parser will not handle standard Fortran output and
does not differentiate between double precision exponents and floating
point exponents.

The request is to have the Double.valueOf string parser recognize standard
data.

  According to the spec the definition is as follows.

       FloatValue:
               Signopt Digits . Digitsopt ExponentPartopt
               Signopt . Digits ExponentPartopt

       ExponentPart:
               ExponentIndicator SignedInteger

       ExponentIndicator: one of
               e E

       SignedInteger:
               Signopt Digits

       Sign: one of
               + -

  Which means that I was wrong about the leading zero, and it looks like it is the 'D'
  that is complaining about. The D really is only needed in a context free situation
  like a program source file. In your example the string will become a Double by virtue
  of the method being called. It might be a little ungenerous to complain about the D,
  but that looks like the way it is.

  Nik

  On Wed, 22 Oct 1997 18:51:17 -0700, you wrote:

  >Same thing...
  >
  >Error: java.lang.NumberFormatException: 0.00000000000000D+00
  >
  >Bummer.
  >
  >
  >
  >Nik Shaylor wrote:
  >
  >> On Wed, 22 Oct 1997 18:04:45 -0700, you wrote:
  >>
  >> >Java problems again..
  >> >
  >> >I get the following error on these parses:
  >> >
  >> > Error: java.lang.NumberFormatException: .00000000000000D+00
  >> >
  >> > X[I][J] = Double.valueOf(line.substring(1,20)).doubleValue();
  >> >
  >> > Y[I][J] =
  >> >Double.valueOf(line.substring(21,40)).doubleValue();
  >> >
  >> >
  >> >What is being done wrong?
  >>
  >> I'm guessing here, but I think it may be that this parse function requires a number
  >> as the first digit. It's not efficient, but you might try:
  >>
  >> X[I][J] = Double.valueOf("0"+line.substring(1,20)).doubleValue();
  >>
  >> etc.
  >>
  >> Nik.
  >
  >