Is there any reason to have 1.0f/3.0f etc in resize.c?

[NicolasRobidoux]

... when it goes into a MagickRealType?

Wouldn't it just be better to not have floats, but simply doubles (0.0 instead of 0.0f, 1.0 instead of 1.0f, 1.0/3.0 instead of 1.0f/3.0f etc)?

[NicolasRobidoux]

Actually, you don't find 1.0f/3.0f, you find 1.f/3.f.

[NicolasRobidoux]

(Hopefully I understood what the code does: I am recovered FORTRAN programmer, so my structs ...)

[NicolasRobidoux]

More generally: Is there any reason to use floats in MagickRealType assignments?

E.g. value=1.0f in the Lagrange code.

[magick]

We typically default to doubles unless its part of an array where we can save space with single precision rather than double.

[anthony]

It is just the way I write it. The decimal point is the more important part, and the definition is in doubles. I suppose the 'f' is redundant. I will remove it.

The use of 1./3. is to implement the B,C value that is needed for make the CubicBC function
produce a Mitchell filter.

The only other unusual fractions is for Bessel, with the two numbers defining the support for a 3 lobed Bessel, and the size of the first lobe to use if you want to use Bessel as a windowing function,
specifically to generate a Bessel windowed Bessel or a cylindrical Lanczos

Basically that table maps filter names to actual function calls (weighted or window) defining the attributes of that function as a weighting function (support), windowing function (range to use for windowing purposes, typically 1.0), and the secondary arguments needed by some functions (B,C values for CubicBC).

That last however could be expanded to also provide other variables to functions, such as the pre-calculation of constants specific to that function definition.