[GRASS5] GRASS testsuite issue

[Sören Gebbert]

Hi,
thank you for your response.

On Friday 10 February 2006 22:23, Daniel Calvelo wrote:
> Guessing: those are FCELL or DCELL, right? It doesn't happen for
> integer rasters, I reckon.

Yes you are correct, fcell and dcell. 
And the vector output. 

> 
> It smells like be some math libraries or libc precision difference.

Indeed, and i think there is no way to avaoid this. :(

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

That will be hopefully an acceptable solution. For now the generated output is exported with
r/r3.out.ascii and the float output is truncated (dp=5). The r.out.ascii output between a AMD and 
a P4 system with different libc and compiler differs if i use the option dp=7! 

First i was thinking about a module which compares two maps (r/r3/vect) within a error-range, for example eps=0.000001.
But then i realized that truncating combined with md5 checksums will do the same,
and is more effective, because you can store the checksum.

To provide output validation for vector maps, i have to patch v.out.ascii. Because the output of 
v.buffer in default spearfish location differs too. The coodinate's
calculation is the "problem". So i have to truncate this float output too:

Normal output:
590529.01701912|4914624.99952804|1
590843.01701912|4918543.99952804|1
590943.01701912|4914228.99952804|1

Truncted output:
590529.01|4914624.99|1
590843.01|4918543.99|1
590943.01|4914228.99|1

I hope 1cm is enough precision for utm locations?
So i will add a dp option to vout.ascii.

But there are new problems:
1.) the test suite output validation depends on 3 grass modules: r.out.ascii, r3.out.ascii and v.out.ascii. 
2.) The validation for correct (float) calculations is not provided
3.) To validate the output, you have to export it

But i hope this will provide cross plattform md5 checksum validation.
And i think this is the only (for me) doable solution.

Any suggestions or comments are welcome.

Best regards
Soeren 

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