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