Conversation
There was a problem hiding this comment.
Remaining comments which cannot be posted as a review comment to avoid GitHub Rate Limit
Runic
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
[Runic] reported by reviewdog 🐶
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
I haven't read a lot of this kind of VSA, so I can't really comment on if this is properly implemented. Apart from that, code looks good, so no comment on that side. A question regarding naming conventions: up until now we have used "generic" naming conventions for the different VSA, for example, BinaryHV refers to the Binary Splatter Code of Kanerva, or TernaryHV refers to the MAP VSA. This new HV type would break this convention (i think) and we could rename it to "ComplexHV" maybe? I'm unsure what to do with this aspect of the package, since (i) it would be useful to comply with the VSA names, but (ii) its more intuitive to think of this hypervectors based on the kind of values they store (this is the convention I think we are using now). LMKWYT |
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
This is still a work in process and requires some tuning. Haven't decided on the proper way of encoding numbers (for which this should be most suited). Would require some work. Name might not be ideal. Does not follow our convention, though I would prefer it to be recognizable. Maybe |
|
Mmm, unsure what to make of this. I would need to think about it to see what makes sense. In my opinion, there is no need to adding all the VSA that exist, but it could be nice to have at least one for each numerical type (Bool, Int, Float, Complex, etc.). I think this is friendlier for newcomers but not that much for experts (maybe this is a question Denis Kleyko could help us answer) |
|
This is an important one to add. Will work furth on it after merging #40 in main so I can streamline the API. Will rename it |
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Implements FHRR, a work in progress.
Contains complex HV, easy to encode numbers