-
Notifications
You must be signed in to change notification settings - Fork 11
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
Conversation
There was a problem hiding this 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).
@fp4code this PR has some good work in it but the repo has changed greatly since the original PR. |
@fp4code can you make the setting for the PR to "allow edits by maintainers"? |
Yes of course, @JeffFessler. I'm looking into how to "allow edits by maintainers"! |
@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
@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. |
Pull Request Test Coverage Report for Build 3330509665Warning: 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
💛 - Coveralls |
Ok @fp4code this took me too many tries, but finally I got it to pass tests with type inference. |
src/cauchy.jl
Outdated
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")) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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)) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 Report
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. |
@mkitti there was a flaw in my previous implementation for iterables. The |
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. |
JF updates:
collect