[GRASS-dev] Re: creating location from the command line

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

[...]

 >>> 2. Even when portable formats are used, the precise choice of
 >>> format may be platform-specific.

 >>> E.g. the row indices in the raster files can be 4 or 8 bytes,
 >>> depending up the size of off_t in the code which creates them. The
 >>> actual size is stored in the file, and the code which reads them
 >>> can handle the case where the size used in the file doesn't match
 >>> the off_t used in the code, so long as the actual values fit within
 >>> an off_t.

 >> Why not to use 8-byte values unconditionally when writing a raster?
 >> (Retaining the ability to read 4-byte values for the sake of
 >> compatibility.)

 > Both formats already exist in the wild, so the code which reads
 > raster data has to be able to cope with both. In that situation,
 > there doesn't seem to be much point in modifying the writing code.

	If not to allow for repeatable results.  And this may be useful
	for purposes other than the test suite's ones.

	(Actually, I've found it quite annoying to check for the results
	to match with any tool other than cmp(1).)

 >>> For text formats, there's the issue that the MSVCRT version of
 >>> printf's %e and %g always use a 3-digit exponent, while other
 >>> implementations follow ANSI and only use 3 digits where necessary.

 >> If there's only a small number of ways to store the result, several
 >> checksums may be specified for the file.

 > With floating-point, there's always the possibility of differences in
 > rounding depending upon the architecture and which optimisations were
 > used. Ensuring that floating-point calculations are repeatable at the
 > bit-pattern level is typically a lot of work for negligible benefit

	Agreed.  For now, I'd focus in making the test suite work for
	the most basic modules, and defer the testing of FP ones until a
	later time.

	A somewhat cumbersome solution for the FP rasters would be to
	import a raster map, find the difference with `r.mapcalc' and
	then check for it to be acceptable with `r.univar'.

 > (simplifying the test suite is usually the *only* benefit).