To be honest the comment by the guy who talks about the JSON representation is just... well.
The numbers there are just what stringification of floats looks like. Consider the value in the middle <something>e-16, which is just 0. Or rather supposed to be. If the JSON conversion were done by Nim, I'd say this is related to these issues: [https://github.com/nim-lang/nim/issues?q=is%3Aissue+float+round+trip](https://github.com/nim-lang/nim/issues?q=is%3Aissue+float+round+trip) But from what I understand it's done by GR internally. Either the code of the C example in your issue happens to result in "nicer" numbers (which as strings are 2 - some epsilon) or there's some stuff involved that automatically makes the floats "nice" strings, which for some reason isn't triggered in your code. In any case though, the determination of the axes sizes should allow for some epsilon above some "nice" tick value and just cut off from there, precisely for this reason. And this should (if you have to use a JSON representation internally..) not rely on the stringification of floats to produce "nice" numbers. ggplotnim still doesn't handle this either though. I've thought about it quite a few times, but so far have been too lazy to handle this correctly without throwing out information in cases where some apparent epsilon is a "real value" etc. Also it's kinda funny that the data range calculation is confused by the offset in the numbers, but handles the 0 tick label correctly. I obviously don't know how they calculate their tick values exactly, but ggplotnim uses linspace internally and then you run into this exact issue again when determining the tick values and have to make sure you don't print the 0 tick label as 1e-16 something. Sorry, this was probably not that helpful. As far as I see your code looks fine (you should use the implicit result variable, set the size of result from the start and assign via result[i] = val! :) ).
