Markus Neteler wrote: > > >> I have tried to update r.surf.idw to floating point: > > >> > > >> but I am not quite sure if this is efficient like this. > > >> Currently it doesn't compile due to some "extern" magic > > >> which I don't quite understand. > > >> I have been inspired by r.example. > > >> > > > > > > The problem is that you have renamed some (but not all) occurrences of > > > "cell" to "outrast", although the variable is still called "cell". > > > > > > > > (given that r.surf.idw should stay for more time) > > > > I have updated the patch (find attached) to the current CVS version, > > still crashing. > > Advice/fix most welcome... > > Still struggling with the FP patch (find attached).
1. A function cannot reference local variables of another function. The outrast variable needs to either be a global variable (like cell) or passed as a parameter. As it stands, the outrast declared in main() and the outrast referenced by interpolate() and make_neighbors_list() are two different variables (the first is local, the second global). Only the former is actually getting initialised, hence the segfault. 2. Changing the type of the cell argument to row_lists() from CELL * to unsigned char * stops the compiler complaining, but the compiler is right to complain. If cell can refer to any of CELL, FCELL or DCELL, any code which dereferences CELL needs three cases. But those values are stored in the value field in the MELEMENT structure, which is an int. So this field qwould need to be either a double or a union of CELL, FCELL, and DCELL, and any code which references that field would also need three cases. Personally, I would suggest simply replacing CELL with DCELL throughout, rather than trying to write three separate cases for everything. If you want to be able to generate CELL output maps (it doesn't necessarily follow that you want CELL out just because you got CELL in), just open the output map as the appropriate type. Most of the time, having separate CELL/FCELL/DCELL cases isn't worth the effort. Sometimes it's worth providing special treatment for integers, but not when you're perfoming interpolation (which naturally produces a FP result even if the inputs are integers). -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
