code: public double toDouble()
    {
      if(m_length == 0)
        return Double.NaN;
      int i;
      char c;
      String valueString = fsb().getString(m_start,m_length);
      
      // The following are permitted in the Double.valueOf, but not by the XPath spec:
      // - a plus sign
      // - The use of e or E to indicate exponents
      // - trailing f, F, d, or D
      // See function comments; not sure if this is slower than actually doing the
      // conversion ourselves (as was before).
      
      for (i=0;i<m_length;i++)
        if (!XMLCharacterRecognizer.isWhiteSpace(valueString.charAt(i)))
          break;
      if (i == m_length) return Double.NaN;
      if (valueString.charAt(i) == '-')
        i++;
      for (;i<m_length;i++) {
        c = valueString.charAt(i);
        if (c != '.' && (c < '0' || c > '9'))
          break;
      }   	    	
      for (;i<m_length;i++)
        if (!XMLCharacterRecognizer.isWhiteSpace(valueString.charAt(i)))
          break;
      if (i != m_length)
        return Double.NaN;
      	
      try {
        return new Double(valueString).doubleValue();
      } catch (NumberFormatException nfe) {
        // This should catch double periods, empty strings.
        return Double.NaN;
      }
    }
docs: Convert a string to a double -- Allowed input is in fixed
  notation ddd.fff.
  
  %OPT% CHECK PERFORMANCE against generating a Java String and
  converting it to double. The advantage of running in native
  machine code -- perhaps even microcode, on some systems -- may
  more than make up for the cost of allocating and discarding the
  additional object. We need to benchmark this.
  
  %OPT% More importantly, we need to decide whether we _care_ about
  the performance of this operation. Does XString.toDouble constitute
  any measurable percentage of our typical runtime? I suspect not!
  
  @return A double value representation of the string, or return Double.NaN
  if the string can not be converted.