Added Contour plots with a test.

[alex404]

Here's my contour plot code. The bulk is the algorithm which actually generates the contours - the interface is relatively simple. I'll be open to improving it on request.

One outstanding issue is still that without any kind of line smoothing, it's hard to prevent the contours from having a blocky appearance. Over time this has bothered me less though, because the fact that standard contour plotting algorithms do apply line smoothing without informing the user is a bit disengenuous.

Anyway, maybe one day we'll get line smoothing into Chart.

[alex404]

Also note that since the algorithm depends on containers, so this would have to be a dependency in Chart.

[timbod7]

Thanks for the pull request. I wonder if this would be better as a utility function, rather than a new plot type? ie something like:

contourPlot
:: (Double,Double) -- ^ The range along the x axis.
-> (Double,Double) -- ^ The range along the y axis.
-> Int -- ^ The number of points to sample along the x axis.
-> Int -- ^ The number of points to sample along the y axis.
-> Int -- ^ The number of isolevels.
-> (Double -> Double -> Double) -- ^ The function to contour.
-> [LinePlot Double Double]  -- ^ One lineplot per isolevel

Also, in terms of smoothing, does this really need to be in the rendering layer? Without too much difficulty, the contour plot function above could dynamically adjust the xy point density in order
to get a desired degree of smoothness.

[alex404]

You're probably right about this being better as a utility function. As is, the contourplot is just a thin wrapper around LinePlot anyway. I'll set that up and push it when I have a chance.

As for the line smoothing, one can already set the density. So earlier I think the grid I sampled was 100x100, whereas this one

is 2000x2000. The problem is that whereas the first one generates in less then a second, this one takes more like a minute. In order to have a nice balance between appearance and performance, most contour plots in other libraries (as far as I can tell) sample some reasonable grid like 100x100, and then apply line smoothing to make things look better than they actually are.

Anyway, it's not critical, and maybe is even bad practice to use line smoothing like that.

[alex404]

Right, okay, so I finally got around to updating the contour plots in the manner discussed. Sorry that things are a bit out of sync now, but I don't think it's in significant ways. Let me know if you think any other changes are needed.

[alex404]

Okay, so I overcame my inertia and merged with the latest Chart. Please pull or let me know if I should do anything else.

[timbod7]

I'm about to go on holidays, but will merge this when I return.

[jagajaga]

Some updates? Seems to be good PR.

[alex404]

Just pinging for a pull. I'd be happy to make whatever other changes are necessary to get this accepted, but I'd like to stop maintaining a fork.

[timbod7]

Hi,

The reason that I haven't merged this is that I think the output would look
much better with some curve interpolation, as you suggested earlier. A few
months ago I saw this blog post:

http://phaazon.blogspot.com.au/2015/02/smoothie-haskell-library-for-creating.html

Is this something that could be used to get smoother output?

Tim

On Wed, Apr 29, 2015 at 11:42 PM, alex404 [email protected] wrote:

Just pinging for a pull. I'd be happy to make whatever other changes are
necessary to get this accepted, but I'd like to stop maintaining a fork.

—
Reply to this email directly or view it on GitHub
#47 (comment).

[alex404]

So that's half the solution, as far as I can see. 'smoothie' allows us to describe smooth curves, but not solve for them in the first place.

The only fully worked out tool for spline interpolation I've seen in haskell that would work in this case is provided by Diagrams:

https://hackage.haskell.org/package/diagrams-lib-1.3/docs/Diagrams-CubicSpline.html

Is that something we could make use of? Since Chart is meant to be backend agnostic, I'm guessing not...

[alex404]

Just a follow question: Is it conceivable that at some point 'Chart' would abandon the backend approach and just depend on diagrams?

[timbod7]

The diagrams backend is significantly slower than the cairo backend. I wouldn't want to switch to pure diagrams whilst that remains the case.

[alex404]

That makes sense.

I'm not quite sure how to proceed at the moment. I don't plan on trying to work out spline interpolation on my own in the near future.

I suppose another solution would be to stick this module into chart-diagrams, so that I can make use of the spline interpolation there. Or just expose this module in chart, and then write a little interface in chart-diagrams for handling interpolation of general line plots.

[alex404]

Hi Tim,

One comprise I came up with would be to completely remove the dependence of Contour.hs file on any Plot types and basically just leave it as a pure algorithm which returns a list [(Double,[Double])] where the first double is the contour level and the second is the line. My wrapping up the algorithm in plot types is fairly unnecessary.

I could even just push the think onto hackage as its own library, but since it's an oft requested feature it makes sense to me to keep them bundled up to an extent. With this approach at least, users will know that they're just running an algorithm to generate some values, and what they do with them is their decision.

[steinitznavican]

I assume this never got merged :( but perhaps someone could tell what the plan is?