I can't reproduce. All axis settings are automatic for me.

I'm able to reproduce, and it's the intended behaviour (which doesn't mean I like it). The rationale being for a set of values near to zero, make the axis stick to zero. Probably similar to what XL does.

Near to zero? THe values are 1.1 to 1.6, so 0 is about 180% of the range away...  

I still get 1 as minimum for the x axis. The y-axis starts from 0.

The code is in gog-axis.c, starting at line 631:

	/* pull to zero if its nearby (do not pull both directions to 0) */
	if (bound[GOG_AXIS_ELEM_MIN] > 0 &&
	    (bound[GOG_AXIS_ELEM_MIN] - 10. * step) < 0)
		bound[GOG_AXIS_ELEM_MIN] = 0;
	else if (bound[GOG_AXIS_ELEM_MAX] < 0 &&
	    (bound[GOG_AXIS_ELEM_MAX] + 10. * step) > 0)
		bound[GOG_AXIS_ELEM_MAX] = 0;

Adreas, feel free to ask the list about this issue.

Jean, I'm attaching a sample file that exhibits the same behaviour.

Created attachment 140020 [details]
Sample file

Created attachment 140038 [details]
screenshot

I still don't see the issue.

It is surprising how often map_linear_auto_bound is called when you open Emmanuel's sample file.

I see, we first make the bounds loose and then pull 0. (Jean if you are using a 64bit machine you may just not pull 0, on my 32 bit machine it is just in in range.)

before pulling zero to range is 
(gdb) p bound[GOG_AXIS_ELEM_MIN]
$11 = 1

to

(gdb) p bound[GOG_AXIS_ELEM_MAX]
$12 = 1.7000000000000002

with step 
(gdb) p step
$13 = 0.10000000000000001

Since 0 is within 10*step, if barely, it is pulled in.

Note that if we first had pulled 0 and then made it loose, we would have had a smaller range.

So clearly this is intended and I just stumbled onto an extreme situation.

Closing as NOTABUG.

I find a bit weird that a 32 bit machine and a 64 bit machine give different outputs. This might be considered a bug.

It might be interesting to know what you get for 
step = pow (10, go_fake_floor (log10 (range)));
in map_linear_auto_bound in gog-axis.c

I'm getting 0.10000000000000001

Interesting. If you trace through the next step, you shuold see why you are not pulling in 0. 

32-bit mode will often use the old x87 instructions with extra precision.
64-bit mode uses, AFAIK, 64-bit instructions with no extra precision.

Hence I am not surprised that we see differences.

Even on the same chip, there are numbers for which log produces different
results in 32-bit and 64-bit mode.

Maybe we should not use an integer like 10 for the pull-in-0 logic.
Doing so almost is asking for user-visible rounding issues.

How about 9.99?

Tha seem like a good idea

Fixed.

This might have broken the xls compatibility.

To maintai XL compatibility (if it is what we want, since I largely prefer starting the axis form 1. in such a case), I propose:

	if (bound[GOG_AXIS_ELEM_MIN] > 0 &&
	    (bound[GOG_AXIS_ELEM_MIN] - 10. * step) < DBL_EPSILON)
		bound[GOG_AXIS_ELEM_MIN] = 0;
	else if (bound[GOG_AXIS_ELEM_MAX] < 0 &&
	    (bound[GOG_AXIS_ELEM_MAX] + 10. * step) > -DBL_EPSILON)
		bound[GOG_AXIS_ELEM_MAX] = 0;

Do we have any reason to believe that a factor of 10.00 is required for XL compatibility. I suspect that the value 10.00 was just used because it seems to give the right answer in a bunch of cases. 9.99 would likely give similar answers.

I made a test with Emmanuel's sample: XL does have an x-axis starting from 0. With 9.99, our axis starts from 1.

Perhaps we should then just use 10.01 or something to that effect.

Or consider it is an XL bug and do not reproduce it.

We do not have XL compatibility for axes.  For date axes, for example, I
recently made us choose sane dates for ticks instead of round number-of-
days-since-1900.