linear diophantine equations#220
Conversation
|
|
||
| -- | Produces an unique solution given any | ||
| -- | arbitrary number k | ||
| runLinearSolution :: _ => LinearSolution b -> b -> (b, b) |
There was a problem hiding this comment.
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.
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.
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.
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.
|
|
||
| -- | 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.
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.
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.
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.
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.
| -- Module for Diophantine Equations and related functions | ||
|
|
||
| {-# LANGUAGE PartialTypeSignatures #-} | ||
| {-# OPTIONS_GHC -Wno-partial-type-signatures #-} |
There was a problem hiding this comment.
Is it difficult to provide full type signatures?
2 participants
These come up quite a bit, and I've looked for them in arithmoi more than once!
Kuṭṭaka,PogoandRaceare usage examples if you will, rather than something I want into the library.Pogoin particular is pretty interesting: any Brainfuck program that does not contain nested loops can be reduced to a Pogo problem!