rint() replacement

rint() replacement

Post by Bruce Momji » Sun, 11 May 2003 11:10:02




> speaking of rint(), I just got this on Linux on a clean get from CVS:

> gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../.
> ./src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../
> src/include   -c -o dt_common.o dt_common.c
> dt_common.c: In function `dt2time':
> dt_common.c:1271: warning: implicit declaration of function `rint'

> which I guess is kinda undesirable...

OK, fixed.  I added '#include <math.h>'.

However, this illustrates another problem.  dt_common and other ecpg
files test for c.h defines but there is no #include of c.h or
postgres.h, so they never get triggered.  That needs to be fixed.

--
  Bruce Momjian                        |  http://candle.pha.pa.us

  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

 
 
 

rint() replacement

Post by Bruce Momji » Sun, 11 May 2003 11:13:06




> > Also, there is a special HPUX 9 configure test to look for rint() a
> > different location.  I am not sure if the new replacement rint() test
> > has invalidated that code.  Do we still support HPUX 9?  (I added a
> > comment to the configure script to mention it might now be broken.)

> HPUX 9 is obsolete (heck, HP is about to obsolete HPUX 10...).  If
> there's any beta testers out there still running it, they can find out
> for us.  But I'd say that if you are providing a portable rint() in
> /port, we could get rid of the HPUXMATHLIB crock and let configure
> fall back to using the /port version.

OK, removed.

Quote:> > I see a cbrt() in float.c.  Do we actually have platforms that don't
> > have cbrt()/cube root?  I am inclined to remove it more move it to
> > /port.

> Hardly worth the trouble.  The substitute implementation is small
> and portable...

Sorry, my paragraph was bad.  Should I remove cbrt or move it to /port?

--
  Bruce Momjian                        |  http://candle.pha.pa.us

  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

 
 
 

rint() replacement

Post by Tom La » Sun, 11 May 2003 11:34:48




>> Hardly worth the trouble.  The substitute implementation is small
>> and portable...
> Sorry, my paragraph was bad.  Should I remove cbrt or move it to /port?

I'd leave it sit as-is.  I don't think it's worth fooling with.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command

 
 
 

rint() replacement

Post by Tom La » Sun, 11 May 2003 13:34:09



> Probably, most of the time nearbyint() is what is really wanted instead
> of rint().  The rint() function can throw an exception even when it does
> what is wanted.

The real issue here is "what is portable behavior"?

PG never changes the rounding mode, so we should always get the default,
which is round-to-nearest-even unless there have been big changes made
while I wasn't looking.

Expressing that as nearest() instead of rint() would be fine with me if
all platforms recognized nearest().  But rint() is more likely to be
portable in the real world, AFAIK.

I do have a bit of a problem with the CVS-tip version of this code: it
falls back to implementing rint() in terms of modf().  I would like to
know the justification for assuming that modf() is more portable than
rint().

Quote:> Most of the time, this is what rint() is doing if we are round to
> nearest:
> return floor(x+0.5);

I'd be happier with that as a fallback implementation ...

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command

 
 
 

rint() replacement

Post by Kurt Roec » Sun, 11 May 2003 20:55:21




> I do have a bit of a problem with the CVS-tip version of this code: it
> falls back to implementing rint() in terms of modf().  I would like to
> know the justification for assuming that modf() is more portable than
> rint().

modf() is part of C89 and POSIX, just as floor().  I have modf()
here, I do not have rint().

rint() was a BSD thing and is now part of C99.

Kurt

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

 
 
 

1. rint() replacement

In working on an rint() for Win32, I found two --- one in
port/qnx4/rint.c and another in dt_common.c.  The first is very simple,
using fmod, while the second is very complicated.

I would like to pick the best one and move it to /port.  Any idea why
there are two different methods for rint() --- is the second one
complicated because it doesn't use fmod?

--
  Bruce Momjian                        |  http://candle.pha.pa.us

  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------

2. Filter dimension members based on Current dimension member

3. SQL replacement in real time

4. US-NJ: ROSELAND-ORACLE FINANCIALS W/STRONG FIXED ASSETS

5. HELP: Need a Replacement SQL 6.5 Enterprise CD

6. Network Access

7. GUID type support in for ODBC/C++/GUID as replacement for autonumber fields

8. DTS and replication

9. Top Replacement

10. Phone number for replacement CD?

11. Character replacement by SQLServer

12. Replacement for Last Function

13. Oracle to MSSql, COMMENT ON...replacement?