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 <[email protected]> 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 > > <[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
