BUG: corrected bug in handling left-over samples in uneven double data

[jankoslavic]

This bug was discovered in the issue:
#107

The bug is in writing dataset 58 when the data is real, double precision, and unevenly spaced.

The UFF dataset 58 format supports 8 different cases depending on the combination of data type (real/complex), precision (single/double), and spacing (even/uneven). Each case has its own code path for formatting the numbers into lines.

When data is unevenly spaced, every x value has to be stored alongside its y value. So if you have 5 data points, the code interleaves them into a flat array of 10 values:

[x1, y1, x2, y2, x3, y3, x4, y4, x5, y5]

These are then written to the file 4 values per line, with alternating format specifiers — narrow for x (%13.5e) and wide for y (%20.11e):

x1 y1 x2 y2 ← line of 4
x3 y3 x4 y4 ← line of 4
x5 y5 ← leftover 2 values

The main lines of 4 are handled fine. The problem is with the leftover values. The code builds a list of format specifiers and tries to pick the right ones for however many leftover values there are:

fmt = ['%13.5e', '%20.11e', '%13.5e', '%20.11e']
fmt[rem_vals] # bug — gets one single item (e.g. fmt[2] = '%13.5e')
fmt[:rem_vals] # fix — gets a slice of the first rem_vals items (e.g. fmt[:2] = ['%13.5e', '%20.11e'])

With the bug, the format string has only one placeholder but there are two values to write, so Python throws a TypeError: not all arguments converted during string formatting.

This means the bug only triggers when there are leftover values, which happens when the number of data points is odd (odd * 2 = not divisible by 4). With an even number of data points, the leftover line is never reached and everything works fine.

Only this one case (real, double, uneven) has the bug. The other 7 cases handle leftovers differently — they use string repetition like rem_vals * '%20.11e' which naturally produces the right number of format specifiers. This case is the only one that uses a list with
mixed format specifiers (alternating between %13.5e and %20.11e), and that's where the indexing typo crept in.

The fix is one character: [ to [:].