-
Notifications
You must be signed in to change notification settings - Fork 183
Conversation
katz centrality is broken.
Hierarchy: AbstractGraph -> AbstractSimpleGraph -> SimpleGraph / SimpleDiGraph AbstractEdge -> AbstractSimpleEdge -> SimpleEdge |
Also, the docs got a little messed up. Need to fix these. |
Codecov Report
@@ Coverage Diff @@
## master #541 +/- ##
========================================
+ Coverage 99.17% 100% +0.82%
========================================
Files 57 60 +3
Lines 2898 2985 +87
========================================
+ Hits 2874 2985 +111
+ Misses 24 0 -24 Continue to review full report at Codecov.
|
I like this, my only issue is that there are a lot of methods that are currently mapped to _NI(). Many of these methods could be implemented in terms of each other. For example |
Can we do the reverse? Oh, I see the issue. The problem is that The methods that equal |
My "go-to" check for regression, Current master:
This branch:
|
…Graphs.jl into sbromberger/benchmarks
There appears to be a slight regression in
edit: no longer - perhaps it's an aberration:
|
|
Just a heads-up: I spent the weekend updating the docs and making them consistent. There are a few docstrings that need work - I've noted them in comments - but I don't think this will block a merge. |
That is an awesome work, I wish could write code with just half your efficiency 👍 I will digest the changes over time by writing more LG tutorials, looking forward to @jpfairbanks review. |
|
Great Job Seth. This was a lot of work! How do we want to rebase this?
|
@jpfairbanks I like your approach outlined above. I'm really sorry this is such a mess of commits, but I wanted to break them out into smaller units of change so that they would be easy to bisect/diagnose. I have one more major commit to make (merge the new docs); it has some additional code bugfixes, found when the docs didn't match the output, and some cleanup of variable names. It shouldn't cause any major impact though. Can you rebase? I don't trust my git skills to do it myself, and my original plan (don't laugh) was just to "squash and merge". |
I gave rebasing this thing a try, but there are a lot of conflicts and the resolution choices you make compound, I got about halfway through. If someone else wants to try and rebase it, go ahead. I think we can squash and merge this behemoth into one big commit. Most of the internal state will not really be useful anyway. LGTM soon. |
@jpfairbanks thanks for the attempt. I figured it just became too big to manage properly. Is there any reason not to merge into master at this point? There's one other PR depending on this one. |
I suppose we should run some benchmarks. |
I am fine with merging and fixing any regressions in a separate PR |
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.
Squash this massive PR and let's all agree to never have a PR with 7K+ lines of diff again.
hah! how else could I have done this? (Genuine question.) |
) | ||
return a[1] ≈ b[1] && a[2] ≈ b[2] | ||
end | ||
≈(a::Tuple{T, T}, b::Tuple{T, T}) where T <: AbstractFloat = |
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.
this is type piracy and changes global behavior - could you do this instead with a different operator name, or via all(a .≈ b)
to not extend arithmetic operators to tuples?
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.
The global behavior is undefined: there is no isapprox
method for tuples, so nobody should be using it.
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.
We're only using it in one place, so I can rename it, but it's (at least for me, and likely for the author) a really intuitive extension of isapprox
.
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.
sure, people have tried adding arithmetic to tuples in a bunch of places, but it has surprising side effects because the language uses tuples for argument lists and return values
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.
Good point. I'm renaming now, but I've also filed JuliaLang/julia#21336 for discussion.
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.
#18779
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. Do I close the METADATA PR and re-release v0.8.0 with this new code?
|
||
Return a zero-vertex, zero-edge version of the same type of graph as `g`. | ||
""" | ||
zero(x...) = _NI("zero") |
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.
should this be zero(g::AbstractGraph)
? defining zero-arg zero()
and vararg zero
for Any
inputs seems odd
Hi all,
Here's a starting point for abstraction. Comments please.