.NET's Sometimes Nonsensical Logic
-
So if you asked your sergeant if your platoon was all present and correct when in fact they'd all been blown to smithereens and the platoon was now devoid of soldiers, you would still expect the answer "Yes"?
In your example, the sergeant is probably asking about the set of soldiers assigned to the platoon (regardless of status). In which case, the set isn't empty, and the answer is "no". However, if the sergeant was asking if all soldiers in your platoon who were capable of showing up were there, then the answer is "yes". Note: technically, the set still isn't empty, as you are presumably in your own platoon. However, the logic would still apply if the question was asked about another platoon where no one was left alive - everyone who was capable of showing up would be there...
-
I agree. I find the behavior of
All()on an empty collection strange. If I'm told "all the members of a list of integers are greater than zero" I would expectAny(p => p > 0)on that list to returntrue. But if the list is empty,Any(p => p > 0)returnsfalse. That seems wrong. /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Good point. So, you're saying that if `list.All(>0)` then we should be able to assume that `list.Any(>0)` is also true? Makes sense. However, it also makes sense that if `list.All(>0)` then `list.Any(<=0)` should be false, which it is, and we should be able to expect that if not `list.Any(<=0)` then `list.All(>0)` would be true, which it is (but wouldn't be if we changed it to work in your example). The problem is that either way, when working with null sets, we end up with some relationship which isn't fully transitive. For example, in SQL `x = null` and `x <> null` are both false (regardless of whether x is null or not, the only way to test for null is explicitly: `x is null` or `x is not null` ).
-
I brought it up a while back and there was some back and forth on it. Apparently, malloc( 0 ) not returning NULL is deliberate. Here is what GCC does with some short bit of code printf("Hello world!\n"); printf( "call malloc(0)\n" ); sz = (char*)malloc(ZERO); printf( "Errno %d\n", errno ); if( sz == NULL ) printf( "returned NULL allocated zero bytes\n"); else printf( "NULL not returned from malloc, allocated 8 bytes\n" ); Hello world! call malloc(0) Errno 0 NULL not returned from malloc, allocated 8 bytes Apparently this is allowed by GCC. The argument is that it was successful Haven't tried it in VS.
"A little time, a little trouble, your better day" Badfinger
jmaida wrote:
Apparently, malloc( 0 ) not returning NULL is deliberate.
Standard says either is allowed.
jmaida wrote:
allocated 8 bytes
Without the actual standard, which costs money, I suspect the following is authoratative enough. MEM04-C. Beware of zero-length allocations - SEI CERT C Coding Standard - Confluence[^] Keep in mind that without that reference I thought it might have been undefined. Which means it could throw a system exception too. So probably better the way it is.
-
I know I may be alone on this but .. I just do not like Linq. It biases for easy-to-write at the expense of easy-to-understand (to say nothing of perf implications of making non-inlineable callbacks for each item in the list). Semantic details (like your example) matter, and I've spent way more hours debugging unexpected nuances like this, than I've saved by not writing a foreach loop in a little helper method.
ShawnVN wrote:
I just do not like Linq.
Yep. And even worse when it was forced down as a database layer. Now I have to do a database profile on every single usage just to make sure it actually does the expected SQL rather than deciding to do something non-sensical.
-
jmaida wrote:
Apparently, malloc( 0 ) not returning NULL is deliberate.
Standard says either is allowed.
jmaida wrote:
allocated 8 bytes
Without the actual standard, which costs money, I suspect the following is authoratative enough. MEM04-C. Beware of zero-length allocations - SEI CERT C Coding Standard - Confluence[^] Keep in mind that without that reference I thought it might have been undefined. Which means it could throw a system exception too. So probably better the way it is.
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
The
Allseems to work the same as any other language conjunctions. Search for "vacuous truth" to read about the underlying set theory origin of this definition in logic, which all (or at least all non-esoteric) programming languages define all. The same logic you can find at least in Python, JavaScript, C/C++, PHP, etc. But on the other hand, if C# makes the methodAlldoes not return true without error on empty set, it will make C# special and unique language, so there might be benefits. -
You're not wrong. But you're not right either. Maths vs. Words :-D
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
Have you ever heard of first-order logic - the logic which has been used formally for about 200 years (and informally much longer; on the order of 2000 years) for all sound reasoning in mathematics? Where it is obviously correct that "there is no x where P(x) is false" is equivalent with "for all x, P(x) holds" - because otherwise, that calculus would explode in your face ... Have you ever heard about vacuous truth? If not, please take some time to learn about these things. That's neither a .Net nor a Microsoft thing - it's basic logic knowledge. H.M.
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
One more for MS is right here (what??? how is that possible.) Not really different from what others already wrote, but this is how I see it... For me, Any(x) is the same as All(!x) so this must be true: if list.Any(x) == false then list.All(!x) == true which is true with the current implementation. What you expect results in: list.Any(x) == false and list.All(!x) == false. ... it's correct under your assumption, but to me it's illogic logic :).
-
In your example, the sergeant is probably asking about the set of soldiers assigned to the platoon (regardless of status). In which case, the set isn't empty, and the answer is "no". However, if the sergeant was asking if all soldiers in your platoon who were capable of showing up were there, then the answer is "yes". Note: technically, the set still isn't empty, as you are presumably in your own platoon. However, the logic would still apply if the question was asked about another platoon where no one was left alive - everyone who was capable of showing up would be there...
The officer doing the asking is enquiring about the present state of his platoon, not what it might have been. He wants to know how many men he has left in that platoon, if any (he's a practical chap). The Sergeant isn't necessarily a member of the platoon in question. It's a valid question before possibly sending the platoon out on another patrol, one which requires a practical answer. A platoon now devoid of soldiers wouldn't perform well on patrol.
-
The officer doing the asking is enquiring about the present state of his platoon, not what it might have been. He wants to know how many men he has left in that platoon, if any (he's a practical chap). The Sergeant isn't necessarily a member of the platoon in question. It's a valid question before possibly sending the platoon out on another patrol, one which requires a practical answer. A platoon now devoid of soldiers wouldn't perform well on patrol.
Exactly! The officer needs to know how many men are available (a platoon of one wouldn't perform well either). He could have asked, "How many are available?" But he didn't (in this example). Presumably he can see there's no one there, so he effectively asked, "Is this everyone in the platoon?" The correct answer at that point is "Yes", at which point he knows what he has to work with (even if it's zero). To answer No at this point would imply that there are others who are not present, which isn't the case. If we were to write that in code, it would be Platoon.AreAllPresent(), and the result would be True as long as no members of the Platoon are absent (even if there are no members of the Platoon).
