Hurray :-)

[Justin Hickey]

Hello Stephan

On Sep 17,  4:50pm, Stephan Eickschen wrote:
>
> XGRASS is running! Thank you very much for your help, again!

Great! I forgot to mention that xgrass may not display the opening window
properly. So I have included info to fix it if you encounter this.

When "xgrass4.1" was first run, it didn't display the lists properly. To fix
this the file "$GIS/src/xgrass/menu/xgdbset.c" had to be changed. Lines 1637
and 1692 appear as follows:
	XmNrightAttachment, XmATTACH_FORM,
	XmNleftAttachment, XmATTACH_FORM,
These lines are part of the definition of the list containers that are placed
inside a form. The definitions, as they are, both describe the containers as
occupying the whole form. Therefore, one of the containers will cover up the
other. This situation is fixed by commenting out the above lines. The program
was re-compiled by simply typing "gmake4.1" in the "$GIS/src/xgrass/menu"
directory.

> What is - basicly - the difference between the "normal" grass and the
> "floating point" version you have mentioned? I think, that I read this
> words a while ago, but I can't remember anymore ...

Basically normal grass will not use floating point values in raster maps. So if
you have elevations like 12.56 meters then you have to multiply all the values
by 100 to change them to 1256 cm. During the last days of development of Grass
at CERL, they had developed floating point code so users didn't need to do this
multiply step. Development was halted before they could commit the code to the
grass source tree. Instead it is available on moon but as I said earlier I
found several programming errors. Basically, many files are replaced,
especially in the libraries and some new files have been added.

>	the compilation
> 	/ linking goes right, but the results are definatly wrong...
> 	It's all C code.

My experience has been that if code gives different results on two different
systems, then the authors of the code have used contsructs in C that result in
undefined behaviour (eg y = x + x++;) which means that each vendor must decide
how to resolve the problem. In this case some vendors do one thing, other
vendors do other things, thus the different results.

The other possibility could be the difference in libraries, especially if there
are a lot of calls to math library functions. Unfortunately, the math libraries
are not standard between vendors (this is why you need the -lm if you link to
the math library). So if the code has calculations that depend heavily on
floating point numbers, there may be differences in rounding off errors. You
may have to print out intermediate results to see where the code is failing.

I hope this helps.

-- 
Sincerely,

Jazzman (a.k.a. Justin Hickey)  e-mail: jhickey at hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do.  ---Anonymous

Jazz and Trek Rule!!!
==================================================================