Re: POC: rational number type (fractions) - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: POC: rational number type (fractions)
Date
Msg-id 0404d85ef736eb9a33138e94d0c745cd22e50fba.camel@j-davis.com
Whole thread Raw
In response to Re: POC: rational number type (fractions)  (Joe Nelson <joe@begriffs.com>)
List 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





pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Function to track shmem reinit time
Next
From: Jeff Davis
Date:
Subject: Re: Memory-Bounded Hash Aggregation