Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

besselj Float32 calling incorrect function #15272

Merged
merged 1 commit into from
Mar 1, 2016
Merged

besselj Float32 calling incorrect function #15272

merged 1 commit into from
Mar 1, 2016

Conversation

simonbyrne
Copy link
Contributor

Hopefully should fix recent 32-bit build failures (e.g. #15259).

@tkelman
Copy link
Contributor

tkelman commented Feb 28, 2016

Aha. Strange that this would be intermittent?

@simonbyrne
Copy link
Contributor Author

Yeah, very odd. I don't know enough about the ABI, but I guess in certain cases we happened across the right bit pattern.

@yuyichao
Copy link
Contributor

Looks like we only have very limitted test for besselj function, (only 0 for Float32?)

@simonbyrne
Copy link
Contributor Author

I've added some more tests.

@simonbyrne simonbyrne force-pushed the sb/besselfix branch 2 times, most recently from 4017ebe to 63da79b Compare February 28, 2016 09:55
@@ -387,12 +387,20 @@ j33 = besselj(3,3.)
@test besselj(-3,-3) == j33
@test besselj(-3,3) == -j33
@test besselj(3,-3) == -j33
@test besselj(3,3f0) ≈ j33
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do these have to be approximate because we can't reliably constrain different libm's accuracy here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it's because they're calling different precision functions, so they won't be exactly equal.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but if we round the higher-precision value into the lower precision type can we reliably test exact equality?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, it's up to the libm/openspecfun (there are 3 different C functions involved)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay so if the answer is no even to the rounded version, then not worth worrying about

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and maybe it needs an even larger tolerance?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe cast the RHS to Float32.

julia> 0.1320342f0  0.1320341839246122
false

julia> 0.1320342f0  Float32(0.1320341839246122)
true

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, perhaps we should change isapprox to use the larger of the 2 tolerances.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would make more sense. Probably a different issue/pr though...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's do Float32 on the rhs now, and think about tweaking isapprox separately

@simonbyrne
Copy link
Contributor Author

I think I broke travis by doing a bunch of force pushes, and so the most recent commit doesn't appear. Any way I can get it to restart?

@tkelman
Copy link
Contributor

tkelman commented Feb 28, 2016

f0b8cc8 is merging the right commit, someone just clicked cancel...

@simonbyrne
Copy link
Contributor Author

Isn't it 63da79b?

@tkelman
Copy link
Contributor

tkelman commented Feb 28, 2016

Yeah, but f0b8cc8 is "Merge 63da79b into 7199602". PR builds run on the merge commit.

@simonbyrne
Copy link
Contributor Author

ah, makes sense. I've restarted.

@simonbyrne
Copy link
Contributor Author

Okay, I've updated the isapprox checks.

@tkelman
Copy link
Contributor

tkelman commented Feb 29, 2016

great, do merge when green

tkelman added a commit that referenced this pull request Mar 1, 2016
besselj Float32 calling incorrect function
@tkelman tkelman merged commit 9971fd2 into master Mar 1, 2016
@tkelman tkelman deleted the sb/besselfix branch March 1, 2016 00:38
@tkelman
Copy link
Contributor

tkelman commented Mar 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants