[GRASS5] potential problems in d.vect.thematic when using a column of type real in postgresql

[Moritz Lennert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I just discovered a slight problem in d.vect.thematic, but I'm not
sure whether d.vect.thematic should/could be altered for this, or
whether a simple warning should be inserted in the man page.

When using a column that is defined as 'real' in postgresql, the
results of the comparisons are more or less arbitrary, since, as the
postgresql manual puts it:

"The data types real and double precision are inexact,
variable-precision numeric types", meaning that "comparing two
floating-point values for equality may or may not work as expected".

Now there seem to be two possible solutions for that in postgresql:

1) quote the constant you are comparing your real value with, i.e.
(within psql):

grass=> select * from espvie where e_=81.58;
 grands_sec | pop | icm | e_ | cat | e2
- ------------+-----+-----+----+-----+----
(0 lignes)

grass=> select * from espvie where e_='81.58';
 grands_sec |  pop  |   icm    |  e_   | cat |  e2
- ------------+-------+----------+-------+-----+-------
 23103      | 13600 | 0.722814 | 81.58 |  51 | 81.58
(1 ligne)


Using this solution would mean changing the lines constructing the
sqlwhere variable from

sqlwhere="$GIS_OPT_column $mincomparison $rangemin and
$GIS_OPT_column<=$rangemax"

to

sqlwhere="$GIS_OPT_column $mincomparison '$rangemin' and
$GIS_OPT_column<='$rangemax'"

But I don't know what the effect of this would be on other drivers
(such as dbf). And don't have the time to test this just now.

2) use the 'numeric' data type:

grass=> \d espvie
               Table «public.espvie»
  Colonne   |         Type         | Modificateurs
- ------------+----------------------+---------------
 grands_sec | character varying(8) |
 pop        | real                 |
 icm        | real                 |
 e_         | real                 |
 cat        | integer              |
 e2         | numeric              |

grass=> select * from espvie where e2=81.58;
 grands_sec |  pop  |   icm    |  e_   | cat |  e2
- ------------+-------+----------+-------+-----+-------
 23103      | 13600 | 0.722814 | 81.58 |  51 | 81.58
(1 ligne)

This solution would imply a simple warning in the man page.

This problem is obviously wider than just d.vect.thematic. d.vect is
affected by it as well, and I imagine any command using a where
clause...

Any suggestions ?

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDKGvvrIrMbm76jD8RAhRIAJ9Xmhv2YbqevRow1PaMfq3voa98RQCfTY9M
o/3YjYr1it/fMFHBir/ni0A=
=vb29
-----END PGP SIGNATURE-----