gmtmath does not handle -C when files are given
|Target version:||Candidate for next bugfix release|
Consider this example:
echo 1 2 3 4 | gmtmath -C3 STDIN 1 ADD = 1 2 3 5but:
echo 1 2 3 4 | gmtmath -C3 1 STDIN ADD = 0 0 0 5
#2 Updated by Paul over 4 years ago
Let us first determine what the result should be. With -C3 we are saying that any operation should only affect column 3 (the last one). The stack is initialized to all zeros. Placing a file (or STDIN) on the stack is modulated by -C3 so that only the value 4 is actually put on the stack for column 3. Now we add 1, still just to column 3, and then we are done (=). Hence [0 0 0 5] is the correct answer. So to me the bug lies in the first case where -C3 seems to be ignored when the file is placed but honored when 1 is added. I argue that both examples should output [0 0 0 5]. Comments?
#3 Updated by Joaquim over 4 years ago
I would be surprised if the [0 0 0 5] was considered the correct result (and that independently of the implementation arguments). Actually this issue is not specific to STDIN as it happens equally with files.
echo 1 2 3 4 > lixo.dat
gmtmath -C3 1 lixo.dat ADD =
0 0 0 5
gmtmath -C3 lixo.dat 1 ADD =
1 2 3 5
I certainly would not like to see the contents of my file, in columns other than specified by -C, to be modified at all.
#4 Updated by Paul over 4 years ago
I already pointed out that it has nothing to do with STDIN.
Not sure what you mean though: First you seem to say that [0 0 0 5] should not be correct, but your last sentence seems to imply you only want the content of the file to be modified as specified by -C; at least that is how I read you. The way I intended -C to work is to modify which columns are allowed to be changed by arguments and operators. A file is an argument and hence only those columns in the file that pass the -C modulator gets through. That seems consistent to me. Or are you arguing that -C should NOT affect files that are placed on the stack?
#5 Updated by Joaquim over 4 years ago
Sorry if I was not clear. I meant to say that if I was a user who read the manual (which pretty closely describes how this issue applies to me) and got the [0 0 0 5] result than I would surprised, as what I would expect would be the [1 2 3 5] answer. Otherwise what good would it do to me to have a series of columns filled with zeros?
(not sure what you meant in the last sentence of -C not affecting files in stack)
#6 Updated by Paul over 3 years ago
And a year went by...How can we resolve this. To me, when -C3 is issued, nothing should happen to any other column until another -C option is issued. That is the whole point of having -C. So that is why I consider
echo 1 2 3 4 | gmtmath -C3 STDIN 1 ADD = 1 2 3 5
a bug: Columns 0-2 are messed with; they should be prestine and remain at zero since -C was in effect.
#7 Updated by Paul over 3 years ago
Trying this again. Perhaps this makes it clearer: What you want is the output of
echo 1 2 3 4 | gmtmath STDIN -C3 1 ADD =
and what I want is the output of
echo 1 2 3 4 | gmtmath -C3 STDIN 1 ADD =
That is, you want to load all your columns from input (or file), then slam -C3 into effect and only add 1 to your last column. I on the other hand wish to exclude all but the last column from being placed on the stack in the first case. So in that case I want 0 0 0 5 on output and in your case you want 1 2 3 5.
So there is not a problem getting what you want; it is a problem getting what I want due to the bug.
#9 Updated by Paul about 3 years ago
- Status changed from In Progress to Resolved
- Assignee set to Paul
- % Done changed from 0 to 100
I have implemented a fix so that -C also affects placement of columns read from files. If no -C is in effect then the entire file, including time column, is placed on the stack, as before. However, when -C is in effect then only selected columns will be placed on stack. In r13352.
#10 Updated by Paul about 3 years ago
- Subject changed from gmtmath does not handle STDIN unless placed 1st on stack to gmtmath does not handle -C when files are given
- Target version set to Candidate for next bugfix release
Just changing the title to better match the actual issue. Now also fixed in GMT4 (r 10245).