Prev: active contour on ultrasound images
Next: separating overlaping field images from n number of images to create panormaic image mosaicing
From: Walter Roberson on 19 Apr 2010 11:14 Sebastien wrote: > I should write data in a specific format for a Fortran software. I know > that matlab could read this format, but i don't know how to write in > this specific format: > 5.D02 > matlab return 500 > > 6.25D-02 > matlab return 0.0625 > > My problem is that i want to do the inverse. > > I want to enter 0.0625 and matlab return 6.25D-02. You will have to write into a string and use string manipulations to change the E to D (or write your own format routine.) Although Matlab accepts D on input, it does not have any provision for writing it on output.
From: dpb on 19 Apr 2010 14:13
Sebastien wrote: > I should write data in a specific format for a Fortran software. I know > that matlab could read this format, but i don't know how to write in > this specific format: > 5.D02 .... > I want to enter 0.0625 and matlab return 6.25D-02. .... Others have addressed the lack of a specific double precision output formatting string in C (from which the Matlab fprintf() cometh) to generate the D w/o munging on a string and writing it. Another way if there is a lot of this to be done and it is mandatory (keep going for why it might be or then again, might not) would be to write a Fortran Mex file and use the Fortran i/o rtl to do it. Probably only worthwhile if there is a very, very, very large amount of this to do or its going to be a "forever" repetitive thing. The bottom line is, though, you may not have to have the "D" instead of "E" depending on the application of the output data your writing even if the current procedure is to use it. If it is to be read into a program using Standard Fortran i/o, on input the D is interpreted as an E if the variable is single precision and an E is as good as a D for a double precision variable. This is so for any conforming compiler since at least F77; I'm not positive w/o looking it up any longer whether it (D for dp) might have been required for earlier compilers. So, if it is for file input/output, if the application is with a compliant current (or even F77 which isn't very new any more :) ) compiler using standard i/o, it won't make any difference. The only places where I could see it being significant would be if there is some custom i/o routine that is scanning the input and parsing it that is sensitive to the D or that the data being generated are used internal to a Fortran source file (such as the aforementioned DATA statements) wherein a literal constant w/o the D is single precision, not double. Specifics of the the perceived need/application could confirm/deny above hypothesis. -- |