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

[Barry DeZonia]

Yes, and I think you need to choose carefully between the 3 sources
(java and the two C++/C ones) based upon what you want edge case
behavior to be and whether to copysign() or not or sometimes etc.

On Tue, Oct 7, 2025 at 5:04 PM Javier Jimenez Shaw <j1 at jimenezshaw.com> wrote:
>
> 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