-
Notifications
You must be signed in to change notification settings - Fork 98
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
Remove Metric <: SemiMetric <: PreMetric #228
Conversation
Codecov Report
@@ Coverage Diff @@
## master #228 +/- ##
==========================================
- Coverage 96.82% 96.73% -0.09%
==========================================
Files 8 8
Lines 725 736 +11
==========================================
+ Hits 702 712 +10
- Misses 23 24 +1
Continue to review full report at Codecov.
|
This doesn't look like an improvement to me and doesn't look like standard usage of traits. Traits are typically used for small pieces of extra information that you want to dispatch on (often related to dispatching to an optimized method). This might be the type of indexing ( From #199:
This feels like something that is more suitable for using traits for (which there should be no problem for you to do) so I don't really see that as an argument for this. Also, remember this package is very old and has a large number of packages depending on it. Breaking changes should be kept to an absolute minimum. |
For StringDistances, traits won’t work since I would like to define
specialized methods for findall etc, which is not possible using traits.
I do get the argument about breaking changes, but the change is mainly
going to impact developers, rather than end users.
…On Sun, Sep 12, 2021 at 3:51 PM Kristoffer Carlsson < ***@***.***> wrote:
This doesn't look like an improvement to me and doesn't look like standard
usage of traits. Traits are typically used for small pieces of extra
information that you want to dispatch on (often related to dispatching to
an optimized method). This might be the type of indexing (LinearSlow or
LinearFast) or if the length is known (HasLength, IsInfinite etc). But
not to encode big families of types like this.
From #199 <#199>:
In StringDistances, I would love to be able to define certain functions on
these groups. This is not possible, however, due to the lack of multiple
inheritance in Julia.
This feels like something that is more suitable for using traits for
(which there should be no problem for you to do) so I don't really see that
as an argument for this.
Also, remember this package is very old and has a large number of packages
depending on it. Breaking changes should be kept to an absolute minimum.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#228 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPPPXLOQA7F73OC7G4JUTLUBUAD7ANCNFSM5D4MX7KQ>
.
|
Types should be based on interfaces, not properties. To me, the current situation of abstract type SymmetricAbstractArray <: AbstractArray end This would make it impossible create new array types (e.g. TriangularArray or SparseArray) that may end up being symmetric.
|
This PR removes the type structure
Metric, SemiMetric, PreMetric
which makes it harder to define new distance types (solving #199)Still, generic distances are encouraged to define
issymmetric
andissubadditive
, which is used inpairwise
to accelerate computations.