|
php:<?
function is_equal_equal($val1, $val2) {
if (($val1 == $val2) == ($val1 === $val2)) {
return true;
} else {
return false;
}
}
?>
|
#
?
Jul 15, 2016 09:22
|
|
|
|
| # ? May 21, 2024 05:54 |
|
|
No, see, if you were going down that route, you'd test that ($val1 == $val2) == ($val2 == $val1), in case equality isn't symmetric.
|
|
#
?
Jul 15, 2016 14:42
|
|
|
gently caress PHP. That is all.
|
|
#
?
Jul 15, 2016 15:25
|
|
|
php:<?
function is_equal_equal_equal($val1, $val2) {
if ((($val1 == $val2) == ($val1 === $val2)) ==== (($val1 == $val2) == ($val1 === $val2))) {
return true;
} else {
return false;
}
}
?>
|
|
#
?
Jul 15, 2016 15:28
|
|
|
PHP code:
|
|
#
?
Jul 15, 2016 15:58
|
|
|
TooMuchAbstraction posted:No, see, if you were going down that route, you'd test that ($val1 == $val2) == ($val2 == $val1), in case equality isn't symmetric. PHP's == is symmetric though, right? 
|
|
#
?
Jul 15, 2016 17:24
|
|
|
You know, sometimes I think I get too cute with commit messages. I just looked at one of my old repositories and my description of a bugfix (I was accidentally checking if an atomic bool was false instead of true) is "not is not not not".
|
|
#
?
Jul 15, 2016 17:32
|
|
|
VikingofRock posted:PHP's == is symmetric though, right? Symmetric equality or IEEE floating point math, pick one.
|
|
#
?
Jul 15, 2016 17:47
|
|
|
OddObserver posted:Symmetric equality or IEEE floating point math, pick one. IEEE floating point equality is symmetric. a == b <=> b == a. It's also transitive, because a == b & b == c => a == c. What it's not is reflexive (because of NaN). IEEE floating point is weird and insane for many reasons, but the reason equality is dodgy with it is because expressions that should be equal at infinite precision end up not being equal, not because it's not symmetric. Linear Zoetrope fucked around with this message at 17:59 on Jul 15, 2016 |
|
#
?
Jul 15, 2016 17:56
|
|
|
VikingofRock posted:PHP's == is symmetric though, right? Like most things in PHP, it works exactly the way you'd expect. The trouble with PHP, especially since the introduction of namespaces, is the things people do with it rather than the language itself. PHP is easy to use, so it tends to attract people who need something that's easy to use.
|
|
#
?
Jul 15, 2016 18:03
|
|
|
No, PHP's == absolutely does not work in exactly the way I'd expect.
|
|
#
?
Jul 15, 2016 18:11
|
|
|
Jsor posted:IEEE floating point equality is symmetric. a == b <=> b == a. It's also transitive, because a == b & b == c => a == c. What it's not is reflexive (because of NaN). IEEE floating point is weird and insane for many reasons, but the reason equality is dodgy with it is because expressions that should be equal at infinite precision end up not being equal, not because it's not symmetric. Along these lines, I thought PHP's == was symmetric but not transitive (because a and b can both be false-y but not == to each other).
|
|
#
?
Jul 15, 2016 18:20
|
|
|
PHP is bad and stupid. Use literally anything else if you can.
|
|
#
?
Jul 15, 2016 18:21
|
|
|
You should never use == with floats, anyway. You need something that allows you to set a precision.
|
|
#
?
Jul 15, 2016 18:37
|
|
|
Absurd Alhazred posted:You should never use == with floats, anyway. You need something that allows you to set a precision. That's not true, sometimes == with floats is very useful. In functions with no randomness, the same input will still yield the same output. It's only dodgy if you're relying on different inputs to yield a bit-identical output in a floating point calculation. These details also matter with the distinction between >= and >.
|
|
#
?
Jul 15, 2016 18:47
|
|
|
Absurd Alhazred posted:You should never use == with floats, anyway. You need something that allows you to set a precision. sprintf, best function ever.
|
|
#
?
Jul 15, 2016 18:48
|
|
|
Jsor posted:IEEE floating point equality is symmetric. a == b <=> b == a. It's also transitive, because a == b & b == c => a == c. What it's not is reflexive (because of NaN). IEEE floating point is weird and insane for many reasons, but the reason equality is dodgy with it is because expressions that should be equal at infinite precision end up not being equal, not because it's not symmetric. Doh. Got my symmetry and reflexivity reversed.... Well, it's not the most embarrassing thing in /this/ tread, at least.
|
|
#
?
Jul 15, 2016 19:20
|
|
|
Plorkyeran posted:No, PHP's == absolutely does not work in exactly the way I'd expect. Sure it does, it works bizarrely just like you'd expect something in PHP to work. 
|
|
#
?
Jul 15, 2016 19:55
|
|
|
Absurd Alhazred posted:You should never use == with floats, anyway. You need something that allows you to set a precision. What about for special casing to avoid dividing by zero?
|
|
#
?
Jul 15, 2016 20:11
|
|
|
VikingofRock posted:What about for special casing to avoid dividing by zero? It seems like that might be and allowable exception, but in situations where you will be dividing by a number that could be zero, you probably also don't want it to be too small, either.
|
|
#
?
Jul 15, 2016 20:15
|
|
|
Floating point comparison is unpredictable in PHP (or at least version 5.3), irregardless if it's using ==,or bccomp, or comparing round()ed numbers. It was delightful when we had to compare floats casted to strings because 13.61 (or something like that) wasn't equal to 13.61, no matter what. If I remember correctly, one side of comparison had to be first assigned to additional variable. Happened once - laughs were had, hair were lost, as was the sanity. Fun times. Still my favourite is adding an empty comment to the source code, to make certain Zend logic work. And it happened suddenly - everything works fine, then forms start throwing errors on initialization, then I add some debugging, error disappears, but reappears when I remove the debugging, then I add a comment to change filesize of the file, that does the trick. No caching of source code, no opcache, just 
|
|
#
?
Jul 15, 2016 20:22
|
|
|
Absurd Alhazred posted:It seems like that might be and allowable exception, but in situations where you will be dividing by a number that could be zero, you probably also don't want it to be too small, either. Fair enough. I could see preferring huge numbers to Infinity though, since big numbers are at least more well behaved (as far as I know).
|
|
#
?
Jul 15, 2016 21:04
|
|
|
VikingofRock posted:Fair enough. I could see preferring huge numbers to Infinity though, since big numbers are at least more well behaved (as far as I know). Isn't the result of dividing a sufficiently large number by a sufficiently small (but nonzero) one still infinity?
|
|
#
?
Jul 16, 2016 00:59
|
|
|
VikingofRock posted:What about for special casing to avoid dividing by zero? Don't you end up missing dividing by -0 then?
|
|
#
?
Jul 16, 2016 02:33
|
|
|
leper khan posted:Don't you end up missing dividing by -0 then? No, -0 == 0.
|
|
#
?
Jul 16, 2016 02:41
|
|
|
rjmccall posted:No, -0 == 0. But 1/-epsilon is really really negative, while 1/+epsilon is really really positive.
|
|
#
?
Jul 16, 2016 02:48
|
|
|
Absurd Alhazred posted:But 1/-epsilon is really really negative, while 1/+epsilon is really really positive. Most of the time when I worry about dividing by zero, all I'm looking to prevent is the exception; I don't care if I get wildly weird numbers as long as the CPU doesn't just throw up its hands and go "nope, gently caress it, I'm out."
|
|
#
?
Jul 16, 2016 03:16
|
|
|
Absurd Alhazred posted:But 1/-epsilon is really really negative, while 1/+epsilon is really really positive. For that matter, 1/-0 is -Inf while 1/+0 is +Inf. FP equality doesn't imply perfect substitutability. TooMuchAbstraction posted:Most of the time when I worry about dividing by zero, all I'm looking to prevent is the exception; I don't care if I get wildly weird numbers as long as the CPU doesn't just throw up its hands and go "nope, gently caress it, I'm out." FP divide-by-zero doesn't trap unless you've in some weird configuration or have non-IEEE hardware.
|
|
#
?
Jul 16, 2016 03:17
|
|
|
rjmccall posted:FP divide-by-zero doesn't trap unless you've in some weird configuration or have non-IEEE hardware. Oh, you're right, I was thinking of integer division. My bad.
|
|
#
?
Jul 16, 2016 03:22
|
|
|
TooMuchAbstraction posted:Oh, you're right, I was thinking of integer division. My bad. That producing a SIGFPE always kinda bothered me.
|
|
#
?
Jul 16, 2016 03:35
|
|
|
Often with floats it is provable that x <= y and to test x == y to check a special case at an endpoint is valid. Or say you have sin(x)/x and want 1, not NaN, at zero.
|
|
#
?
Jul 16, 2016 03:59
|
|
|
Cuntpunch posted:
This is the greatest horror. Writing a novel in your comment that's made illegitimate on the next commit yet everyone is forced to read it and try to get in that person's mind if they want to work in that file.
|
|
#
?
Jul 16, 2016 04:05
|
|
|
in php, '==' is 'equivalence' and '===' is 'equality'. Similarly '!=' and '!=='. The main difference is that the extra '=' implies a type check, as well. The problem comes down to PHP's VeryWeakTypes(tm) - until you force a variable to be a string or an integer (or a float, etc.) then it's not actually certain what it is.  In short: php:<? // strings vs integers '' == 0; // true '0' == 0; // true '' == '0'; // false // strings, booleans, integers, nulls, arrays. '' == false; null == false; 0 == false; '0' == false; [] == false; 'anything other than 0' == true; 1 == true; -1 == true; [0] == true; ['0'] == true; ?> bobthecheese fucked around with this message at 08:49 on Jul 16, 2016 |
|
#
?
Jul 16, 2016 08:47
|
|
|
Yeah, but those languages don't have the feature where two number-like strings are parsed to numbers and then tested.code:
|
|
#
?
Jul 16, 2016 09:18
|
|
|
Suspicious Dish posted:Yeah, but those languages don't have the feature where two number-like strings are parsed to numbers and then tested. Wait doesn't php also have the thing where "12ab" == "12cd"? So that would mean that "1d3" == "1d4", but "1e3" != "1e4", right? 
|
|
#
?
Jul 16, 2016 09:42
|
|
|
weak typing is a non-word it's just the general language misfeature of allowing implicit type conversions in situations that can easily cause bugs even "strongly" typed languages often do really stupid poo poo in terms of implicit conversions to boolean that will cause bugs forever and ever, although i guess sane linters will usually warn about it
|
|
#
?
Jul 16, 2016 09:49
|
|
|
C++ is considered strongly typed. C++ implicitly casts to bool (this could be blamed on the C legacy). However, c++ even has built-in implicit cast operators that create bugs including implicit casts to bool, so uh make your own determination on c++'s position there. Some would argue that that's just users hanging themselves and abusing the features, but I disagree. Python is often considered by proponents to be strongly typed. The language encourages pervasive bug-creating casting to bool.
|
|
#
?
Jul 16, 2016 10:02
|
|
|
spent a day debugging a mysterious stack overflow caused by va_args pulling garbage arguments because of insufficient stack alignment
b0lt fucked around with this message at 10:26 on Jul 16, 2016 |
|
#
?
Jul 16, 2016 10:13
|
|
|
did you know in python that an implicit cast to bool for one of their time types will be false if the instance is either null or exactly midnight? do you agree this is really stupid and can cause bugs? let's please stop using the weak/strong language terminology and just agree implicit type coercions are very bad except in very limited cases
|
|
#
?
Jul 16, 2016 10:21
|
|
|
|
| # ? May 21, 2024 05:54 |
|
|
quote:There was quite some pushback at the time since many of us feared that the new type and constants would be used by Python newbies to restrict the language's abilities, but Guido was adamant that we were just being pessimistic: nobody would ever understand Python so badly, for example, as to avoid the perfectly natural use of False and True as list indices, or in a summation, or other such perfectly clear and useful idioms.
|
|
#
?
Jul 16, 2016 10:38
|
|