[gdal-dev] gdal raster calc - a modulo operator (%)?

[Barry DeZonia]

I'm not sure what the operational definition of raster is. In my world
you can have a floating point raster (a grid of floating point values
instead of a grid of integer values). I might be wrong about that in
your context.

Interestingly the Java language specs are helpful:

See Section 15.17.3 Remainder Operator %

in this document:

https://docs.oracle.com/javase/specs/jls/se25/jls25.pdf


On Tue, Oct 7, 2025 at 4:47 PM Scott <public at postholer.com> wrote:
>
> Hey Barry,
>
> I can confirm there are a whole slew of issues I haven't begun to think
> through! ;)
>
> In context of a raster pixel, integers shouldn't be an issue. Can a
> raster pixel even have a NaN value? A nodata IS a value. I don't even
> know. Is this a chunk of code I'd encourage everyone to use? Definitely not.
>
> Scott
>
> On 10/7/25 14:30, Barry DeZonia wrote:
> > This might be ill behaved for floating point. Rounding errors and
> > correct behavior for Infs and NaNs etc can spring surprises on you.
> > Java has a floating point modulus operator. I am betting the Double or
> > Float class java api javadoc might discuss implementation notes.
> >
> > On Tue, Oct 7, 2025 at 4:24 PM Scott via gdal-dev
> > <gdal-dev at lists.osgeo.org> wrote:
> >>
> >> Thanks for the idea Dan. Building on that, I added it upstream to the
> >> MuParser source. Now I have it in libmuparser as well:
> >>
> >> ./muparser-2.3.5/include/muParserTemplateMagic.h
> >>      static T Mod(T pixel, T div) { return lround(pixel) -
> >> ((lround(pixel) / lround(div)) * lround(div)); }
> >>
> >> ./muparser-2.3.5/src/muParser.cpp
> >>      DefineFun(_T("mod"), MathImpl<value_type>::Mod);
> >>
> >> After rebuild, leads to:
> >>
> >> gdal raster calc \
> >>      --input "p=input.tif" \
> >>      --calc="mod(p[1], 50) == 0 ? p[1] : 255" \
> >>      --ot=Byte \
> >>      --output="output.tif" --co COMPRESS=DEFLATE --overwrite --progress
> >>
> >> Ideally, though, having a mod function in GDAL itself would be awesome.
> >>
> >> Scott
> >>
> >>
> >> On 10/7/25 09:52, Daniel Baston wrote:
> >>> It's fairly straightforward to define functions in C++ and register them
> >>> with muparser. You can see how we do this with "isnan" and "isnodata" here:
> >>>
> >>> https://github.com/OSGeo/gdal/blob/
> >>> ca7a2d38893a8d6cdc03653b47712f4442d99d65/frmts/vrt/
> >>> vrtexpression_muparser.cpp#L27 <https://github.com/OSGeo/gdal/blob/
> >>> ca7a2d38893a8d6cdc03653b47712f4442d99d65/frmts/vrt/
> >>> vrtexpression_muparser.cpp#L27>
> >>>
> >>> I don't think we want too many custom functions, but adding "mod" seems
> >>> like a good idea.
> >>>
> >>> Dan
> >>>
> >>> On Tue, Oct 7, 2025 at 12:30 PM Scott via gdal-dev <gdal-
> >>> dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>> wrote:
> >>>
> >>>      Greetings!
> >>>
> >>>      I've been unable to find a modulo operator in CLI calc. It's not in the
> >>>      muparser functions or appear to be in the forth-coming 3.12 C pixel
> >>>      functions.
> >>>
> >>>      This has been working with muparser, but it's messy every time you need
> >>>      a simple modulo. pixel is real or int, div is int:
> >>>
> >>>      rint(pixel) - (rint(rint(pixel) / div) * div)
> >>>
> >>>      Am I missing something? If not, consider this a feature request! :)
> >>>
> >>>      Thanks!
> >>>      Scott
> >>>
> >>>      --
> >>>      www.postholer.com <http://www.postholer.com>
> >>>
> >>>      _______________________________________________
> >>>      gdal-dev mailing list
> >>>      gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> >>>      https://lists.osgeo.org/mailman/listinfo/gdal-dev <https://
> >>>      lists.osgeo.org/mailman/listinfo/gdal-dev>
> >>>
> >>
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>