Skip to content
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

Split Octonion into another package? #90

Closed
hyrodium opened this issue Aug 20, 2022 · 7 comments · Fixed by #100
Closed

Split Octonion into another package? #90

hyrodium opened this issue Aug 20, 2022 · 7 comments · Fixed by #100
Labels

Comments

@hyrodium
Copy link
Collaborator

I think the practical uses of Quaternion and Octonion are totally different, and these types don't have to be provided in one package.

@sethaxen
Copy link
Collaborator

I agree, but also, I don't see major benefits from splitting Octonion to its own package. If it's here, we can have a uniform API and implementation, and we support legacy code. I doubt its inclusion changes the load time of this package much.

Probably DualQuaternion could/should be its own package, as this is where our DualNumbers dependency comes from. Without this dependency, the package loads in ~12ms even with Octonion, but with this dependency the load time is ~130ms. And as noted in #79, DualQuaternion could maybe be delivered without any additional code by releasing the Real type constraint on Quaternion.

@sethaxen
Copy link
Collaborator

sethaxen commented Sep 2, 2022

It seems no GitHub-hosted packages use Octonions in package code. LinearMaps.jl uses it in their tests. This is a good argument for moving Octonions to its own package. Do octonions have geometric applications? Should an Octonions.jl package live in JuliaGeometry as well or moved to an org like JuliaMath?

@hyrodium
Copy link
Collaborator Author

hyrodium commented Sep 4, 2022

Currently, I don't have applications for Octonion. Should we ask this topic on Julia Discourse or Slack?

@sethaxen
Copy link
Collaborator

As others commented on Slack, either JuliaMath or JuliaGeometry would be a good host org for this package, though JuliaGeometry might make more sense due to its historical connections to the Quaternions package.

Neither of us have rights in these orgs, but we don't need to to make the package and register it; it's easy to migrate the package to an org after registration. I do think it's important to preserve the contribution history, which we can do with git filter-branch. I've done this before, so I can make the repo, add you as an admin on it, and register it. Then we can transfer it when we get the ear of someone with the necessary org admin rights.

@hyrodium
Copy link
Collaborator Author

I see. I don't have experience with git filter-branch, so it would be nice to be invited to your repository:+1:
After creating the repo, we can add warnings to Octonion constructor, and remove it in the next breaking release.

@sethaxen
Copy link
Collaborator

I've created the repo at https://github.com/sethaxen/Octonions.jl and invited you to be a collaborator.

@sethaxen
Copy link
Collaborator

I registered the package as-is to start the clock for the 3-day embargo: JuliaRegistries/General#68578. We can make any other changes we like after the initial release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants