Skip to content

Conversation

@simonbyrne
Copy link
Member

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
Member 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
Member 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
test/math.jl Outdated
@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
Member 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
Member 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
Member 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
Member 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
Member 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
Member Author

ah, makes sense. I've restarted.

@simonbyrne
Copy link
Member 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.

5 participants