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

Make DomainError more informative #22751

Merged
merged 2 commits into from
Jul 12, 2017
Merged

Make DomainError more informative #22751

merged 2 commits into from
Jul 12, 2017

Conversation

timholy
Copy link
Sponsor Member

@timholy timholy commented Jul 11, 2017

Fixes #12152.

@timholy
Copy link
Sponsor Member Author

timholy commented Jul 11, 2017

The travis errors look weird. A consequence of the switch to trusty?

Perhaps this will fail too, but worth a try: @nanosoldier runbenchmarks(ALL, vs = ":master")

@fredrikekre
Copy link
Member

A consequence of the switch to trusty?

Perhaps, same error in #22750

@tkelman
Copy link
Contributor

tkelman commented Jul 11, 2017

Complete coincidence, was happening before changing .travis.yml too. The unicode consortium might be rate-limiting Travis' IP's like they were doing for appveyor at one point. It looks like we maybe missed this download from our caching server whitelist, which should be added in staticfloat/cache.julialang.org#16. I'm not clear on the details of how that gets deployed though, at least since the caching server was redone and moved a couple months back.

@tkelman tkelman added the needs news A NEWS entry is required for this change label Jul 11, 2017
base/intfuncs.jl Outdated
@@ -159,6 +160,10 @@ invmod(n::Integer, m::Integer) = invmod(promote(n,m)...)
# ^ for any x supporting *
to_power_type(x::Number) = oftype(x*x, x)
to_power_type(x) = x
@noinline throw_depbs(p) = throw(DomainError(p,
Copy link
Contributor

Choose a reason for hiding this comment

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

this only occurs twice, may as well spell out the name a little more

@@ -436,6 +438,14 @@ julia> eigvecs(A, B)
"""
eigvecs(A::AbstractMatrix, B::AbstractMatrix) = eigvecs(eigfact(A, B))

function throw_de_complex(A)
if length(A) < 10
Copy link
Contributor

Choose a reason for hiding this comment

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

bit arbitrary, maybe the showerror should be looking at the iocontext limits?

base/math.jl Outdated
@@ -27,6 +27,16 @@ using Core.Intrinsics: sqrt_llvm

const IEEEFloat = Union{Float16, Float32, Float64}

@noinline function throw_complex_domainerror(x, f)
Copy link
Contributor

@tkelman tkelman Jul 11, 2017

Choose a reason for hiding this comment

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

maybe x and f should be the other way around to match nan_dom_err ?

edit: misread - maybe change to a different argument name than f for whatever it is that nan_dom_err is doing?

@@ -169,7 +169,7 @@ Compute ``\\cos(\\pi x)`` more accurately than `cos(pi*x)`, especially for large
function cospi(x::T) where T<:AbstractFloat
if !isfinite(x)
isnan(x) && return x
throw(DomainError())
throw(DomainError(x, "`x` must be finite."))
Copy link
Contributor

Choose a reason for hiding this comment

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

this and sinpi(x::T) where T<:AbstractFloat should probably be consistent

@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

@timholy
Copy link
Sponsor Member Author

timholy commented Jul 11, 2017

We should cancel all remaining builds until #22133 (comment) is resolved, otherwise we're just clogging the queue.

@timholy timholy closed this Jul 11, 2017
@timholy timholy reopened this Jul 11, 2017
@tkelman tkelman removed the needs news A NEWS entry is required for this change label Jul 12, 2017
struct DomainError <: Exception
val
msg
DomainError(val::ANY) = (@_noinline_meta; new(val))
Copy link
Contributor

Choose a reason for hiding this comment

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

keep an eye on whether @nospecialize gets merged before this

@timholy
Copy link
Sponsor Member Author

timholy commented Jul 12, 2017

The AppVeyor failures in the old buildlogs looked fine---the failure seemed pretty clearly unrelated. OK to merge now?

if isa(ex.val, AbstractArray)
compact = get(io, :compact, true)
limit = get(io, :limit, true)
print(IOContext(io, compact=compact, limit=limit), "DomainError with ", ex.val)
Copy link
Contributor

Choose a reason for hiding this comment

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

the compact code path doesn't look like it's tested anywhere

base/intfuncs.jl Outdated
@@ -147,7 +147,8 @@ julia> invmod(5,6)
"""
function invmod(n::T, m::T) where T<:Integer
g, x, y = gcdx(n, m)
(g != 1 || m == 0) && throw(DomainError())
g != 1 && throw(DomainError((n, m), "Greatest common divisor is 1."))
Copy link
Member

Choose a reason for hiding this comment

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

I am confused: Is g not the gcd?

@noinline function throw_exp_domainerror(x)
throw(DomainError(x, string("Exponentiation yielding a complex result requires a ",
"complex argument.\nReplace x^y with (x+0im)^y, ",
"Complex(x)^y, or similar.")))
Copy link
Member

Choose a reason for hiding this comment

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

The first method recommends calling complex, whereas the second recommends calling Complex; should these methods consistently recommend one or the other?

@@ -106,7 +106,7 @@ Compute ``\\sin(\\pi x)`` more accurately than `sin(pi*x)`, especially for large
function sinpi(x::T) where T<:AbstractFloat
if !isfinite(x)
isnan(x) && return x
throw(DomainError())
throw(DomainError(x, "`x` cannot be infinite."))
Copy link
Member

Choose a reason for hiding this comment

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

Slight inconsistency between errors in this file? ("x cannot be infinite" versus "x must be finite"?)

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe that's intentional, as some of the methods check for isnan and return the input, others don't

Copy link
Member

@Sacha0 Sacha0 left a comment

Choose a reason for hiding this comment

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

Fantastic! :)

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.

None yet

5 participants