Feature #554

Compare two variables in custom symbol conditional statements

Added by Kristof over 3 years ago. Updated over 3 years ago.

Status:ClosedStart date:2014-05-06
Priority:NormalDue date:
Assignee:Paul% Done:

0%

Category:-
Target version:Candidate for next minor release
Platform:

Description

Dear Devs,

I could make good use of a possibility to compare two variables in a custom symbol.

Currently the conditional statement is limited to comparing a var to a constant es described in http://gmt.soest.hawaii.edu/doc/latest/GMT_Docs.html#conditional-statements

This works:

if $1 >= 130 then {

this doesn't:

if $1 >= $2 then {

I would appreciate it if case 2 would work as well.

All the best,
Kristof

degsymbol_5_2.sh Magnifier - simplified test script (636 Bytes) Kristof, 2014-05-07 10:28

degsymbol_testcase.ps - Result of degsymbol_5_2.sh (39.6 KB) Remko, 2014-05-08 03:28

Associated revisions

Revision 13120
Added by Remko over 3 years ago

Fix bug in treatment of variable text introduced when fixing issue #553.
This fixes issue #554.

Revision 13121
Added by Remko over 3 years ago

Fix treatment of variable text in custom symbol. Fixes issue #554.

History

#1 Updated by Paul over 3 years ago

  • Status changed from New to In Progress
  • Assignee set to Paul
  • Target version set to Candidate for next minor release

Turns out this ought to be very simple, so I implemented it in the 5.2 branch, r13112. I have not yet had time to test it though. You could either build the 5.2 branch and test it or send me a script that does such a test and I could check it here.

#2 Updated by Remko over 3 years ago

Should we allow to also have the first in the comparison to be a constant?

Example

if 10 > $1 then

That would make it entirely generic. If needed, I'm available to implement that.

#3 Updated by Remko over 3 years ago

  • Status changed from In Progress to Resolved

Done. The comparison statements can now have variables or constants on both sides of the operator. See r13115 in the 5.2 branch.

#4 Updated by Kristof over 3 years ago

Hi Paul and Remko,

I built the 5.2 branch r13117 and ran first the original script but it crashed under Version 5.2.0_r13117 [64-bit]. I wrote a simplified test script (see attached) but it crashed as well:

$ ./degsymbol_5_2.sh
ERROR: Caught signal number 11 (Segmentation fault) at
/opt/gmt-5.2.0-13117/bin/../lib/libgmt.so.5(gmt_format_symbol_string+0x336)[0x7f017f345c16]
[0x0]
Stack backtrace:
/opt/gmt-5.2.0-13117/bin/../lib/libgmt.so.5(sig_handler+0x137)[0x7f017f23b3b7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f017efe3cb0]
/opt/gmt-5.2.0-13117/bin/../lib/libgmt.so.5(gmt_format_symbol_string+0x336)[0x7f017f345c16]
/opt/gmt-5.2.0-13117/bin/../lib/libgmt.so.5(GMT_draw_custom_symbol+0x109)[0x7f017f345fb9]
/opt/gmt-5.2.0-13117/bin/../lib/libgmt.so.5(GMT_psxy+0x2b2f)[0x7f017f476a8f]
/opt/gmt-5.2.0-13117/bin/../lib/libgmt.so.5(GMT_Call_Module+0x179)[0x7f017f23ef69]
psxy(main+0x1c1)[0x400cf1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f017ec3576d]
psxy[0x4011b5]
$

Cheers,
Kristof

EDIT: typo corrected

#5 Updated by Remko over 3 years ago

  • Status changed from Resolved to In Progress

Thanks, Kristof, for the feedback and the script.

If Paul does not have time, I can look at it tomorrow. May simply be something to do with reading strings from internal memory. I think there was already something wrong in r13112 that I tried to fix.

#6 Updated by Remko over 3 years ago

I fixed the bug, which had nothing to do with the new conditionals with two variables but it was introduced in the fix for issue #553.
So this bug also affected the 5.1 SVN version, not only 5.2.
The fix is in r13120 for 5.1 (which does not include the conditional testing on two variables)
The fix is also made in r13121 for 5.2 (which does include the conditional testing on two variables).
Attached the result of your test script.

#7 Updated by Kristof over 3 years ago

Hi Remko,

thank you for your work. I didn't update to r13121 so far but had a look at the result you attached to your last post.

The values which are plotted in the chart are not the one I expected. In my understanding those numbers should be 120, 130 and 140 (third column from input file → $1), not 47.24..., 51.18... and 55.11... as in your attached Postscript file. I don't have an explanation for the values in your result at the moment.

Cheers,
Kristof

#8 Updated by Paul over 3 years ago

When I run the example with the latest 5.2 I get what you expect: 120 in red and 130, 140 in black.

#9 Updated by Remko over 3 years ago

  • Status changed from Resolved to In Progress

The ratios between what I got (47.24..., 51.18... and 55.11...) and what it was supposed to be (120, 130, 140) is the ubiquitous factor 2.54! (an inch in cm).
Because I have my default length unit as "c" and Paul probably "i" that makes it work for him but not for me.

What I suspect is that the third input column is somehow seen as a length unit and this conversion is done without me asking for it. We had things like that in the past.
I'll switch it back again to In Progress and let Paul figure this one out.

Meanwhile Kristof can work around it by adding --PROJ_LENGTH_UNIT=i to the psxy call. That worked for me.

#10 Updated by Paul over 3 years ago

Weird, I have
PROJ_LENGTH_UNIT = cm
in my gmt.conf in that directory.
Changing it to inch gives the same plot as for cm.
Anyway, there is an assignment in psxy to say that some args are dimensions and not angles, etc. I just wish I could reproduce your problem....

#11 Updated by Paul over 3 years ago

Code deals with this. I am completely unable to reproduce Remko's result. I've tried gmt.conf settings and --PROJ_LENGTH_UNIT=c but always get the right result. So not so easy to debug for me...

#12 Updated by Remko over 3 years ago

  • Status changed from In Progress to Resolved

I cannot reproduce my earlier result either I guess that's a good thing.
I ran the test script (which resulted in the attached PS file with the division by 2.54) before sucking in some edits from trunk that Paul made. Then I committed the joined code. Therefore, the fix may have been in Paul's edits between r13112 and r13120.
Anyway, I changed the status to Resolved. We at least have a trace of this when it pops up again. Very good use of the issue tracker!
If Kristof can confirm it all works to his expectations we can close this issue.

#13 Updated by Kristof over 3 years ago

It works as desired under Version 5.2.0_r13121 [64-bit] on my Linux box. No strange behavior observed. A big thank you from my side!

#14 Updated by Remko over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF