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

[Javier Jimenez Shaw]

In c++ there is
https://en.cppreference.com/w/cpp/numeric/math/fmod
And
https://en.cppreference.com/w/cpp/numeric/math/remainder.html

On Tue, 7 Oct 2025, 23:55 Barry DeZonia via gdal-dev, <
gdal-dev at lists.osgeo.org> wrote:

> 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
> >
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251008/2ae849ab/attachment.htm>