From: | Ants Aasma <ants(dot)aasma(at)eesti(dot)ee> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Does people favor to have matrix data type? |
Date: | 2016-05-25 11:07:26 |
Message-ID: | CA+CSw_ttk9XGgV5rtPpKd-E3BfBPt3W0dT5Qqq1Zjc9=Uar_=A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 25, 2016 at 10:38 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 25 May 2016 at 03:52, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
>>
>> In a few days, I'm working for a data type that represents matrix in
>> mathematical area. Does people favor to have this data type in the core,
>> not only my extension?
>
>
> If we understood the use case, it might help understand whether to include
> it or not.
>
> Multi-dimensionality of arrays isn't always useful, so this could be good.
Many natural language and image processing methods extract feature
vectors that then use some simple distance metric, like dot product to
calculate vector similarity. For example we presented a latent
semantic analysis prototype at pgconf.eu 2015 that used real[] to
store the features and a dotproduct(real[], real[]) real function to
do similarity matching. However using real[] instead of a hypothetical
realvector or realmatrix did not prove to be a huge overhead, so
overall I'm on the fence for the usefulness of a special type. Maybe a
helper function or two to validate the additional restrictions in a
check constraint would be enough.
Regards,
Ants Aasma
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Seltenreich | 2016-05-25 12:18:34 | Re: [sqlsmith] PANIC: failed to add BRIN tuple |
Previous Message | Dmitry Igrishin | 2016-05-25 10:05:47 | Deleting prepared statements from libpq. |