# Re: [Vala] Libgee problem

• From: Jan Hudec <bulb ucw cz>
• To: Alessandro Pellizzari <alex amiran it>
• Cc: vala-list gnome org
• Subject: Re: [Vala] Libgee problem
• Date: Wed, 9 Dec 2009 20:52:50 +0100

```On Wed, Dec 09, 2009 at 19:16:41 +0100, Alessandro Pellizzari wrote:
```
```Il giorno mer, 09/12/2009 alle 11.30 +0100, Nicolas ha scritto:

```
```var map = new HashMap <double, double> ();

Return this error:
error: `double' is not a supported generic type argument, use `?' to box
value types

Why libgee does not support double with hashmap?
```
```
I think using double as hash index is dangerous, because of
approximation.
```
```
Well, it needs care to handle properly. But it might happen one knows the
numbers will indeed always be exactly the same (because they come from
a fixed set or something) and than you can do it.

```
```Did you think about transforming the double numbers to "fixed precision
decimals" (represented by 64bit integers) or to strings?
```
```
That's more pain than it's worth IMO. I'd say it would be easier to simply
use the fact, that you have to implement (glib does not have them) the hash
and equality function anyway and do the hashing and equality comparison with
the desired precision there.

Converting to random format won't magically save you from approximation. If
you convert the values after calculation, they will already be approximate,
so it won't help you. You have to calculate in a sufficiently precise
representation (obviously you won't calculate on strings, right?)

Note, that doubles won't randomly decide to loose precision. It's
deterministic and depnds on the calculations you do. For division,
fixed-point will loose precision too and it can overflow on multiplication.

Also note, that when the approximation happens, it can lead to wrong bucket
being chosen, no matter how you round it, because the rounding can always
just happen to cross the boundary between the buckets.

--
Jan 'Bulb' Hudec <bulb ucw cz>

```