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

[Scott]

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