I’m trying to figure out how to balance @tim.holy’s suggestion with putting the convenience constructors up front. I think you are getting at the underlying matter. Could you elaborate on how you think we might achieve that balance?
The working version of the index page now includes a convenience constructor example first, and then it breaks it down, including a mention of scale. Do you think I should explain more detail about regular and irregular grids on the index page or should that kind of detail be relegated to deeper sections.
Your excellent maintenance of this package is greatly appreciated!
One ambitious option might be to reconsider the design of the convenience constructors. There are a couple of things odd about them, for example:
The capitalization of LinearInterpolation is a bit non-traditional since there isn’t actually a type of that name
LinearInterpolation does not hint that it also sets a choice for extrapolation. Perhaps the default value for extrapolation_bc could be nothing, and in such cases it returns something without an extrapolation wrapper, e.g., a (scaled BSpline) interpolant for uniform grids. If the user chooses something besides nothing, then it could wrap in an extra extrapolation layer.
one might consider implementing LinearInterpolation(A) (or whatever new name it gets) to return just the plain (unscaled) BSplineInterpolation.
That might resolve the performance concerns while maintaining the ease of use, and at that point I don’t think I’d have any reservations about emphasizing the convenience constructors.
Hi, thanks for your work on this package. I use it every day =)
The new landing page is a lot better than the old one!
In addition to Paul’s suggestions, I’d add a small section where you ‘’[…]explain more detail about regular and irregular grids on the index page" and also explain scale.
I don’t understand what this means “Note: the current version of Interpolations supports interpolation evaluation using index calls , but this feature will be deprecated in future.”. Since it’s a holdover from an old version, maybe it’s time to drop this sentence.
I created a separate pull request to deprecate ConstantInterpolation, LinearInterpolation,
and CubicSplineInterpolation in favor of constant_interpolation, linear_interpolation, and cubic_spline_interpolation:
The graphs that show name-by-dim vs time-by-order are some hard to understand at a glance. Using the same font for the dim and the order may not be the best choice, even italicizing one would help. Also consider separating cells or rows or cols by thin yet visible lines (grey?).
I also do not know where the code to generate those graphs are at the moment, although I have a vague recollection of asking @tim.holy about it at one point. At the moment, those numbers are likely quite out of date. I would lean towards removing them in favor of focusing on benchmarks of Interpolations.jl itself.