[GRASS-dev] patch for v.voronoi/v.delaunay

[Hamish]

> > Markus wrote:
> >  > It seems that the precision gets somewhere lost in
> >  > db_convert_column_value_to_string()
> >  >
> >  > i.e. lib/db/dbmi_base/columnfmt.c
> >  >
> >  > but I don't find where is is rounded.
> >
Hamish:
> >  lib/db/dbmi_base/valuefmt.c db_convert_value_to_string() does:
> >         case DB_C_TYPE_DOUBLE:
> >             sprintf (buf, "%lf",db_get_value_double(value));
> >             G_trim_decimal(buf);
> >
> >  the %lf is rounding to %.6f?
> >
> >  maybe
> >  - "%lf"
> >  + "%.14f"
> >
> >  then let G_trim_decimal() remove any extra .00000s.
> >
> >  but maybe such noisy output is not always wanted. :-/
> 
> Let's do the fix because a library should keep the precision.
> We can reduce noise in the modules then.

understand that you will then change the way the DB attribute library is
currently designed, it's not as simple as a small patch or new lib fn
(beyond adjusting %lf to show more digits). For me, I don't feel
qualified to mess around with Radim's DB lib code much.

output from computer stored IEEE FP representation to human-readable will
always need some form of %f simplification, and associated loss of
exactness. Life is a compromise, as they say.

[v.]db.select is the important one, as that is specifically data out.


> >  (e.g. pretty output for d.what.vect tcl form)
> >  ?
> 
> Yes, but trim that at module level.

I think it might be annoying for every module to have their own random
%.[6-16]f choice, I think it is better to write it into one place, or
have two lib fns, one standard and the other full precision. But having
two would be a bit annoying and doesn't address the real problem.


> >  FWIW v.out.ascii defaults to dp=8.
> 
> So we should consequently use the same length everywhere
> (adjustable) and full precision at library level.

I expect SQL "a * b" works at the DB level, and so doesn't suffer the
loss of precision?


> > In the case of v.colors, the SQL set loop could be rewritten to
> > avoid this problem by matching to the cat number, not trying to
> > logically match the FP value.
> 
> This would be good.

Yes. I feel some responsibility to fix that, but unfortunately I have
very little time to work on that currently.


Hamish




     
____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