Possible improvement of hplot.Ticks{N: 10}

[rmadar]

On the example below, I show the default tick of gonum/v1/plot (left) and the output of hplot.Ticks{N: 10} command (right). While it seems to have the desired effect on the x-axis, it doesn't seem to be as nice for y-axis (int his particular example). If I understand correctly, N is supposed to be the maximum number of major ticks, and there is 0 major ticks on the right.

[sbinet]

do you have a somewhat simple reproducer I could play with?

[rmadar]

Yes, you can have a look at the test of https://github.com/rmadar/hplot-style .

To reproduce the problem, you just have to comment or not the line https://github.com/rmadar/hplot-style/blob/master/style/style.go#L58 and re-run the example.

[sbinet]

yeah, it seems David's algorithm is a tad less robust than gonum/plot's.

playing a bit with gonum/plot's ticker (but allowing to change the default N=3 suggested ticks, I came up with this:

compared to the one with David's:

and here's what your example plot would look like:

except for the pathological case of an interval [0,1.2] (row=7 in the gallery of ticks), I would say it's not too shabby.
would do you think?

[rmadar]

it seems David's algorithm is a tad less robust

Whaaat ??? ;-)

I think your proposal is really good! I was just wondering why the row 5 and 6 have the same ticks in your case while David's algorithm yields to different ticks (I am actually not sure what change from 1 row to another)

In any case, I would maybe propose to have a number formatting without decimals for raw 5 and 6 (if that's easy to do - I have no idea how these things work), i.e. 1000 instead of 1000.00.

Otherwise, it looks very good to me!

[sbinet]

Whaaat ??? ;-)

don't tell him I said that.

what does change from row-to-row (besides the xmin/xmax) is the number of required rows:

• hep/hplot/example_ticks_test.go

  Line 15 in d62708a

  func ExampleTicks() {

I was just wondering why the row 5 and 6 have the same ticks

oops, forgot to change back the requested number of ticks...
I tried a couple of hours to understand the 1000/1000.00 behaviour to no avail.
what could be done is to optionally provide a string as a format (if empty, the automatically picked one from the underlying mechanism would be used.)
e.g.:

type Ticks struct {
    N int
    Fmt string // e.g. "%8.2f"
}

[rmadar]

I like the idea of the formatting string to be more flexible. I think we can go for it and see in practice how (in)convenient this is. But I'd say it's a good move!