Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Aug 2002 17:52:18 +0200
From:      Erik Trulsson <ertr1013@student.uu.se>
To:        Mikhail Teterin <mi+mx@aldan.algebra.com>
Cc:        Dan Nelson <dnelson@allantgroup.com>, Matthew Seaman <m.seaman@infracaninophile.co.uk>, questions@FreeBSD.ORG
Subject:   Re: pow(3) on FreeBSD
Message-ID:  <20020819155217.GA25028@falcon.midgard.homeip.net>
In-Reply-To: <200208191124.35129.mi%2Bmx@aldan.algebra.com>
References:  <200208190413.g7J4DEcw051123@corbulon.video-collage.com> <20020819043012.GN74231@dan.emsphone.com> <200208191124.35129.mi%2Bmx@aldan.algebra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 19, 2002 at 11:24:35AM -0400, Mikhail Teterin wrote:
> On Monday 19 August 2002 12:30 am, Dan Nelson wrote:
> = In the last episode (Aug 19), Mikhail Teterin said:
> = > In accordance with its man-page entry, pow(3) will return 0 if its
> = > second argument is not an integer. Why is that? What's the reasoning
> = > and what is a workaround -- I'm trying to port an application from
> = > Solaris, which uses pow(3) quite heavily...
> 
> = Seems to work fine for me.  Where in the manpage does it say that?  All
> = I can see is that if x<0, y must be an integer.
> 
> = My Solaris manpage says the same thing.
> 
> No, it does not have the requirement of y being an integer. Only that x
> is positive.
> 
> You are right, the FreeBSD's man-page does not specify the return value
> in case of a non-integer y. I just know it from experiment to be zero

Correction: It does not specify the return value for negative
non-integers.

> (and not NaN as Matthew claimed).
> 
> = $ cat > test.c
> = #include <math.h>
> = #include <stdio.h>
> = main()
> = {
> =     printf("%f\n", pow(2, 1.5));
> = }
> = ^D
> = $ gcc test.c -lm
> = $ ./a.out
> = 2.828427
> 
> The test above was, obviously, done on Solaris. On FreeBSD, this same
> program outputs zero:
> 
> 	mteterin@misha:~ (257) uname -a
> 	FreeBSD misha 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Jul 31 13:27:39 EDT 
> 2002     mteterin@misha [...]
> 	mteterin@misha:~ (258) ./a.out 
> 	0.000000
> 	mteterin@attila:~ (515) uname -a
> 	SunOS attila 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R
> 	mteterin@attila:~ (516) ./a.out
> 	2.828427


For me that program prints 2.828427 just as it is supposed to do. 
This is using FreeBSD 4.6-STABLE.  
It might be that something has changed in -current (unlikely but
possible) or it might be your setup that is faulty.

[snip]

> 
> = Even Solaris cannot return a complex value as a double.
> 
> There is nothing complex (pun intended) about, say, 1^2.5. It is still
> 1. -- unless you are running FreeBSD (Linux?)... There is nothing
> complex about Dan's's example (2^1.5) above either -- the correct value
> is 2.828427, but it is 0 on FreeBSD -- in accordance with the man-page
> and in disagreement with Dan...

That comment about complex refers to the case when the second argument
to pow() is a negative non-integer, in which case the result should
indeed be complex which cannot be represented as a double.  
The manpage does not say anything about pow() returning 0 for positive
non-integer arguments, nor does pow() return 0 in that case as far as I
can determine.


> 
> Now, can someone, please, offer the REAL reasons for the FreeBSD's
> apparent defficiency? May be, even a double-precision workaround --
> unlike powf(3), which operates on float-precision numbers?..

I can't duplicate the behaviour you see here on my system so I suspect
it is your setup that is faulty somehow.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020819155217.GA25028>