The Transfer function

[GerritGroot]

Hi,

I've got a question about the transfer function. I'd like to transfer a two byte integer to a four byte integer using

FourByteInt=TRANSFER(TwoByteInt,FourByteInt)

The above integers are declared as:

INTEGER, PARAMETER :: I2B=SELECTED_INT_KIND(4)
INTEGER, PARAMETER :: I4B=SELECTED_INT_KIND(9)
INTEGER(KIND=I2B) :: TwoByteInt
INTEGER(KIND=I4B) :: FourByteInt

The two byte integer is read correctly from a binary file
opened as:

OPEN(UNIT=1,FILE='./INPUT/MyBinary.bin',ACCESS='DIRECT',FORM='BINARY',RECL=2,STATUS='OLD')
READ(1,REC=1)TwoByteInt

and has the value -99. However, when I use the above transfer statement: FourByteInt=4390813

"Maybe something with the sign bit," I thought at first and then I tried to change the sign in TwoByteInt from -99 to 99 and use the transfer function afterwards, but this gives: FourByteInt=4325475. (If I'd have to take the sign into account the transfer function wouldn't be useful anyway, so I suppose the transfer function works for negative values as well)

The binary file has been written on windows by a commercial code, so I suppose it's all little-endian, I'm working on XP myself and the value -99 is read correctly.

What am I doing wrong? How do I get FourByteInt=-99??

Thanks,

Gerrit

 

[mikrom]

Look at the positive number 99 and 4325475 in binary (Hex) representation

     99 Dec =      0063 Hex
4325475 Dec = 0042 0063 Hex

and look at the negative number -99 and 4390813 in binary (Hex) representation

    -99 Dec =      FF9D Hex
4390813 Dec = 0042 FF9D Hex

We can see that in the both cases there are some similarities - the both number have the 2 last bytes the same (0063 Hex or FF9D Hex) and the big numbers in 4 byte representation have in the first 2 bytes 0042 Hex.

I found here

http://gcc.gnu.org/onlinedocs/gfortran/TRANSFER.html

this about the TRANSFER function:
[highlight]
If the bitwise representation of the result is longer than that of SOURCE, then the leading bits of the result correspond to those of SOURCE and any trailing bits are filled arbitrarily.
[/highlight]
Maybe this is the problem, however I don't know why everytime 0042 Hex is filled "arbitrarily".

 

[GerritGroot]

Darn, I got a similar problem a long time ago and asked it on this forum as well. I found my own question back, the solution is to make an array of two two bytes or to use AND and OR logic.

http://www.tek-tips.com/viewthread.cfm?qid=1508674&page=10

Don't know how to treat negative numbers yet, but for positive numbers:

INTEGER(KIND=I2B), DIMENSION(2) :: TwoTimesTwoByteArray
INTEGER(KIND=I4B) :: FourByteInt

READ(1,REC=1)TwoTimesTwoByteArray(1)
!TwoTimesTwoByteArray(1)=-TwoTimesTwoByteArray(1)
TwoTimesTwoByteArray(2)=0
FourByteInt=TRANSFER(TwoTimesTwoByteArray,FourByteInt)

Works!

 

[xwb]

if (TwoTimeTwoByteArray(1) .lt. 0) then
   ! -ve number
   TwoTimesTwoByteArray(2) = z'FFFF'
else
   ! 0 or +ve number
   TwoTimesTwoByteArray(2) = 0
end if
FourByteInt=TRANSFER(TwoTimesTwoByteArray,FourByteInt)

As a 4 byte int, -99 is FFFFFF9D, +99 is 00000063. All you need to do is fill in the missing bits.

 

[GerritGroot]

Thanks,

Your solution is more elegant than mine. I checked whether the TwoByteArray was negative, changed it's sign, converted it and then changed again the sign of the transferred one, but this looks less clumsy.

Gerrit