If you are dividing two numbers with no prior knowledge of these numbers or any reasonable assumptions you can make and this code is used where you can not rely on the caller to catch an exception and the code is critical for the product, then this is necessary. If you are actually doing safety critical software, e.g. aerospace, medicine or automotive, then this is a good precaution, although you will not be writing…
LLMs are mortally terrified of exceptions
21–30 of 157 posts
Re: LLMs are mortally terrified of exceptions
#22If you are dividing two numbers with no prior knowledge of these numbers or any reasonable assumptions you can make and this code is used where you can not rely on the caller to catch an exception and the code is critical for the product, then this is necessary. If you are actually doing safety critical software, e.g. aerospace, medicine or automotive, then this is a good precaution, although you will not be writing…
I might agree with that, and maybe the example posted by Karpathy is not the greatest, but what I'm constantly being faced with is try catches where it will fail silently or return a fallback/mock response, which essentially means that system will behave unexpectedly in a more subtle way down the line while leaving you clueless to as what the issue was. I have to constantly remind Claude that we want to fail fast.
Just raise god damn it
Re: LLMs are mortally terrified of exceptions
#23Re: LLMs are mortally terrified of exceptions
#24Re: LLMs are mortally terrified of exceptions
#25I mean, the first three cases are just attempting to turn dynamic into static typed... right? maybe just don't aim for uber-safety in a dynamically typed language? :shrugs: (I used to look out for kaparthy's papers ten years ago... i tend to let out an audible sigh when i see his name today)
I for one really enjoy both his longer form work and his shorter takes.
Re: LLMs are mortally terrified of exceptions
#26Given that the output describes the function as being done "with extraordinary caution, because you never know what can go wrong", i would guess that the undisclosed prompt was something similar to "generate a division function in python that handles all possible edges cases. be extremely careful". Which seems to say less about LLM training and more about them doing exactly what they are told.
1. the code is actually wrong (and is wrong regardless of the absurd exception handling situation)
2. some of the exception handling makes no sense regardless, or is incoherent
3. a less absurd version of this actually happens (edit: commonly in actual irl scenarios) if you put emphasis on exception handling in the prompt
Re: LLMs are mortally terrified of exceptions
#27This is just AI trying to tell us how bad we designed our programming languages to be when exceptions can be thrown pretty much anywhere
So you think java's checked exceptions are a better model? No opinion myself, but that way seems widely considered bad too.
Also, division by zero should return Inf
Re: LLMs are mortally terrified of exceptions
#28Re: LLMs are mortally terrified of exceptions
#29Turns out computer math is actually super hard. Basic operations entail all kinds of undefined behavior and such. This code is a bit verbose but otherwise familiar.
# Step 3: Preemptively check for catastrophic magnitude differences
if abs(a) > sys.float_info.max / 2:
logging.warning("Value of a might cause overflow. Returning infinity just to be sure")
return math.copysign (float('inf'), a)
if abs(b)
Does the above code make any sense? I've not worked with this sort of stuff before, but it seems entirely unreasonable to me to check them individually. E.g. if 1 < b < a, then it seems insane to me to return float('inf') for a large but finite a.Re: LLMs are mortally terrified of exceptions
#30I know it's Karpathy, which is why the entire prompt is all the more important to see.