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

Define chol for UniformScaling's #22633

Merged
merged 2 commits into from
Jul 18, 2017
Merged

Conversation

mschauer
Copy link
Contributor

This came also up during the review by @tkelman of https://github.com/mschauer/Bridge.jl and is quite natural to define. There cannot be a CholFact because UniformScaling s are not AbstractArray s



## Cholesky
function _chol!(J::UniformScaling, uplo)
Copy link
Contributor

Choose a reason for hiding this comment

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

is this mutating?

Copy link
Contributor Author

@mschauer mschauer Jun 30, 2017

Choose a reason for hiding this comment

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

This is following verbatim the chol(::Number) implementation.

Copy link
Member

Choose a reason for hiding this comment

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

It is a trick to allow a recursive definition of chol. See

Akk, info = _chol!(A[k,k], UpperTriangular)
. The outer structures will typically be mutable but not the inner. I think it is fine because ! is not saying "will mutate", just "be aware, might mutate".


Compute the square root of a non-negative UniformScaling `J`.

# Example
Copy link
Contributor

Choose a reason for hiding this comment

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

Examples plural, no blank line after

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

there are pending pr's that are going to be changing all of the existing cases

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, then I only change that one instance in base/linalg/uniformscaling.jl

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah just change the one you're adding

@mschauer
Copy link
Contributor Author

Hm, on a related but orthogonal note to this, chol(fill(3.*I, 3,3)) fails with
ERROR: MethodError: no method matching isreal(::UniformScaling{Int64})
and after defining Base.isreal(J::UniformScaling) = isreal(J.λ)) with

ERROR: StackOverflowError:
Stacktrace:
 [1] chol(::Hermitian{UniformScaling{Int64},Array{UniformScaling{Int64},2}}) at ./linalg/cholesky.jl:188 (repeats 80000 times)

@ararslan ararslan added the linear algebra Linear algebra label Jun 30, 2017
@fredrikekre
Copy link
Member

Since the implementation is in base/linalg/uniformscaling.jl (rather than base/linalg/cholesky.jl) I suggest that we move the test to test/linalg/uniformscaling.jl (instead of in test/linalg/cholesky.jl as it is currently).

@mschauer
Copy link
Contributor Author

Travis: Timeout.

@mschauer
Copy link
Contributor Author

mschauer commented Jul 6, 2017

I would not like to move the tests, they integrate nicely into the file. On the other hand, the implementation could well be in linalg/cholesky.jl but the linalg/uniformscaling.jl is later in compilation order so I would not know how to rearrange this.

@fredrikekre
Copy link
Member

I think that something like

@testset "chol" begin
    for T in (Float64, Complex128)
        λ = T(4)
        @test chol*I)  λ*I
        @test_throws LinAlg.PosDefException chol(-λ*I)
    end
end

would integrate nicely into test/uniformscaling.jl. It is nice to keep the mirroring between implementation file and test file IMO :)

@mschauer
Copy link
Contributor Author

mschauer commented Jul 7, 2017

Actually, I let myself be convinced here.

@mschauer
Copy link
Contributor Author

Bump.

@kshyatt
Copy link
Contributor

kshyatt commented Jul 18, 2017

@fredrikekre are you happy with this as is? @tkelman ?

@andreasnoack andreasnoack merged commit eb133ab into JuliaLang:master Jul 18, 2017
jeffwong pushed a commit to jeffwong/julia that referenced this pull request Jul 24, 2017
* Define chol for UniformScaling's

* Move test for chol(lambda*I) to test/linalg/uniformscaling.jl
UniformScaling(c), info
end

chol!(J::UniformScaling, uplo) = ((J, info) = _chol!(J, uplo); @assertposdef J info)
Copy link
Member

@fredrikekre fredrikekre Nov 9, 2017

Choose a reason for hiding this comment

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

What is the motivation for this method? Should fall in the same category as the now deprecated chol(::Number) IIUC, see #24498

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The function chol! is a chainable modifying array function and should do the right thing to immutable arrays. If !-versions of chainable array functions are defined for immutable arrays, then f!(g!(h!(copy(A())))) is a good way to write efficient and generic code which works for immutables and mutables (here ! allows f, g, h to use the copy of A as workspace where appropriate). In the same fashion, copy pushes through immutables and is defined for UniformScalings.

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

Successfully merging this pull request may close these issues.

6 participants