aengvs

It's not the upper bound that matters but the frequency. How frequently should the compiler assume an 's' appears in the dataset, or any other character?

We know that E[# of '\0' in a string] == 1.

But what is E[# of 's' in a string]? Is it greater or less than E[# of '\0' in a string], and how should the compiler know this?

You haven't given the compiler any reason to assume that 's' or 'p' will appear more often than '\0'.

Imagine a scenario where most of the strings being processed contain a single null character, with no other characters. In that case checking for the null character first would be optimal.

Does the compiler know that this isn't true? No, it doesn't. The author of the article is making an assumption about the contents of the data that might seem reasonable but isn't necessarily true.

Problem with this is I'm now using the back of my hand or other parts of my body to open doors, press elevator buttons etc...

I've recently moved to the US from Australia. The amount my employer and I pay for my healthcare is significantly more than I paid in Australian taxes for healthcare. And that's before including my deductible, things my insurance doesn't cover and the amount I pay in US taxes for healthcare.

>No, I represent a quarter as 25/100's to show how it would be accurately represented in metric. 1/4 meter is not pure metric, it's applying a non-metric modifuer to a metric amount. The metric representation of 1/4 meters is 25 centimeters, which is 25/100.

What? Fractions aren't exclusive to the imperial system.

1/4 of a metre is metric, just as a 1/4 of an inch is imperial.

Everything below is a perfectly legitimate way of writing metric units:

1/4 m = 6/24 m = 3/12 m = 0.25 m = 25 cm = 250 mm

So easy!

The efficacy of a compression algorithm is dependent on the data it is compressing, so that statement is true for some data.

>you have the uniform distribution over those strings. This makes sense in the original context of encoding random data.

Lossless compression is nothing more than taking advantage of prior knowledge of the distribution of the data you are compressing.

Random data isn't always (or even often) uniformly distributed. Everything we compress is "random" (in the context of information theory), so I disagree that it makes sense to assume uniformly distributed data.

>In fact, any lossless compression algorithm has the property that the output is (on average) at least as long as the input

I don't think this is true. If it was, lossless compression would be useless in a lot of applications. It's pretty easy to come up with a counter example.

E.g.

(simple huffman code off the top of my head, not optimal)

symbol -> code

"00" -> "0"

"01" -> "10"

"10" -> "110"

"11" -> "111"

If "00" will appear 99.999% of the time, and the other 3 symbols only appear 0.001% of the time, the output will "on average" be slightly more than half the length of the input.

It's not hard to believe that some portion (if not the majority) of people joining the military genuinely think they are doing something good.

I think you're conflating "knowing" a language with knowing the syntax of a language.

It was an easy transition into C++ syntax from my usual C#/Java programming, but the transition into thinking like a C++ programmer was not a simple or easy one. Weeks (months?) later, I am still learning how to be a "good" C++ programmer.

I remember "learning" PHP when I was younger and could probably program quite a few things with it still but I am definitely not a PHP programmer. I have no idea what is considered good or bad practice in PHP land. I could solve a bunch of Project Euler problems in PHP but I could not write a secure PHP application for actual use.

The same goes for most languages I can think of. I've fiddled around with it, written a few small programs, gotten a feel for the standard library, but unless I use that language on a decent sized project I have nothing but a superficial understanding of it.

If you already know how to program, "learning" a new language is trivial, you can do it in a few days, sometimes even a few hours. Learning to write "good" code in that language is not something that is easy to pick up or something that is transfers between languages, even closely related languages like C and C++ or C# and Java.