[GRASS-dev] patch for v.voronoi/v.delaunay
Markus Neteler
neteler at osgeo.org
Sat May 3 15:26:26 EDT 2008
On Sat, May 3, 2008 at 5:33 AM, Hamish <hamish_b at yahoo.com> wrote:
> Markus Neteler 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.
>
>
> 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.
> (e.g. pretty output for d.what.vect tcl form)
> ?
Yes, but trim that at module level.
> FWIW v.out.ascii defaults to dp=8.
So we should consequently use the same length everywhere
(adjustable) and full precision at library level.
> for the v.colors script, SQL "select * WHERE dbl_col = <FP number>" is
> always going to be problematic.
>
> the C way:
> if( abs(test - value) < GRASS_EPSILON )
On Sat, May 3, 2008 at 7:41 AM, Hamish <hamish_b at yahoo.com> wrote:
> 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.
Markus
More information about the grass-dev
mailing list