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

bugs #11

Open
17 of 21 tasks
KiaraGrouwstra opened this issue Jan 21, 2020 · 1 comment
Open
17 of 21 tasks

bugs #11

KiaraGrouwstra opened this issue Jan 21, 2020 · 1 comment
Labels
bug Something isn't working

Comments

@KiaraGrouwstra
Copy link
Owner

KiaraGrouwstra commented Jan 21, 2020

in-scope

out of scope

  • type constraints bolted on to type parameters might hinder their lookup in case that's done without this?
  • --maskBad: fitExpr cannot yet deal with types containing ambiguous type variables such as length (undefined :: Foldable t => t a)
  • type variables can only be deduped if made equivariant to type variable name (standardize: name Haskell #1 for first occurring type variable, normalize tyApp [] to tyList, ...)
    • dedupe: do by instantiated function type signature sets instead? or better yet, the whole io map at once.
    • tyList: ?
  • on epoch 0, 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 gives max (undefined :: a) rather than like max (undefined :: Ord a => a). that's still simplified since for max _ _, 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 behavior

  • fix 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 as Non type-variable argument in the constraint: Enum (a -> a -> a)

  • fn_type_instantiations ignores type constraints

  • nub in genInputs cannot handle type variables, needs explicit type annotations. this breaks many Tamandu functions such as max, which for some reason now annotate it with types like Gen [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 earlier

  • fnOutputs crashes with Bool.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 in ambiguous 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 lr
    • square loss
    • swap adam init - any variants gave NaNs...
    • swap adam - GD randomly performs good or terrible as well...
    • try without model -- fixes it, implying this is a thing about my forward fn!
    • check gradients not too weird (e.g. close to 0?) -- printing params shows the independent bits go to 0 after the optim step. possibly the biases which makes sense. still need to check the gradients.
    • one-hot op may not have gradient? use one-hot tensor as mask as dummy op to make it differentiable
  • so far I've yet to see any accuracy >0%. this seems uh bad.

@KiaraGrouwstra
Copy link
Owner Author

some test cases for the (==) type ambiguity error:

    , 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
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant