#### Do you have a question? Post it now! No Registration Necessary. Now with pictures!

## Re: Portability of sinl() etc - with -lm present

And the sine function is defined over all real numbers.

--

Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst

Nokia

"We must do something. This is something. Therefore, we must do this."

-- Antony Jay and Jonathan Lynn, "Yes Minister"

## Re: Portability of sinl() etc - with -lm present

But Eric brought up the cases of +Inf, -Inf and NaN for which there is

no conventional definition of sin. Obviously, on implementation that

don't have these quantities there is no issue, but the debate arose

around the possibility of using just the 387 instruction and that does

have them.

--

Ben.

## Re: Portability of sinl() etc - with -lm present

...

7.12.1p2 says "The description of each function lists any required

domain errors; an implementation may define additional domain errors,

provided that such errors are consistent with the mathematical

definition of the function.203"

The 203 (which is superscripted in the original text) refers to footnote

203, which says: "In an implementation that supports infinities, this

allows an infinity as an argument to be a domain error if the

mathematical domain of the function does not include the infinity."

Note that it says that such a domain error is allowed; not that it's

required. The only required domain errors are those explicitly listed;

and none are listed in the description for sin() in section 7.12.4.6.

## Re: Portability of sinl() etc - with -lm present

I think you are slightly confused here: 387 is just one (lousy?)

implementation of IEEE arithmetic; and IEEE arithmetic (more or less)

mandates a certain behaviour. AFAIK, there is no FPU today which

would not follow IEEE.

And I would expect that the behaviour of sin() at Inf/NaN WAS defined

by Bill...

Hope this helps,

Ilya

## Re: Portability of sinl() etc - with -lm present

["Followup-To:" header set to comp.lang.perl.modules.]

No wonder - it looks like I replied to a wrong message. (There was a

post in the thread which assumed that the fact that the FPU is i387

has some bearing. Apparently, I can't find this post anymore... ;-)

Sorry,

Ilya

## Re: Portability of sinl() etc - with -lm present

Keith Thompson wrote:

If you are about to argue that +Inf, -Inf, and NaN are

real numbers -- or even complex numbers, for which sine is

also well-defined -- you risk excommunication. No one would

mistake me for a mathematician, but my degree was in fact in

mathematics and I still retain a few shreds of principle, and

I bet I could find a black candle and a muffled bell with

minimal delay should need arise. ;-)

Bear in mind that simply extending the domain of the

true sine to include Inf and NaN as arguments with NaN as the

result is not a good solution. The extended sine -- let's

call it sin# -- no longer behaves like the real sine. For

example, -1 <= sine(x) <= 1, but the same cannot be said for

sin#. sine(x)

not hold for sin# and cos#. sine(x)/cosine(x), if it exists,

is equal to tangent(x), but this doesn't hold for sin#, cos#,

and tan#. And so on, and so on. Considering all the properties

that sin#, cos#, tan#, sinh#, ... do not possess, one questions

the utility -- even the rationality! -- of allowing them to

misappropriate the names of their better-behaved originals.

--

Eric Sosman

esosman@ieee-dot-org.invalid

If you are about to argue that +Inf, -Inf, and NaN are

real numbers -- or even complex numbers, for which sine is

also well-defined -- you risk excommunication. No one would

mistake me for a mathematician, but my degree was in fact in

mathematics and I still retain a few shreds of principle, and

I bet I could find a black candle and a muffled bell with

minimal delay should need arise. ;-)

Bear in mind that simply extending the domain of the

true sine to include Inf and NaN as arguments with NaN as the

result is not a good solution. The extended sine -- let's

call it sin# -- no longer behaves like the real sine. For

example, -1 <= sine(x) <= 1, but the same cannot be said for

sin#. sine(x)

***sine(x)+cosine(x)***cosine(x) = 1, but this doesnot hold for sin# and cos#. sine(x)/cosine(x), if it exists,

is equal to tangent(x), but this doesn't hold for sin#, cos#,

and tan#. And so on, and so on. Considering all the properties

that sin#, cos#, tan#, sinh#, ... do not possess, one questions

the utility -- even the rationality! -- of allowing them to

misappropriate the names of their better-behaved originals.

--

Eric Sosman

esosman@ieee-dot-org.invalid

## Re: Portability of sinl() etc - with -lm present

and in the case of NaN, even numbers! No they are not real numbers

but they are valid values of float/double if IEEE is being used.

why not?

because it's been given a bad argument

no, but various other similar equations don't hold for Inf/NaN

x + 1 > x

x * 0 =3D 0

etc.

sine(x)

***sine(x)+cosine(x)***cosine(x) = NaN

if x is NaN. NaN is way to mark the calculation

as erroneous without having to break in the middle of

a long sequence of calculations.

yes but that's what NaNs do

--

Nick Keighley

## Re: Portability of sinl() etc - with -lm present

Says who? Given your background, you may find reading relevant papers

(by Kahane etc) quite entertaining...

Wrong. (Valid only for Im(z)=0, and Inf does not satisfy this...)

Not true for IEEE sine/cosine.

Again, wrong in IEEE...

The question is not of propriety. AFAIU, the question is how to

design the limited-bitwidth arithmetic that not only people with much

more than 10 years experience in low-level bitcrunching have a chance

