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