Philippe Rivière

Yes, #47 was only about the "noFrame" sub-issue.

The algorithm in this PR (apply marching squares then smooth) doesn't seem to match the description in https://www.boristhebrave.com/2018/04/15/dual-contouring-tutorial/ ? Is this expected? Bilinear interpolation is addressed in https://github.com/d3/d3-contour/pull/46

[Here's an example](https://bl.ocks.org/mbostock/1b64ec067fcfc51e7471d944f51f1611) "in the wild" where drag.container is used, but it [can be removed](https://bl.ocks.org/Fil/b8025e91219af4538e28efb38d354639) with no ill effect.

I think it makes sense, but not sure that I fully grasp all the consequences or would know how to code this. If we want to do this, it would...

https://observablehq.com/@mbostock/streaming-csv

I'd love a review @enjalot ; in particular I'm making grandiose claims about having a shorter and more accurate code than the reference implementation so I must be wrong somehow...

I also have a trick to avoid divergence in https://github.com/d3/d3-ease/pull/29/files#diff-98bd2b6dedcb4fda72304031dbf8d928R24 "when we're moving too fast, slow down". I've used this trick a lot in the 2D Newton-Raphson solver in d3-geo.

Thanks! Yes, we should make a new push for all the outstanding features that have been waiting in pull-requests—some of them might be merged, others made available as notebooks or...

I've implemented a new function here https://observablehq.com/d/e7d4fef33e304f2b Compared to a reference implementation: we get the same speed, and, unless I'm mistaken, our results are more accurate for the limiting cases...

Respecting user-defined initial positions seems like the expected behavior. In fact, adding jitter to user-defined initial positions might cause problems in some cases (for example if you need all the...