Inline conversion from real(4) to real(8) when reading from file

[LarsJ]

Hi All

Not sure how to formulate this correctly, so hopefully the below code will explain.

I have two programs that internally uses real(8) precision, but when we store data on disk it is stored as real(4) to save space. When writing the file we can convert from real(8) to real(4) inline. Is there an equivalent way of doing this when reading?

Example code (not sure everything is correct, but to give you an idea):

Type T_MyType
real(8) :: Val
end type

type(T_MyType) :: MyType

!Write variables to file as single precision
subroutine WriteFile

open(10,file='MyFile.A10',access='sequential', form='unformatted',status='new')

write(10) SNGL(MyType%Val) !Store as single to save space on disk

close(10)

end subroutine WriteFile

!Read variables from file
Subroutine ReadFile

open(10,file='MyFile.A10',access='sequential', form='unformatted',status='old',action='read')

read(10) DBLE(MyType%val) !is there someway to do this?

!Equivalent solution
!read(10) tmpR4
!MyType%Val = DBLE(tmpR4)

close(10)
end subroutine ReadFile

Best regards

Lars

[mecej4]

The conversion from double to single precision real during write reduces the size of the output file, but there is an accompanying destruction of information, since a 24-bit mantissa replaces a 53-bit mantissa. Once discarded, those 29 bits cannot be recreated from nothing.

A second aspect of what you would like to do: an expression can occur as an element of an output list, just as a variable or a constant can. You cannot have an expression or a constant as an element of an input list (leaving aside implied DO loops in I/O lists).

You have shown how to handle the issue -- read into a temporary single precision variable, and then convert that variable to double precision.

Whether the lost precision is a serious loss or not may be worth more investigation before being accepted.

[LarsJ]

Hi mecej4

Thanks for the reply.

The loss of precision is not an issue (in this case). 

In our real case scenario we are reading several variables from file in the same record i.e. we require several temporary variables to do this conversion.

I was just hoping that there would be some "trick", that would make the code look nicer.

Best regards

Lars

[jimdempseyatthecove]

>>some "trick", that would make the code look nicer.

Why?

The readers of your code will be focused on the CALL ReadFile()

The internal details are immaterial.

And, you could make a generic read file subroutine

 Call ReadFileSPtoDP(iUnit, dpArray)

Jim Dempsey

[mecej4]

Re: "The loss of precision is not an issue (in this case). " I am afraid it is, because the internal representations of single and double precision numbers differ in the mantissa field as well as in the biased exponent field.

For instance, it it tempting to think that the single precision decimal number 0.1000000 is just the leading part of the double precision decimal number 0.1000000000000000. The IEEE754 internal representations, expressed in hex, are in fact quite different: Z'3DCCCCCD' for single precision and Z'3FB999999999999A' for double precision.

[JohnNichols]

@mecej4 is really correct.  Downsizing is not a great idea, the better idea is -- buy some hard drives.  

If you use the GPS data as an example, the X and Y coordinates have a certain accuracy, so if they represent a single point on the ground that is not moving more than thermal movement, then the accuracy requires one of two techniques to get a "known" position.   RTKLIB which then runs into further precision errors, especially in remote locations, far northern Iowa for instance. Or you use the Central Limit Theorem and then you run into how accurate do you want to be and how much data must be sacrificed for the accuracy.   

GPS you can get to 1/10000th of a foot, but you use a lot of data and it takes a lot of time.  

Numerical analysis, fundamental theorem - never sacrifice quality of numbers. 

Humans rarely care about precision till it bites. 

[LarsJ]

Hi All

Perhaps I did not formulate this correctly. Loss of accuracy when converting from double to single is not causing a problem in our use case (I did not mean to say it does not happen).

Best regards

Lars