Added tests for math.jl functions

[kshyatt]

mod2pi and modf had no tests at all so I added enough that all branches are covered. There might be one or two extraneous ones. frexp had one test but most of the function (the array version, the Float32 and Float64 specializations) was not covered so I added tests for that as well. @test_approx_eq didn't seem to want to work with tuples - if there's a way to do this I can change the modf and frexp tests to be more concise.

[fabianlischka]

Hi, good idea, I think.
mod2pi is tested reasonably in test/mod2pi.jl - those tests should probably be merged into math.jl, it doesn't seem worth it to keep an extra file around for that; and pruned somewhat, as well.

(An alternative would be to test every function that excessively... Maybe in 0.5 or so... :-p )

[tkelman]

It was mentioned elsewhere that math.jl is a pretty nondescriptive name. It would make more sense to split math.jl up into separate pieces with more specific names. Most of the current content of math.jl is for special functions, so test/special.jl would probably be a better name for it anyway.

edit- found the comment #8364 (comment)

[kshyatt]

Oops ... I should have read the output of ls more carefully. Should I remove my mod2pi tests and re-push?

[tkelman]

If the tests of mod2pi that you're adding cover areas that the existing ones don't, then I'd say add them to the other file. On special functions, most of the base/ code was reorganized in #7083 but it looks like none of the tests were moved. For some of the linear algebra code there's been a desire to have the organization in test/ mirror that in base/, but we don't have to figure all of that out for this PR.

[kshyatt]

Looking at the mod2pi tests in mod2pi.jl, it looks like that covers everything I did. It's pretty hard for me to figure out what the actual inputs are because everything's a giant float, but I think I didn't do anything new. So I should delete mine and re-push?

[tkelman]

I think I didn't do anything new. So I should delete mine and re-push?

Sure.

[kshyatt]

Did I screw up the git log again? Twice in one day?

[tkelman]

Nope, 0542cb1 looks fine. Sometimes you need to refresh the page, or github can get confused for a second. For anyone else's reference the original commit that included mod2pi tests (now rebased away) was abd6908.

Not sure whether everyone's 100% on the same page when it comes to code style for whitespace-inside-parens / brackets, but that's functionally irrelevant. I think the encouraging readable whitespace item in CONTRIBUTING.md is mostly about whitespace after commas, but I could be wrong on that.

[kshyatt]

@vtjnash, @tkelman assures me that you're the one to ping about why my linux build isn't working?

[tkelman]

#9544 would be the culprit there (maybe?), we'll probably turn off the ccall(:raise) test for now so it doesn't catch innocent PR's like this one

[tkelman]

I guess one slightly more concise syntax for testing approximate equality of a tuple-returning function would be by splatting into an array like @test_approx_eq [modf(convert(elty,1.2))...] elty[0.2, 1.0]. There's more syntax features going on there so maybe that's unnecessarily complicated.

[timholy]

Since the travis failure has nothing to do with this PR, I'm going to merge.

[tkelman]

backported the new tests in f4bd89f