My point was that if you use fortran conventions for the run length encoding, then you can get some help from the language for the conversions. Taking your data as an example:
real :: vals(6)=[-1.002, 1.01, -1.01, -1.02, 0.001, -0.001]
character(80) :: string
integer :: ivals(6)
ivals = nint(vals)
write(*,'(*(i0,1x))') ivals
string='-1 1 2*-1 2*0'
read(string,*) ivals
write(*,'(*(i0,1x))') ivals
write(string,*) ivals
write(*,'(a)') string
end
If you run this, you should get something like this output
$ gfortran ldio.F90 && a.out
-1 1 -1 -1 0 0
-1 1 -1 -1 0 0
-1 1 -1 -1 0 0
This shows that the run length encoded string expands the same way to the original integer vector, just using the internal read statement.
Unfortunately, my compiler (gfortran) does not produce that string when internal i/o is used, as is shown in the last line. So efficient run length encoding must be done manually. That’s not difficult to do, it just isn’t a single write statement.
The reason this came to mind is that back in the 1980s I wrote the f77 code that did this. Basically, I was duplicating list-directed i/o, but I had more control over the output format, including when repetition counts were used. F77 did not allow internal list-directed i/o, so that was the only option then. After f2003 (I think that was the change), I could replace half of my library code with just an internal list-directed read statement. Forming the compact string from the integer array still doesn’t work the right way, as seen above, so that part of the library code is still required.
This is not a bug with gfortran. It is allowed to add spaces and extra records and to ignore when repetition counts could be used. So if you want the compact encoded string, you still must do it yourself.