I have been using IDL to read some ASCII output from a Fortran legacy code. It is a rather complicated format (i.e., not a simple multi-column file), so I had to write specific routines to do the job.
I am planning to use GDL now instead, but I've run into an annoying problem with my reading routines. The Fortran output contains numbers in scientific format, e.g., "1.500D-01" for 0.15. When read as strings, it was never a problem for IDL to directly translate that into a float or double number. However, now with GDL this does not work anymore, as GDL only recognizes scientific notation that uses "E" instead of "D" as in "1.500E-01".
Self-evidently, I could simply read the Fortran output and check for the occurrence of "D" and change it to "E". However, I'm reading very large chunks of data and this would simply take too long. Also, I'm afraid rewriting the Fortran code is not an option. Is there any trick to this that I might have overlooked?
I had a look at the GDL documentation and did some web searching, but couldn't find any remarks about this limitation anywhere. Therefore, this problem might potentially affect more people who relied on IDL's type conversion abilities.
could you please provide a (as small as possible) sub set of the data
(can be "fake") with the related sub set code to read it ?
We will gain time and being focused on the concrete problem.
PS: we cannot promise we can quickly solve this issue
but I have the feeling it is an important issue today.
PS: you can write me directly
PPS: a temporary work around would be to read back in IDL, generating
XDR output via SAVE in IDL, RESTORE in GDL (you must add your self the CMSV lib,
we can not put it in the GDL CVS tree du to licence issue) then test you code
and report any others problems (in the bug tracker !)
actually, it's not really necessary to give a snipped of the code or the data.
I'm sorry that I was not very specific when I said it didn't work with GDL.
The problem can be easily reproduced.
Simply try the following:
a = '1.500D-01'
b = 1.0*a
IDL will print: 0.15
GDL will print: 1.5
Try the same thing with '1.500E-1' will produce the right answer with both interpreters.
Hope that helps & thanks for your suggestions :)
By the way, I just discovered a nice work-around for the efficient conversion of multiple occurrences of the "D" format character to the "E" format character in a string. In the astrolib (the IDL Astronomy User's Library - http://idlastro.gsfc.nasa.gov/) there is a function called REPCHR which first converts the input string into a byte array and then performs a "where" search for the byte-representation of one character (e.g., "D"), changes all which were found to the byte value of another character (e.g., "E") and then converts the byte array back into a string.
Thanks for reporting it!
I'll work on it this weekend.
Fixed in the CVS:
GDL> a = '1.500D-01'
GDL> b = 1.0*a
GDL> print, b
i realized that the print procedure is missing date time formatting:
GDL> print, systime(/julian), format='(C())'
Format parser: Mismatched Token
% Format parser: Mismatched Token
% Execution halted at: $MAIN$
The same in IDL:
IDL> print, systime(/julian), format='(C())'
Tue Oct 02 10:07:33 2012
for a description of the data time format of idl see e.g.:
I'm encountering a similar problem. The a = '1.500D-01'; b = 0.15 issue is working properly if I define "a" within the body of the code.
However, if I try to read a simple 2 column file of:
with the commands:
The result is 1.5000000 and 1.6000000. Are there any work-arounds or alternatives to ReadF that would maintain the scientific notation?
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.