to write reasonably-behaving numeric algorithms.

Hope this helps,

Ilya

## Re: Portability of sinl() etc - with -lm present

The function definition is built in; the declaration for that function

which should be provided by <math.h> is not built-in.

Use gcc -E to find out which file it is using for <math.h>. Examine that

file to determine whether it provides a declaration for sinl().

## Re: Portability of sinl() etc - with -lm present

[...]

gcc is only part of the implementation. The combination of gcc and

the FreeBSD library apparently is not a conforming C99 implementation,

but given the library's failure to conform, gcc appears to be doing

its job.

--

Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst

Nokia

"We must do something. This is something. Therefore, we must do this."

-- Antony Jay and Jonathan Lynn, "Yes Minister"

gcc is only part of the implementation. The combination of gcc and

the FreeBSD library apparently is not a conforming C99 implementation,

but given the library's failure to conform, gcc appears to be doing

its job.

--

Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst

Nokia

"We must do something. This is something. Therefore, we must do this."

-- Antony Jay and Jonathan Lynn, "Yes Minister"

## Re: Portability of sinl() etc - with -lm present

If you're prepared to draw that distinction, then yes. However,

I don't view math.h to not be part of the compiler just because

it was bundled in a different package from the compiler engine.

Of course, by the time BSD have got their hands and mangled it,

it's no longer GNU's gcc that is to blame, rather BSD's version

in this instance. But I still view BSD's version of the imple-

mentation being broken as the compiler being broken.

Phil

--

Marijuana is indeed a dangerous drug.

It causes governments to wage war against their own people.

-- Dave Seaman (sci.math, 19 Mar 2009)

## Re: Portability of sinl() etc - with -lm present

[...]

Then you're using the word "compiler" in a way that's entirely

inconsistent with the way I use it.

Personally, I find it very useful to have a word "compiler" that

refers to a particular subset of an implementation, and another word

"library" that refers to another subset. And I can use the word

"implementation" to refer to the whole thing. Do you really consider

these to be unimportant distinctions? And do you consider glibc, for

example, to be part of a "compiler", even though it doesn't actually

compile anything?

--

Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst

Nokia

"We must do something. This is something. Therefore, we must do this."

-- Antony Jay and Jonathan Lynn, "Yes Minister"

Then you're using the word "compiler" in a way that's entirely

inconsistent with the way I use it.

Personally, I find it very useful to have a word "compiler" that

refers to a particular subset of an implementation, and another word

"library" that refers to another subset. And I can use the word

"implementation" to refer to the whole thing. Do you really consider

these to be unimportant distinctions? And do you consider glibc, for

example, to be part of a "compiler", even though it doesn't actually

compile anything?

--

Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst

Nokia

"We must do something. This is something. Therefore, we must do this."

-- Antony Jay and Jonathan Lynn, "Yes Minister"

## Re: Portability of sinl() etc - with -lm present

I do bundle them all together. So my 'compiler' doesn't just have

the libraries, it has an assembler and linker too. But you're right,

there are useful distinctions to be drawn, and my stance can be

perceived as a lazy one.

Phil

--

Marijuana is indeed a dangerous drug.

It causes governments to wage war against their own people.

-- Dave Seaman (sci.math, 19 Mar 2009)

## Re: Portability of sinl() etc - with -lm present

With a bit of Googling about sinl() and FreeBSD, it appears that (as of

the last reference I can find, several years old) FreeBSD's libc does

not support long doubles well, and they're blaming it on bugs in GCC

that prevent them from doing so. Apparently, GCC doesn't really

understand the difference between double and long double, so sometimes

variables end up with more or less precision, respectively, than they're

supposed to have. With x87's 80-bit precision going away in x64 (which

specified SSE math), though, it won't matter for much longer.

S

--

Stephen Sprunk "Stupid people surround themselves with smart

CCIE #3723 people. Smart people surround themselves with

K5SSS smart people who disagree with them." --Isaac Jaffe

## Re: Portability of sinl() etc - with -lm present

Stephen Sprunk wrote:

The SSE instructions offer double precision. The FPU is still there, and

it should be used for long double precision.

Lcc-win uses (in its 64 bit version) the SSE instruction set for double

precision, and the FPU for long double precision. Note that since the

FPU still provides with sin/cos/atan/log/ and other high level

functions, all of those functions are done (even when you use double

precision) in the FPU, meaning they are done in long double precision

even for floats.

There is NOTHING that specifies SSE as the only way to do double

precision math.

The SSE instructions offer double precision. The FPU is still there, and

it should be used for long double precision.

Lcc-win uses (in its 64 bit version) the SSE instruction set for double

precision, and the FPU for long double precision. Note that since the

FPU still provides with sin/cos/atan/log/ and other high level

functions, all of those functions are done (even when you use double

precision) in the FPU, meaning they are done in long double precision

even for floats.

There is NOTHING that specifies SSE as the only way to do double

precision math.

#### Site Timeline

- » How to install XML::LibXML ?
- — Next thread in » PERL Modules Announcements

- » right name for package
- — Previous thread in » PERL Modules Announcements

- » Updating the hash across the files
- — Newest thread in » PERL Modules Announcements

- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — The site's Newest Thread. Posted in » Secure Shell Forum