Implement all functions in #6148 except for 'pow' functions

[jeffreyrogers]

Pretty much what the title says #6148 suggested adding several functions to Julia based on the IEEE-754 standard. All were possible to write with very brief, simple code. I didn't implement the pow functions, both because Julia provides exponentiation as an operator (rather than a function) and because some functionality will require #2976 to be completed first.

[tkelman]

this is going backwards, you don't want this included here - should put this back to 5599b8

submodules are annoying like this - next time you see a weird diff in a submodule, try doing git submodule update and it should go away

[tkelman]

Thanks for the contribution. Looks like compound and rootn are using y in the signature but n in the calculation? New functions like this should have tests added, either in test/math.jl or a test file with a more specific name. While these are the basic generic implementations, it doesn't do much good to have them unless there are specialized more-accurate versions for common types like Float64. Some of these might be available in https://github.com/JuliaLang/openlibm but not yet exposed? Or that would be a natural place to add them if the specialized versions need to be implemented in assembly or C.

[jeffreyrogers]

Yeah, you're right about compound and rootn. I can add tests, although I guess it won't do much good if they need specialized implementations. A quick glance at openlibm suggested they aren't implemented there, but I can probably write them. Assuming I (or someone else) does that, then you just have to use ccall in math.jl to expose them through Julia, right?

[kmsquire]

Since some users use the system libm, it wouldn't be very useful to have
these only in libm.

On Friday, October 24, 2014, Jeffrey Rogers [email protected]
wrote:

Yeah, you're right about compound and rootn. I can add tests, although I
guess it won't do much good if they need specialized implementations. A
quick glance at openlibm suggested they aren't implemented there, but I can
probably write them. Assuming I (or someone else) does that, then you just
have to use ccall in math.jl to expose them through Julia, right?

—
Reply to this email directly or view it on GitHub
#8801 (comment).

[jeffreyrogers]

Would implementing the functions in openlibm and falling back to the Julia versions if they aren't available be an acceptable way to handle that problem?

[JeffBezanson]

The problem is that an implementation like log2(1+x) is not accurate enough to be useful. The reason these functions are specified in the standard is that they require special implementations that avoid computing 1+x.

[jeffreyrogers]

Right, so assuming an accurate implementation is possible in openlibm, is it better to expose it even though some users won't be able to use the accurate implementation and will fall back to a pure Julia version or should it just be left out?

[JeffBezanson]

I think it's better not to have it. If somebody understands these issues and specifically needs and uses log21p, there is no point in giving them the wrong answer.

[jeffreyrogers]

Okay, that makes sense. I'll just close this issue then, since it doesn't look like there's much I can do.

[tkelman]

no point in giving them the wrong answer

Only for people who use system libm, right?

Maybe the best thing to do would be to try adding the specialized implementations to openlibm, and expose them with ccall via a package that specifically errors when it detects the user doesn't have a version of openlibm new enough to contain the specialized versions.

[kmsquire]

If efficient C versions are to be coded up, it would probably be better to add them to https://github.com/JuliaLang/openspecfun. These were actually added to openlibm at one point, but then it was decided to attempt to maintain compatibility with system libm.

[tkelman]

Oh yeah, duh, that is pretty much the point of having openspecfun be separate.