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

RescaleCyc Usability #28

Open
crockeea opened this issue Mar 4, 2017 · 0 comments
Open

RescaleCyc Usability #28

crockeea opened this issue Mar 4, 2017 · 0 comments

Comments

@crockeea
Copy link
Collaborator

crockeea commented Mar 4, 2017

Currently it's unclear which way to associate product rings for optimal efficiency without inspecting our code. This makes it difficult for users to write the best code. Is there some way we can improve this situation?

For example, if I do a keySwitch where zq ~ b and zq' ~ (a,b), we end up calling the optimized Cyc.RescaleCyc instance. However, if I choose zq' ~ (b,a), I end up with the generic, less efficient Cyc.RescaleCyc instance. One way to resolve this particular idiosyncrasy is to add a third Cyc.RescaleCyc instance for (a,b) to a.

However, another overlapping instance only compounds this problem: The overlapping RescaleCyc instances means that some valid rescales are not allowed. Take for example, rescaling from three moduli to one like this: ((a,b), c) -> c. This matches the instance head for the optimized instance, but not the instance constraints, since we don't have, e.g. Unbox (LiftOf (a,b)) ~ Unbox Integer. Thus the compiler throws an error. If we instead remove the optimized instance altogether, the compiler picks the generic instance and accepts the code, since the generic instance doesn't require Unbox Integer.

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

No branches or pull requests

1 participant