I don't think we need to make hashes with FLOATVAL keys possible. I can't imagine a single use-case where such a thing would be worth the added costs. This is especially true when you consider that common arithmetic roundoff errors of wider formats is going to make equality testing of floats difficult and error-prone.
Better use of integer keys is a very good thing. --Andrew Whitworth On Wed, Mar 14, 2012 at 9:36 PM, Luben Karavelov <[email protected]> wrote: > On Thu, 15 Mar 2012 11:51:37 +1100, Vasily Chekalkin <[email protected]> > wrote: >> >> Yay! >> >> Can you also try parrot with int keys and float values? Just for >> curiosity. >> >> -- >> Bacek > > > I was looking to make it possible (yesterday I pushed a commit to make > iterating > Hash PMCs with int keys possible) but it is not at the moment. > > There as also some uncertainty how to proceed. At my PC(amd64) FLOATVAL is > defined as synonym for double (64 bits). Hash values have maximum size of a > pointer and there are architectures that have > sizeof(void *) < sizeof(double) > i386 to be precise. > > So if we want to store FLOATVAL directly in hash tables we have 2 choises: > > 1. Make FLOATVAL = float (32 bit) on platforms where > sizeof(void *) < sizeof(double) > > I am not sure if this is the right choice - what guarantees do we give for > FLOATVALs (Num registers)? > > 2. make hashval field big enough for doubles - it will pose some penalty on > 32bit platforms > > In either case it will not be the major case of use of hash tables. I am not > even sure if Rakudo could do hashes with int keys > > If we have consensus how to proceed I am willing to code it even if it is > not > the major use case. > > > Best regards > > -- > Luben Karavelov > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
