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

Glynn Clements glynn at gclements.plus.com
Sun Apr 6 18:14:38 EDT 2008


Ivan Shmakov wrote:

>  > 1. Individual modules can write whatever they want under cell_misc.
>  > E.g. the fftreal and fftimag files written by i.fft are in host byte
>  > order.
> 
> 	Shouldn't these be fixed?

First, you need to identify which modules are doing this sort of
thing.

As for i.fft/i.ifft, the fact that it's storing the FFT data as a
"map" (where the actual map data is only used for e.g. d.rast, and is
ignored by i.ifft) is arguably a more significant flaw than the fact
that the files aren't portable.

>  > 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.

>  > 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
(simplifying the test suite is usually the *only* benefit).

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list