-
-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Import swift algorithms #4497
Import swift algorithms #4497
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4497 +/- ##
=======================================
Coverage 58.96% 58.96%
=======================================
Files 50 50
Lines 290 290
=======================================
Hits 171 171
Misses 119 119
Continue to review full report at Codecov.
|
861a9c0
to
986dd3a
Compare
sorry guys. been very busy in recent months |
9bae784
to
f95f959
Compare
For better performance
} | ||
|
||
if closest != -1 |
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.
@jjatie I was trying to recall the imp here but I couldn't come up a case that closest could be -1. what's your thought here? As if closest could be -1, this function will return -1, and partitioningIndex
would not return -1?
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 only case where closest == -1
in the old implementation is if the dataset is empty (low - high == -1
). This should probably be checked immediately, rather than later on.
Returning -1
is very non-swift, which is why I've elected to drop that behaviour from everywhere I've found it in 4.0.
partitioningIndex
returns endIndex
if no index is found in startIndex..<endIndex
which is the standard behaviour for binary search (since the correct insertion index would be at the end)
|
||
case .down: | ||
// If rounding down, and found x-value is upper than specified x, and we can go lower... | ||
if closestXValue > xValue && closest > startIndex |
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.
closest > startIndex
is different than closest > 0
in old imp, I'm not sure if they are equivalent. are they?
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.
In this case they are equivalent. I'm using startIndex
as it is better to not assume the start is 0
, as slices do not guarantee startIndex == 0
. It also makes it easier to migrate the algorithm to a generalized extension in the future if desired.
This reverts commit 69a303f.
the CI failed on tvOS very weird, don't understand why. It seems a carthage issue but iOS and macOS build pass. Carthage/Carthage#3019 (comment) is the issue for carthage. It is super long and closed now. I have restarted again to see whether it's bound to different Xcode version and maybe we can find a better fix in the thread. |
filed Carthage/Carthage#3120 and waiting for some suggestions. Besides carthage seems made a major upgrade to support Xcode12 with complex steps to setup. I'm kind of hesitating whether we should follow. Meanwhile, the iOS passed so I assume it's kind of safe to merge? @jjatie |
I believe it is. |
@jjatie @liuxuan30 ... |
This seems to be causing a crash when the chart is tapped. To reproduce, run this code:
And tap on the chart (I tapped near the middle). The app crashes. When I reverted back to the previous commit 857db24 this crash did not happen anymore. |
@StefaniOSApps Did you figure out a solution for this? I have a fork that I use to add some data race protections but it keeps telling me that its missing Algorithms |
@darbysauter See #4572 ... I think that @liuxuan30 approved that PR too fast .. so wie lost cocoa pods in future |
@StefaniOSApps I ended up using my fork of Charts with SPM instead of (Cocoapods and trying to import Algorithms with SPM) works fine now |
@darbysauter right, the best solution is a wrapper from swift to objc (only a workaround 😜) |
* Use Algorithms implementation of binary search * Use `indexed()` where appropriate * Update Package.swift to include SwiftAlgorithms * Use lazy implementation of `prefix(while:)` For better performance * Revert "Use lazy implementation of `prefix(while:)`" This reverts commit 69a303f.
FYI as others have mentioned this has broken CocoaPods and Carthage support. |
* master: update changelog. Fixed incorrect guard return statement when rendering limit lines (ChartsOrg#4563) Fix bounds checks on binary search (ChartsOrg#4577) Added SPM build action (ChartsOrg#4576) Replace FBSnapshotTestCase with pointfree/swift-snapshot-testing (ChartsOrg#4574) Import swift algorithms (ChartsOrg#4497) ChartViewBase cleanup (ChartsOrg#4537) SPM GitHub Action (ChartsOrg#4553) Algorithm updates (ChartsOrg#3638) Added SPM Install section Update README.md Fix missing drawIconsEnabled parameter initialization in the copying constructor of the ChartBaseDataSet (ChartsOrg#4424) Resolve conflict for 4.0 branch and master (ChartsOrg#4456) Alternative for SPM dynamic linking (ChartsOrg#4478) 3.6.0 changelog # Conflicts: # Source/Charts/Renderers/LineChartRenderer.swift
This reverts commit b8dba59. # Conflicts: # Charts.xcodeproj/project.pbxproj # Charts.xcworkspace/xcshareddata/swiftpm/Package.resolved # Package.resolved # Package.swift # Source/Charts/Data/Implementations/Standard/ChartDataSet.swift
Provides convenient algorithms written by the community, curated be the swift core team.