Re: POC: rational number type (fractions)

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Joe Nelson <joe(at)begriffs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: POC: rational number type (fractions)
Date: 2020-02-22 17:51:16
Message-ID: 0404d85ef736eb9a33138e94d0c745cd22e50fba.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2020-02-21 at 19:24 -0600, Joe Nelson wrote:
> I could imagine having two types, a rational8 for the current
> implementation, and an arbitrary precision rational. Perhaps...

The main thing I'm trying to avoid is a situation where we introduce
"rational", but it only meets a subset of the use cases, and then we
end up with another extension. I'm not saying that's happening here,
but it would be good to compare against other implementations (for
instance from normal programming languages) to see if we are missing
some use cases.

If you are using rational to track positions of items in an online to-
do list, and the user keeps swapping or rotating items in the list, is
that going to lead to overflow/underflow?

> > * what's the philosophy regarding NULL and rational? Why are NULL
> > arguments returning non-NULL answers?
>
> The rational_intermediate(x, y) function picks a fraction between x
> and
> y, and NULL was meant as a signal that one of the sides is unbounded.
> So rational_intermediate(x, NULL) means find a fraction larger than
> x,
> and rational_intermediate(NULL, y) means find one smaller than y.

Would "x+1" or "y-1" also work for that?

I am a little worried about introducing a function that is not well-
defined. Would a midpoint function serve the purpose?

> If there are already todos positioned after 2 then it'll find a spot
> between 2 and the min. However if there are no todos after 2 then
> min()
> will return NULL and we'll simply find a position *somewhere* after
> 2.

Interesting. That could probably be solved with a COALESCE() around the
MIN(), but your version is a little cleaner.

> > * Is rational_intermediate() well-defined, or can it just choose
> > any
> > rational between the two arguments?
>
> It chooses the mediant [2]

Maybe we should define it as the mediant then?

> currently included these casts: integer -> rational, float8 <->
> rational. Don't have one for numeric yet.

A cast to numeric would make sense. What will you do in cases where the
domains don't quite match, are you rounding or truncating?

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2020-02-22 17:55:26 Re: Memory-Bounded Hash Aggregation
Previous Message Alexander Korotkov 2020-02-22 17:43:20 Re: Function to track shmem reinit time