Mon 14 Dec 2015 12:45:26 PM UTC, comment #11:
Confirmed, it works, thanks for pushing !
Usually devs just copy/paste the "from" field of the corresponding mail. No need for an upper case first letter. But really never mind this time. It's just a pseudo anyway :-)
|
Sun 13 Dec 2015 10:43:00 PM UTC, comment #10:
I pushed the changeset. My apologies, after pushing I noticed I misspelled your alias.
Once the fix is confirmed, this can be closed.
|
Sun 13 Dec 2015 08:19:09 PM UTC, comment #9:
@ederag
I'm ready to push this one. If you'll provide us your full name, I'll have it committed in your name.
|
Sat 07 Nov 2015 03:40:44 PM UTC, comment #8:
I also think that your patch should be applied.
@devs: please review (and push) the patch in comment #3.
@edarag: in comment #6 it should be "Yes, you are right"
|
Sat 07 Nov 2015 01:11:48 PM UTC, comment #7:
i do agree that setting ticks together with the right format at once would be better.
But this is not a trivial change, given the current code structure.
I would vote to keep my minimal change (in comment #3), that does fix the bug.
|
Sat 07 Nov 2015 11:29:59 AM UTC, comment #6:
Yes, I are right, my mistake.
set(h, "YTickLabel", []);
should be translated for gnuplot toolkit to
set ytics format ""
This will keep the tick marks, with empty labels.
But... such change will require to set again the format in every
tics change
|
Fri 06 Nov 2015 05:01:58 PM UTC, comment #5:
Thanks for taking time to explain better the origin of the bug.
But "unset ytics" would remove tics altogether, wouldn't it ?
We do want ticks, just without tick labels.
So just "unset ytics", without a new "set ytics ..." would'nt be enough. Am I missing something ?
|
Thu 05 Nov 2015 09:43:06 PM UTC, comment #4:
Checking the gnuplot file generated by Octave shows that the origin of the spurious tick label is the first command that puts the labels in places
7.000000000000001e-001, 7.500000000000000e-001, 8.000000000000000e-001, 8.500000000000001e-001, 9.000000000000000e-001, 9.500000000000001e-001
and the second lines puts the empty ticks in the correct places,
but since 7.000000000000001e-001 is not 7.000000000000000e-001,
this label is not erased.
The change of format from %.15e to %.15g fix thised,
but I think that another fix is needed: in the case of
set(h, "YTickLabel", []);
there should be "unset ytics" instead of setting a lot of empty ticks.
|
Tue 03 Nov 2015 02:10:11 AM UTC, comment #3:
Actually "%g" lacks precision:
Please find attached a better patch, using %.15g
(file #35370)
|
Mon 02 Nov 2015 08:27:58 PM UTC, comment #2:
And the patch.
There are other %.15e left. If there are other slight mismatches, they could be worth investigating.
(file #35369)
|
Mon 02 Nov 2015 08:19:45 PM UTC, comment #1:
Here is the wrong output
(file #35368)
|
Mon 02 Nov 2015 08:02:35 PM UTC, original submission:
When setting ticks and removing tick labels, sometimes there are spurious tick labels left, for instance:
This has been tested with octave dev, changeset 20679:7ae6bbf0a567
To be precise, my patches given in
https://savannah.gnu.org/bugs/?46292#comment10
have been applied, but they should not interfere with this one.
The patch is following, as soon as I have the bug number.
|