-
Notifications
You must be signed in to change notification settings - Fork 40
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
linear diophantine equations #220
base: master
Are you sure you want to change the base?
Conversation
Math/NumberTheory/Diophantine.hs
Outdated
|
||
-- | Produces an unique solution given any | ||
-- | arbitrary number k | ||
runLinearSolution :: _ => LinearSolution b -> b -> (b, b) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add tests, showing that
a) everything this function returns is a solution,
b) all possible solutions are generated by this function by supplying different k
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are either no solutions (handled by Maybe), or an infinite number of solutions. I'll add some test cases, but I cannot check it exhaustively
linearTest :: (a ~ Integer) => a -> a -> a -> a -> Bool | ||
linearTest a b c k = | ||
case solveLinear Lin {..} of | ||
Nothing -> True -- Disproving this would require a counter example |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that solveLinear = const Nothing
passes this test. Can we come up with a test which requires solveLinear
return Just{}
at least in some cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! I think this is easier to see in terms of my Pogo problem D = H*L (mod C)
where H
is the solution. All we have to do is make sure L
is coprime to C
, because sort [mod (h*l) c | h <- [0..pred c]] == [0..pred c]
, which includes D
.
Math/NumberTheory/Diophantine.hs
Outdated
|
||
-- | A linear diophantine equation `ax + by = c` | ||
-- | where `x` and `y` are unknown | ||
data Linear a = Lin { a,b,c :: a } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes a
, b
and c
globally defined functions, stealing them from any other potential usage. Could you please use something more specific and less likely to clash? Same applies to LinearSolution
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that is a problem I am more inclined to not have names at all, or something like a_var
, or removing Linear
all together in favor of function arguments? The current names are what is used in the literature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not as attached to the names in LinearSolution
. The only reason I have it rather than returning Maybe (Int -> (Int, Int))
is that runLinearSolution
is a very simple function, and applying it is technically lossy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the spam.
I am leaning towards just removing Linear
. It is only used in one function- the user can create their own data type if they really want it.
On the other hand, I know that Linear
has a sensible Semigroup
instance, and many analogues of liftA2 f
makes sense for it:
-- Basically `liftA2 (+)`
-- (a1+a2)*x + (b1+b2)*y = c1 + c2
--
add (Lin a1 b1 c1) (Lin a2 b2 c2) =
Lin (a1+a2) (b1+b2) (c1+c2)
I didn't add instances because I didn't want to bloat this PR.
@@ -1,8 +1,14 @@ | |||
-- Module for Diophantine Equations and related functions | |||
|
|||
{-# LANGUAGE PartialTypeSignatures #-} | |||
{-# OPTIONS_GHC -Wno-partial-type-signatures #-} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it difficult to provide full type signatures?
These come up quite a bit, and I've looked for them in arithmoi more than once!
Kuṭṭaka
,Pogo
andRace
are usage examples if you will, rather than something I want into the library.Pogo
in particular is pretty interesting: any Brainfuck program that does not contain nested loops can be reduced to a Pogo problem!