5 ms·
> such as (1/0).foo.foo (and yes you need the second .foo…) I don't understand the nuance here. In my Firefox developer tools, I can do the following: > (1/0)
by banana_smoothie 7y ago
> such as (1/0).foo.foo (and yes you need the second .foo…)
I don't understand the nuance here. In my Firefox developer tools, I can do the following:
> (1/0).foo.foo
---> TypeError: (intermediate value).foo is undefined
> (1/0).foo
---> undefined
> (1/1).foo.foo
---> TypeError: 1.foo is undefined
> Infinity.foo.foo
---> TypeError: Infinity.foo is undefined
> undefined.foo
---> TypeError: undefined has no properties
While these are all different errors, I don't really understand why the '(1/0).foo.foo' case is an example of a _trapped_ error, but the others are not.
- cyphar 7y agoThe point they were making is that (1/0).foo is not an error, as it returns a value.
- chubot 7y agoNone of those are trapped errors. In Python, Java, C, OCaml, and most other languages, 1 / 0 aborts the program. That is, division by zero is a trapped error. In JavaScript, it's not. It keeps going and lets you do stuff like access nonexistent properties .foo on the result, which are also untrapped errors. So JavaScript is unsafe in Cardelli's terminology. It gives you untrapped errors rather than trapped ones. The program keeps chugging along until you find out later and have to trace backwards to the bug.
- tome 7y agoIt's Infinity in Haskell Prelude> 1.0 / 0.0 :: Double Infinity
- WoodTree 7y agoBecause / is floating point division, and infinity is a defined value in floating point numbers. Try it again with div for integer division.
- chubot 7y agoThanks, removed. I’m sort of surprised by that since my memory is that infinity isn’t a real number, rational, etc. That is, does infinity in Haskell obey some algebraic laws?
- WoodTree 7y agoInfinity is a valid floating point number in the ISO standard. However integer division by 0 isn’t. div 1 0 will fail.
- chubot 7y agoYeah it's an interesting case. It appears that Inf is in floating point to AVOID a trapped error. This answer has an interesting way of looking at it. If you go on the theory that floating points are supposed to represent reals, then in floating point, you can't tell if a value is actually zero or just indistinguishably close to zero. In the case of "indistinguishably close to zero", you're getting the wrong answer, and the program doesn't halt. It keeps on chugging doing bad math. So that's an untrapped error, and it's UNSAFE by Cardelli's definition. https://cs.stackexchange.com/questions/82811/why-do-floating-point-values-have-infinity https://cs.stackexchange.com/questions/82811/why-do-floating... The key point is that "safe" sometimes means "crashes" and sometimes means "doesn't crash". It's an auto-antonym in that sense. A broader definition is "errors are flagged as early as possible", including with seg faults / hardware exceptions.
- WoodTree 7y agoFloats aren’t reals, at best they are an approximation for certain calculations. +0 and -0 are defined and distinct floating point numbers. Floating point math is known to be problematic and does not evenly distribute numbers on the real line either. There are numerical methods used for reducing error on floating point operations when it is acceptable. Otherwise fixed point or intervals may be used.
- WoodTree 7y agoThis is false. Integer division by zero is undefined, but floating point division is perfectly fine. Many languages have different operators to distinguish floating point and integer division, like pythons / for floats and // for integers.