Re: BUG #2357: docs for mod() are wrong

On Mar 24, 2006, at 4:39 PM, Tom Lane wrote:

> "Philip Crotwell" <crotwell(at)seis(dot)sc(dot)edu> writes:
>> It would be nice if mod could directly take a double,
>
> Given the inherent approximate nature of float arithmetic, I'm not sure
> this makes a lot of sense. How often do you really do modulo on
> floats?

We have a table with double longitudes as a column, but it is always a
problem as to whether the earth is -180 to 180 or 0 to 360. To get
around it we so something like
SELECT * FROM table WHERE minlon < mod(lon, 360) AND maxlon > mod(lon,
360)
The basic idea is that using mod(lon, 360) allows us to find entries
with lon=-90 or lon=270 as they are really the same spot on the ground.

It isn't that big of a deal as you can work around it by casting, but
the fact mod works with a numeric but not with a double just seemed
strange to me.

thanks,
Philip

>
>> but if not the docs
>> should say that the arguments should be NUMERIC
>
> That would be incorrect. We have it for all the exact numeric types.
>
> regression=# \df mod
> List of functions
> Schema | Name | Result data type | Argument data types
> ------------+------+------------------+---------------------
> pg_catalog | mod | bigint | bigint, bigint
> pg_catalog | mod | integer | integer, integer
> pg_catalog | mod | integer | integer, smallint
> pg_catalog | mod | integer | smallint, integer
> pg_catalog | mod | numeric | numeric, numeric
> pg_catalog | mod | smallint | smallint, smallint
> (6 rows)
>
> I don't see an easy way to cram that statement into the small amount of
> space available in the table though :-(
>
> regards, tom lane