[GRASS5] GRASS testsuite issue

[Daniel Calvelo]

Guessing: those are FCELL or DCELL, right? It doesn't happen for
integer rasters, I reckon.

It smells like be some math libraries or libc precision difference.
Try to otput to ascii and use diff to see if that's the case. If it
is, then the test suite should fall back to compare some form of
truncated versions for floating-point data, if this kind of
cross-platform testing is sought (which I think is).

Daniel.

On 2/10/06, Sören Gebbert <soerengebbert at gmx.de> wrote:
> Dear list,
> while developing the new GRASS testsuite, i noticed some unexpected behavior.
>
> I try to validate the generated output of grass modules with md5 checksum tests.
> I check the binary files in the grass location (cell, fcell, topo, coor and other files ).
> I was expecting the output of grass (raster, raster3d and vector) is equal on x86 machines,
> but after some testing i recognized that the output differs.
>
> If i create raster map's with r.mapcalc or r3.mapcalc and use sin() and cos(), the md5
> checksums are differ between Linux AMD gcc-3.4.4 and Linux P4 gcc-4.0.3 systems.
> The same with v.buffer. But the command "r.mapcalc test=10" produce's equal output.
>
> How could this happen? Have the compiler, libraries (math?) or other software influence of the
> data generation, or is this a feature of the gislib?
> Maybe the optimize funciton of gcc (-On, SSE, mmx, 3dnow and stuff) produce this behavior?
> I dont know, but i need help. If there is no way no avoid this behavior,
> the md5 checksum test (an important feature) will not work :(  .
> A work-around may be: to check the output exported with the *.out.ascii modules?
>
> What to do? Any help or suggestions?
>
> Best regards
> Soeren
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>


--
-- Daniel Calvelo Aros