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
<[email protected]> 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-
[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.osgeo.org/mailman/listinfo/gdal-dev <https://
lists.osgeo.org/mailman/listinfo/gdal-dev>
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
