Skip to content

Conversation

@abelsiqueira
Copy link
Member

No description provided.

@coveralls
Copy link

coveralls commented Sep 17, 2019

Coverage Status

Coverage decreased (-0.4%) to 91.864% when pulling e5343c0 on abelsiqueira:remove-function-types into 3462b64 on JuliaSmoothOptimizers:master.

@codecov
Copy link

codecov bot commented Sep 17, 2019

Codecov Report

Merging #99 into master will increase coverage by 0.1%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master      #99     +/-   ##
=========================================
+ Coverage   92.49%   92.59%   +0.1%     
=========================================
  Files           6        6             
  Lines         533      527      -6     
=========================================
- Hits          493      488      -5     
+ Misses         40       39      -1
Impacted Files Coverage Δ
src/lsr1.jl 98.38% <100%> (ø) ⬆️
src/LinearOperators.jl 94.07% <100%> (+0.29%) ⬆️
src/PreallocatedLinearOperators.jl 78.72% <100%> (ø) ⬆️
src/kron.jl 100% <100%> (ø) ⬆️
src/adjtrans.jl 79.62% <100%> (ø) ⬆️
src/lbfgs.jl 97.89% <100%> (-0.05%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3462b64...e5343c0. Read the comment docs.

@abelsiqueira abelsiqueira force-pushed the remove-function-types branch from 813bc53 to e5343c0 Compare November 7, 2019 17:19
@test op' * ones(2) == -ones(2)
@test transpose(op) * ones(2) == -ones(2)
end
end
Copy link
Member

Choose a reason for hiding this comment

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

Nice!

@dpo
Copy link
Member

dpo commented Nov 7, 2019

I've lost track of where we stand exactly. Does this resolve #97 in the end?

@abelsiqueira
Copy link
Member Author

It resolves #97 but it becomes type unstable on other parts, such as op * v. The thing is, it doesn't become slow because of it, apparently.
I've used the following script to test the time:

using LinearOperators
N = 15; n = 5
op = LinearOperator(rand(100n,100n))
v = randn(100n)
@time op * v
@time vcat([ op * randn(100n) for i = 1:N ]...)

lops = [ LinearOperator(randn(n,n)) for i=1:N ]
C = hcat(lops...)
@time y = C*randn(n * N)

lops = [ LinearOperator(randn(n,n)) for i=1:N ]
C = vcat(lops...)
@time y = C*randn(n)

lops = [ LinearOperator(randn(n,n)) for i=1:N ]
C = sum(lops)
@time y = C*randn(n)

lops = [ LinearOperator(randn(n,n)) for i=1:N ]
C = prod(lops)
@time y = C*randn(n)

The first test is just trying to see if there will be slowdown on op * v or concatenating op * v. The other four test are slow compilation times reported in #97. The result in #master (3462b64) is

  0.104810 seconds (248.08 k allocations: 12.861 MiB, 5.70% gc time)
  0.078862 seconds (175.04 k allocations: 9.409 MiB)
 11.991879 seconds (679.77 k allocations: 31.905 MiB, 0.04% gc time)
 11.210015 seconds (163.19 k allocations: 8.062 MiB, 0.03% gc time)
 11.503678 seconds (196.38 k allocations: 9.678 MiB)
 10.931659 seconds (174.61 k allocations: 8.669 MiB)

and on this branch

  0.097581 seconds (248.00 k allocations: 12.836 MiB)
  0.086059 seconds (175.03 k allocations: 9.398 MiB, 5.19% gc time)
  0.099990 seconds (339.82 k allocations: 16.891 MiB, 5.28% gc time)
  0.014279 seconds (24.09 k allocations: 1.255 MiB)
  0.003726 seconds (1.27 k allocations: 72.063 KiB)
  0.003686 seconds (1.42 k allocations: 82.033 KiB)

@dpo
Copy link
Member

dpo commented Nov 11, 2019

Excellent, thank you!

@dpo dpo merged commit b3a6816 into JuliaSmoothOptimizers:master Nov 11, 2019
@abelsiqueira abelsiqueira deleted the remove-function-types branch November 11, 2019 14:00
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.

3 participants