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

Reason behind Math.NumberTheory.Powers.Modular deprecation? #219

Open
Javran opened this issue Feb 12, 2022 · 4 comments
Open

Reason behind Math.NumberTheory.Powers.Modular deprecation? #219

Javran opened this issue Feb 12, 2022 · 4 comments

Comments

@Javran
Copy link

Javran commented Feb 12, 2022

I see the module is deprecated in 77e70a1 but I'm not really sure about the rationale, nor do I find any migration guide on this.

Tell me if I'm not using Data.Mod.Word right, but it becomes painfully verbose when m is only available at runtime, for example powModWod becomes this:

powModWord :: Word -> Word -> Word -> Word
powModWord b e m = case someNatVal (fromIntegral m) of
  Just (SomeNat (_ :: Proxy md)) ->
    unMod (fromIntegral @_ @(Mod md) b ^% e)
  Nothing -> error "unreachable"

Not to mention language pragmas one has to enable.

@Bodigrim
Copy link
Owner

As described in documentation, powMod is dangerously polymorphic, as we have little idea how a behaves when multiplication overflows. And powModInteger can be accessed directly from integer-gmp, so arithmoi does not bring much added value.

@Javran
Copy link
Author

Javran commented Feb 15, 2022

I see - wasn't aware of integer-gmp and powModInteger it provides, that would also do (probably also mention that in addition to mod package in the doc?). I agree with you on powMod, but I feel powModWord is still worth keeping just so that user doesn't feel the need of type level naturals don't have to route things through it.

I also just noticed that Math.NumberTheory.Powers.Modular calls GMP interface directly while Data.Mod.Word does it a bit more on the Haskell side - performance speaking is either approach better than the others or it's a bit situational?

@Bodigrim
Copy link
Owner

I believe that type level numbers provide a less error-prone way of doing modular arithmetic, and API should encourage users into this route. A PR, adding a mention of powModInteger from integer-gmp and naturalPowMod from ghc-bignum, would be welcome.

Data.Mod.Word is slightly (10%-25%) faster than GMP call.

@Javran
Copy link
Author

Javran commented Feb 16, 2022

I understand the benefit of having it on type level, probably wouldn't commit to it though - my major concern are (1) the machinery is a bit much converting between type and term level (as demostrated in OP) (2) some constrants tend to spread everywhere, in this case it's KnownNat.

I'll see if I can find time to do a PR, probably also refer to this issue should powModWord be gone in future.

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

2 participants