builds an Y containing booleans, which may subvert expectations (Python having no kind of contracts anywhere, forcibly nonstated expectations ).
Letâs apply the first part of âbe conservative of what you send, liberal in what you acceptâ
def nn_model_test(target):
np.random.seed(1)
X = np.random.randn(2, 4)
Y = (np.random.randn(1, 4) > 0) # return array of numeric, not of boolean
n_h = 5
...
That is a good point, but, again, unless it is critical, which I think you agreed it is âlittleâ instead, it might not be addressed any time soon. I am sure you understand this
Indeed, Python is a bit flexible in terms of data type. It brings, in some sense, convenience but it also requires, e.g. library developers, to handle such ambitguity or it just throws an error.
Have you heard of âType Hintâ? Itâs becoming popular to specify an expected type for each variable in Python, though the expectations are not enforced - it is like part of the documentation effort. Below is an example:
I definitely am using the type hints now. They are free checks for the write-time type checker (which sometimes canât do much, as soon as type Any is encountered, all bets are off) and free documentation for the next person who reads the code.
I deeply mistrust code that doesnât have them, itâs like driving a car with the windshield covered. Missing type enforcement / missing compile-time checks / dynamic typing was acceptable when programs were small, theory and practice of type checking was nonexistent or esoteric and computers were weak (canât run the prover). No longer!
If I have to get up at 02:00 to take a look at a runtime error, it better be interesting, not due to an âunexpected typeâ.
But type hints are only getting popular, so I am sorry to tell you that you may not see them in many deep learning repositories that will be useful for your future adventure.