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

Clean and 100% covered Cauchy matrices #17

Merged
merged 26 commits into from
Jan 1, 2023

Conversation

fp4code
Copy link
Contributor

@fp4code fp4code commented Feb 16, 2017

JF updates:

  • not using travis anymore
  • handle general NTuple and AbstractArray without collect
  • handle type carefully because matrix elements are reciprocals of the types of the "vector" inputs (this is especially important if the inputs have units; in that case the type of the matrix elements is definitely not the type of the vectors)

@fp4code fp4code changed the title Clean and 100% covered Hankel matrices Clean and 100% covered Cauchy matrices Feb 16, 2017
@coveralls
Copy link

coveralls commented Feb 16, 2017

Coverage Status

Coverage increased (+5.6%) to 50.562% when pulling 3e21f6c on fp4code:fp-cauchy-pr into babf5fb on jiahao:master.

jiahao
jiahao previously requested changes Aug 22, 2017
Copy link
Contributor

@jiahao jiahao left a comment

Choose a reason for hiding this comment

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

Thanks for the PR and apologies for being MIA for so long!

This PR certainly improve the current state of the code. I would accept it after the size(A, n) method is restored (it is needed separately from size(A) as part of the array interface).

src/cauchy.jl Outdated Show resolved Hide resolved
@JeffFessler JeffFessler mentioned this pull request Aug 13, 2021
@JeffFessler
Copy link
Member

@fp4code this PR has some good work in it but the repo has changed greatly since the original PR.
If you look at recent PRs you will see I am going through the types one-by-one and trying to clean them up akin to what you did here. Do you want to update this PR?

@JeffFessler
Copy link
Member

@fp4code can you make the setting for the PR to "allow edits by maintainers"?
If not then I'll have to start from scratch...

@fp4code
Copy link
Contributor Author

fp4code commented Oct 26, 2022

Yes of course, @JeffFessler. I'm looking into how to "allow edits by maintainers"!

@fp4code
Copy link
Contributor Author

fp4code commented Oct 26, 2022

@JeffFessler, it looks like the red box on the right was already checked. Please, let me know.

These days we use github actions not travis.
Because `Matrix(A)` is the way to do that now.
Refine tests
@JeffFessler JeffFessler dismissed jiahao’s stale review October 26, 2022 11:08

size(A,i) no longer needed

@JeffFessler
Copy link
Member

@fp4code thanks, I figured out how to make updates. Lots of things changed in the 5 years (!) since your original PR. I made several updates in the web portal and it will probably take a few iterations for the tests to pass.

@JeffFessler JeffFessler marked this pull request as draft October 26, 2022 13:36
@coveralls
Copy link

coveralls commented Oct 26, 2022

Pull Request Test Coverage Report for Build 3330509665

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

Details

  • 15 of 15 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+4.3%) to 96.889%

Totals Coverage Status
Change from base Build 3321757331: 4.3%
Covered Lines: 218
Relevant Lines: 225

💛 - Coveralls

@JeffFessler JeffFessler marked this pull request as ready for review October 26, 2022 15:56
@JeffFessler
Copy link
Member

Ok @fp4code this took me too many tries, but finally I got it to pass tests with type inference.
Could you please review?

src/cauchy.jl Outdated Show resolved Hide resolved
src/cauchy.jl Outdated
Comment on lines 41 to 44
Tx = eltype(first(x))
Ty = eltype(first(y))
all(==(Tx), eltype.(x)) || throw(ArgumentError("inconsistent x element types"))
all(==(Ty), eltype.(y)) || throw(ArgumentError("inconsistent y element types"))
Copy link
Contributor

Choose a reason for hiding this comment

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

Are x and y more abstract than an AbstractArray{T}? Could we enforce consistency in another way?

Copy link
Member

Choose a reason for hiding this comment

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

AFAIK, in every other special matrix in this package, the input types (when relevant) were originally just Vector and we have generalized many of them to AbstractVector so that users can use ranges like 1:3.
For reasons unknown to me, this particular special matrix allowed more general iterable inputs, like a tuple of the form (1.0, 1//2, 3f0). The test case even had a row vector of the form [2im 3f0] or such. Honestly I don't quite know what the use case is for supporting more general iterables. However, the wiki page defines x_i and y_i to be two "injective sequences" so that language is more general than vectors. Perhaps the original code authors were intending hold true to that definition.

The "injective" part of that definition means that each of these two sequences should have unique elements, and currently the code was not testing for that. I will add a test that reports a warning - let me know what you think.

Copy link
Member

Choose a reason for hiding this comment

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

Actually, I've looked back at the history of the original PR by @fp4code
https://github.com/fp4code/SpecialMatrices.jl/blob/e5036efc4cc3c6ece11be6e9c0d90e5b0a9019ae/test/cauchy.jl
and it looks like the most general type being tested was AbstractArray, not more general iterables.
So it would be fine with me to simplify this constructor to take only AbstractArray types with 1-based indexing.
Would that be preferable to you @mkitti ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should definitely write a method for AbstractVector{T}. We can even leave the older implementation here.

src/cauchy.jl Outdated
Ty = eltype(first(y))
all(==(Tx), eltype.(x)) || throw(ArgumentError("inconsistent x element types"))
all(==(Ty), eltype.(y)) || throw(ArgumentError("inconsistent y element types"))
T = eltype(one(Tx) + one(Ty))
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we use the type promotion system here directly?

Copy link
Member

Choose a reason for hiding this comment

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

Originally I had code that used something like promote_type(x...) but it failed @inferred for some tests. Apparently the compiler was unable to do type inference when the input x is an iterable with a mix of several element types.
So I resorted to this all approach to make type inference work.
I'm open to suggestions. (Ideally Julia would have an abstract type for an iterable where all elements are the same type, and AbstractArray would be a subtype of that parent type.)

Co-authored-by: Mark Kittisopikul <[email protected]>
@codecov
Copy link

codecov bot commented Nov 3, 2022

Codecov Report

❗ No coverage uploaded for pull request base (master@a7b36cf). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master      #17   +/-   ##
=========================================
  Coverage          ?   98.59%           
=========================================
  Files             ?        8           
  Lines             ?      213           
  Branches          ?        0           
=========================================
  Hits              ?      210           
  Misses            ?        3           
  Partials          ?        0           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@JeffFessler
Copy link
Member

@mkitti there was a flaw in my previous implementation for iterables. The getindex method requires 1-based indexing, and general iterables do not have such indexing. AFAIK the only viable arguments here are AbstractArray with 1-based indexing, and NTuple, so I have restructured the constructor to support "only" those two cases. This is more general than other lazy matrix types in this package (which used to support only Vectors and now also support AbstractVectors.) This set of arguments suffices to cover all the test cases that were there previously. It is ready for your next review.

@JeffFessler
Copy link
Member

Hi @fp4code and @mkitti, could you double check this updated PR?

@JeffFessler JeffFessler requested review from jishnub and removed request for ivanslapnicar November 15, 2022 17:32
@JeffFessler JeffFessler mentioned this pull request Dec 27, 2022
@JeffFessler
Copy link
Member

Hi everyone, the bug in #46 has been sitting there for years and this PR will address it. My preference is to have a separate set of eyes on any code that is merged, so I've asked multiple people for reviews. But I've gotten no response, so finally I am going to go ahead and merge this. We can always improve it later if I've overlooked something.

@JeffFessler JeffFessler merged commit aa1bd90 into JuliaLinearAlgebra:master Jan 1, 2023
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