Should map return nan value?

Software G'MIC
1

Test this:

$ (nan,0,1,inf) +pal greyt_bit map.. .

Two things wrong. inf and nan technically should return nan because it doesn’t make sense as there is no value.

So, should it behave like this?

2

Yes, this is intended: Here we enter the area of what is called “undefined behavior” :

  • map assumes that the selected image on which it operates it an image of integer indices. If it’s not the case, you clearly enter the “undefined behavior” area. It’s actually the same if you provide an image with floating-point values : map does not ensure about how the rounding to the used integer is performed. If your input is somewhat “wrong” for the command, expect an “undefined behavior” output.

  • Now, we could say it would be nice to reduce the amount of “undefined behaviors”, and consider that map should test for inf or nan values (and return inf or nan in this case), or even round input floating-point values to the nearest integer, in order to provide the most “defined behavior” output as possible.

This is indeed possible, but this would have a huge cost in terms of processing time : the command would have indeed to test each value to determine if it’s a special case to handle or not, before doing the value mapping.

This means it would slow down map’s operation for all the people who used it with “correct” (integer-valued) input images, just to allow people who used it with “wrong” inputs to have a slightly better-defined (but probably still unusable!) result.

You’ll agree with me that, in the end, this is not a good solution.
That’s why I prefer to stick with this “undefined behavior” area. Note that the result you get with wrong inputs could even depend on the specific rules of the C++ to manage these undefined behaviors!

2 Likes
3

…the representation of +∞ when I write inf and the non-numeric representation when I write nan. I have my reasons for inserting such specialized values in a data set — perhaps I am testing the behavior of my code against extraordinary values. I would become churlish is some environmental considerations makes the mappings of of these symbols to representations more complicated than the straightforward face-value of the symbol (perhaps I am mis-reading your suggestion).

insofar as map goes, probably somewhere in Tutorial Land there should be the error cascade of (1) look ups by indices (integers) falling outside of pallete boundaries follow the boundary argument, policy, and (2) non-integral pels in the selected index image (including π, ±∞, nan) always go to zero. (1) is covered in documentation; (2) is not. Add that to the pile of fixes.

4

Except that’s not true :wink:

 gmic run '256,1,1,1,253.75*x/(w-1) +map. hsv,0'

mapfloat
(2) is more complicated than that…

5

To give more insights:

When map reads offsets from an image whose values should be integers, but are not, it actually casts (in the sense of C++ static cast) the read value to a 64bits integer.
So, nan and inf are probably converted to MAX_INT64 (2^{63}-1), although I’ve not checked.
And floating point values are converted to the nearest integer towards 0 (so it should be equivalent to floor() for the positive integers and ceil() for negative integers).

Not checked though, so that’s theoretically how the “undefined behavior” should work in the case of map.