|
I figured I might be in the minority here, but suprised how overwhelmingly folks agree with Microsoft on [Empty].All() == true.
Mathematically I totally get it. None of the items is false. Fine.
But consider a real-world application and what I, as someone giving orders, would expect:
Darth Vader is commanding the Imperial fleet and approaching a suspected Rebel base but is uncharacteristically concerned about civilian casualties for once. "Are there any civilian inhabitants of this planet, commander?"
"No, Lord Vader," the commander replies.
"Good, so they're all rebels?"
"Yes, milord."
"Sterilize the planet," Vader commands.
The fleet spends the next four hours bombarding the planet, burning the entire surface and boiling the oceans, while Vader waits impatiently as he is eager to proceed to the next suspected target. Finally when the carnage is over, Vader asks, "Well done, Commander. How many Rebels did we kill?"
"Well, um, none, milord," the commander meekly replies.
"What do you mean?"
"The planet was uninhabited."
Vader initiates a force choke. "You said there were Rebels here!"
The commander struggles to spit out his last words.
"I said the inhabitants were all Rebels, not that there were any inhabitants."
|
|
|
|
|
This may be considered a "dumb" response, but why not check for null and if not null, get a count, on your collection before attempting an action that presumes items in the collection?
|
|
|
|
|
|
That was an interesting read, as was this:
Vacuous truth - Wikipedia
I don't pretend to be a mathematician, but if all conditions can be satisfied by all members of an empty set, then all members of the empty set would satisfy the condition that their parent set is non-empty.
If we took the other approach and said that no condition can be satisfied by all members of an empty set, then all members of the empty set would fail to satisfy the condition that their parent set is empty.
Both approaches lead to contradictions, which is why the answer seems like it should be undefined.
|
|
|
|
|
|
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.
|
|
|
|
|
The All seems 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 method All does not return true without error on empty set, it will make C# special and unique language, so there might be benefits.
|
|
|
|
|
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.
|
|
|
|
|
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  .
|
|
|
|
|
What was it like, being a WWII baby?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
The idea is that, being born on February 29th, you only have a birthday once every 4 years...and so you get older at a pace of 1/4th of everybody else.
Someone born on February 29th 1940 would only be "21" today...
Ok, I'm done mansplaining.
|
|
|
|
|
Thank you - I'd forgotten about the leap year "calculation"
|
|
|
|
|
OK Thanks for the explanation. Makes sense.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Actually you get older at the same rate as anyone else, but you only get 1/4 of the parties.
Alternatively your lifespan is only a quarter of those born in a "normal" year and you can expect to be an ex-you before you reach 22.
Either way, it seems a bum deal to me.
|
|
|
|
|
Realistically it's more about bragging rights than anything else.
Now imagine twins being born on a February 29th.
|
|
|
|
|
Worst case: Twins born 29 Feb 23:45 and 01 Mar 00:15 (or 28 Feb 23:45 and 29 Feb 00:15)
You can get a similar effect when Daylight Saving Ends (or Starts - I am never sure which way they go). You could have the eldest one born at 01:45, then clocks go back and the younger one is born at 01:30 but both have the same birthday.
|
|
|
|
|
Long ago (i.e. pre-URL) I read a similar story about a married couple who celebrated his and her wedding day on two different dates. During WW2 they were engaged, but he was called for war service before they had had an opportunity to arrange a marriage. They both feared that he might be lost in a battle, and if that happened they would want to be married.
So they had a marriage over military radio: She went to the nearest military camp, with her priest, and called up the station where the groom was located, where he had an army priest available, and they gave their "I do!" over the radio.
The thing was, the groom was stationed in the Pacific, across the date line. So although they were married at the same GMT time, the date was different for the two. The story as I heard it didn't reveal whether their marriage certificate stated one, the other or both dates, only that the groom returned safely home, and every year thereafter they celebrated for two days, one day for her and one day for him.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Conventionally there would only be one wedding registered, hence one wedding certificate which would normally show the date where it was registered.
|
|
|
|
|
jsc42 wrote: You could have the eldest one born at 01:45, then clocks go back and the younger one is born at 01:30 but both have the same birthday.
...and the youngest can claim to be the oldest...?
|
|
|
|
|
I think there is a well known story like that in the Book of Books.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
interesting thing, in my company (300+ employees), no one was born on february 29.
or (conspiracy) they just put either february 28 or march 1st on the public facing anniversary web page.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Well, you have less than 0.25 odds.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Maximilien wrote: (300+ employees),
Even assuming perfectly even distribution, "300+" employees is just too small a sample to get someone born on February 29th.
I'm thinking (again, assuming even distribution, which is not realistic), you'd need a group of at least 365*4(+1?) people to be guaranteed to find one born on that day (maybe? stats have really never been my thing)...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
