-
Notifications
You must be signed in to change notification settings - Fork 1
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
bugs #11
Labels
bug
Something isn't working
Comments
some test cases for the , TestLabel "foo" $ TestCase $ do
-- (/=)
x <- interpretUnsafe $ typeChecksWithDetails "(/=)"
print $ case x of
Right s -> s
Left errors -> show $ showError <$> errors
isRight x `shouldBe` True
-- (/=) (undefined :: a) (undefined :: a)
a <- interpretUnsafe $ typeChecksWithDetails "(/=) (undefined :: a) (undefined :: a)"
print $ case a of
Right s -> s
Left errors -> show $ showError <$> errors
isRight a `shouldBe` True
-- -- let res = neq (undefined :: a) (undefined :: a) where neq = (/=) in res
-- z <- interpretUnsafe $ typeChecksWithDetails "let res = neq (undefined :: a) (undefined :: a) where neq = (/=) in res"
-- print $ case z of
-- Right s -> s
-- Left errors -> show $ showError <$> errors
-- isRight z `shouldBe` True
-- let neq = (/=) in neq (undefined :: a) (undefined :: a)
-- y <- interpretUnsafe $ typeChecksWithDetails "let neq = (/=) in neq (undefined :: a) (undefined :: a)"
-- y <- interpretUnsafe $ typeChecksWithDetails "let neq :: Eq a => a -> a -> Bool = (/=) in neq (undefined :: a) (undefined :: a)"
y <- interpretUnsafe $ typeChecksWithDetails "let neq = (/=) in neq (undefined) (undefined)"
-- y <- interpretUnsafe $ typeChecksWithDetails "let neq :: Int -> Int -> Bool = (/=) in neq (undefined :: Int) (undefined :: Int)"
print $ case y of
Right s -> s
Left errors -> show $ showError <$> errors
isRight y `shouldBe` True |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
in-scope
out of scope
--maskBad
:fitExpr
cannot yet deal with types containing ambiguous type variables such aslength (undefined :: Foldable t => t a)
tyApp []
totyList
, ...)tyList
: ?calcLoss
is run twice. why?resolved
ensure type constraints are propagated to the type signatures of variant holes; for
max :: Ord a => a -> a -> a
,max _
now givesmax (undefined :: a)
rather than likemax (undefined :: Ord a => a)
. that's still simplified since formax _ _
,max (undefined :: Ord a => a) (undefined :: Ord a => a)
would be a bit inaccurate, in that the ordinal used in the holes must match, rather than being independent type variables, but bad hole filling there should get picked up by the compiler afterwards -- in which case perhaps this mostly matters if I'm actually using these hole type annotations myself (am I?).yet to see accuracy better than random, so far it just improved from below to that
type constraints are transferred to parameter types without filtering them to those type variables contained in the parameter type
ensure blocks are in some let construction!
let
commit broke main program behaviorfix constant references:
let zero = 0 :: Int in 0 :: Int
fn_types
now includes crap like("let add = (+)\n succ_ = succ\n in add succ_"," (Enum a, Num (a -> a)) => (a -> a) -> a -> a")
and("let nil = []\n add = (+)\n in add nil"," Num [a] => [a] -> [a]")
, which GHC analyzes asNon type-variable argument in the constraint: Enum (a -> a -> a)
fn_type_instantiations
ignores type constraintsnub
ingenInputs
cannot handle type variables, needs explicit type annotations. this breaks many Tamandu functions such asmax
, which for some reason now annotate it with types likeGen [a]
.fn_type_instantiations
has:("let nil = []\n max_ = max\n in max_ nil",["[a] -> [a]"])
.return types still containing type variables:
fn_io_type_instantiations
has("let replicate_ = replicate in replicate_",[(["Int","Bool"],"[a]")])
.there are some crap types involving constraints on non type variables -- this can be found in
fn_input_types
, and probably earlierfnOutputs
crashes withBool.succ: bad argument
must instantiate type constraints even in partial programs for e.g.
eq
/neq
:Ambiguous type variable ‘a0’ arising from a use of ‘/=’ prevents the constraint ‘(Eq a0)’ from being solved.
-- now inambiguous
stash. note that this may not actually matter as this problem seems to occur only for kind*
, i.e. non-functions. from that reasoning, I guess I'd want it to just reject these programs. it'd be nice if this could be done without the additional typechecks to prevent crashes tho...Hint race-condition (Hint race-condition #32)
Hint concurrent instances (Hint concurrent instances #34)
debug encoder learning test:
try lower lrsquare lossswap adam init - any variants gave NaNs...swap adam - GD randomly performs good or terrible as well...so far I've yet to see any accuracy
>0%
. this seems uh bad.The text was updated successfully, but these errors were encountered: