| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Greatest Common Divisor |
| Date: | 2020-01-04 08:35:43 |
| Message-ID: | alpine.DEB.2.21.2001040925230.31333@pseudo |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bonjour Vik,
>> The point of swapping is to a void possibly expensive modulo, but this
>> should be done on absolute values, otherwise it may not achieve its
>> purpose as stated by the comment?
>
> Ah, true. How widespread are these architectures that need this special
> treatment? Is it really worth handling?
Dunno. AFAICR it was with sparc architectures 25 years ago.
Also I do not like much relying on the subtleties of C99 % wrt negative
numbers to have the algorithm work, I'd be much at ease to deal with sign
and special values at the beginning of the function and proceed with
positive numbers afterwards.
>> I'm unsure about gcd(INT_MIN, 0) should error. Possibly 0 would be nicer?
>
>
> What justification for that do you have?
ISTM that the current implementation has:
\forall int4 n, n \neq MIN_INT4, \gcd(n, 0) = 0 ?
In which case applying the same rule for min int seems ok.
--
Fabien Coelho - CRI, MINES ParisTech
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2020-01-04 08:59:46 | Re: Greatest Common Divisor |
| Previous Message | Peter Geoghegan | 2020-01-04 07:01:59 | Re: pgsql: Add basic TAP tests for psql's tab-completion logic. |