r.mapcalc: add data types info to manual

[pesekon2]

No description provided.

[veroandreo]

Since r.mapcalc has functions to convert data into int, float and double, I agree this is a good place to add such details. I still wonder however if such details should also be in the rasterintro manual instead of the wiki.

[pesekon2]

Since r.mapcalc has functions to convert data into int, float and double, I agree this is a good place to add such details. I still wonder however if such details should also be in the rasterintro manual instead of the wiki.

I do agree that it should be added there, too. The wiki information is a well-hidden gem. Do you think we should open a new PR for that one for clarity and cleanness or shall we just stick it to this one (and rename it then)?

[marisn]

You'll have to provide better explanation where these values come from. I didn't had time to go over all code, but for me it seems that these numbers are incorrect.
Raster types are defined in gis.h file lines 625–257 as int, float and double. Thus int is a standard C int, that shall be at least -32767 +32767 (see Annex E of ISO/IEC 9899:2017). Ditto for floats and doubles.

[ldesousa]

OK, this is a tricky one. The Wikipaedia lists the following lengths for these data types:

• int: minimum 16-bit
• float: unspecified
• double: unspecified

The question then is: can GRASS compile on systems where these types have different meanings from those stated? When I started playing with computers most architectures where 16-bit, and by then GRASS was already old. If this is the case, then some reference must be added like "on most systems", or "on 32-bit and 64-bit architectures".

Another thing: would also be important to describe the change in data type length on the int() function itself.

Hat tip @marisn

[marisn]

The question then is: can GRASS compile on systems where these types have different meanings from those stated? When I started playing with computers most architectures where 16-bit, and by then GRASS was already old. If this is the case, then some reference must be added like "on most systems", or "on 32-bit and 64-bit architectures".

Yes it can.
As long as we keep CELL == int, there is a possibility to have any value. One way out would be to define CELL as "as required to keep values in range from MIN to MAX" and then provide magic that would look up suitable data type. Still this would require a lot of changes in the code as many places (unfortunately) are written with CELL == int in mind. As for this PR, I suggest to rewrite it to clearly state that these are limits on an AMD64 (x86_64) architecture when GRASS is compiled with GCC / CLANG (covering most of common systems running GRASS).

[pesekon2]

@marisn: Thanks for the thoroughful info. The docs were updated in 08aa852, trying to address the issue.