Re: GiST penalty functions [PoC] - Mailing list pgsql-hackers

From Andrew Borodin
Subject Re: GiST penalty functions [PoC]
Date
Msg-id CAJEAwVG01FYegLvAb=druvkoTF_ifQc7MHXmSK_pqoSQGsSKzA@mail.gmail.com
Whole thread Raw
In response to Re: GiST penalty functions [PoC]  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: GiST penalty functions [PoC]
Re: GiST penalty functions [PoC]
List pgsql-hackers
>autoconf check for IEEE 754 floats
Autoconf man says folowing:
>it is safe to assume IEEE-754 in most portable code these days
https://www.gnu.org/software/autoconf/manual/autoconf.html#Floating-Point-Portability

> A union might be more readable
Here is union version of the patch. It's slower 10% than original cube
and dereference version. Have no idea why.
Select performance is improved as in v3.

Also I've investigated a bit why linear package failed. It's usefull
to think in terms of bijections, not in terms of arithmetic functions.

float 1 is 1065353216 hex 3f800000
FLT_MAX / ( 8 >> 3 ) is 2139095039 hex 7f7fffff
FLT_MAX / ( 8 >> 2 ) is 2130706431 hex 7effffff
FLT_MAX / ( 8 >> 1 ) is 2122317823 hex 7e7fffff
FLT_MAX / ( 8 >> 0 ) is 2113929215 hex 7dffffff

This realm borders are completly wrong.
That maens I used 800 thousands values to pack 2billions of values of
realms 1-3, and all other 2.1 bils of values to pack realm 0. Fragile
arithmetics was done wrong.

What I had to use was
Realm 3
INT32_MAX is nan (or something little less than nan)
3*INT32_MAX/4 is 3.689348e+19
Total little less than 512kk different values

Realm 2
3*INT32_MAX/4 is 3.689348e+19
INT32_MAX/2 is 2.000000e+00
Total 512kk different values

Realm 1
INT32_MAX/2 is 2.000000e+00
INT32_MAX/4 is 1.084202e-19
Total 512kk different values

Realm 0
INT32_MAX/4 is 1.084202e-19
0 is 0.000000e+00
Total 512kk different values

Though I hadn't tested it yet. I'm not sure, BTW, hardcoding this
consts is a good idea.

Best regards, Andrey Borodin, Octonica & Ural Federal University.

Attachment

pgsql-hackers by date:

Previous
From: Matthias Kurz
Date:
Subject: Re: [PATCH] Alter or rename enum value
Next
From: Masahiko Sawada
Date:
Subject: Re: Vacuum: allow usage of more than 1GB of work mem