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.
But because in the single-null case the loop body is executed only once, the gains of arrangement that prefers nulls are pretty slim compared to long-string cases where the loop body is executed many times. For example if your dataset contains 99 cases of single null strings and one case of 100 chars long string, it might still be optimal on aggregate to use the long-string optimizing arrangement.
Of course there are still some cases where non-zero strings are extremely rare and as such optimizing for those makes sense.
Partition your body: some parts used for some things, others for other things. Use an elbow or knee to push buttons, use the long sleeve of a jacket as a mini-glove if you need to grasp a handle. Or wear gloves that you take off once you're inside.
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.
In Australia, the government spends over $70B on healthcare, but collects only around $10B through Medicare levy surcharge. The only reason your healthcare spending in Australia seemed so low is because an overwhelming majority of the cost of healthcare in Australia is covered through general taxes, and not through the Medicare tax. Even if you focus on Medicare benefits only, the Medicare levy surcharge only covers less than half of the Medicare benefits.
That said, healthcare in Australia in fact is cheaper than in the US, but not as much cheaper as you think it is.
Yes. And US doctors make more "per capita" than Australian doctors. About twice as much. If they continue making more, I don't see how paying their billing rates from the taxes addresses the "affordability" problem. If you were to fix billing rates at a lower level (through single payer and such), you wouldn't really have any doctors to begin with, at least not for a while.
I live in Australia and that doesn't seem out of the ballpark. I pay the equivalent of USD$1.3k a year in levies and USD$100 a month for health insurance. Australia doesn't have access to the same level of care either (for example, bleeding edge cancer treatments or experimental medicine).
I also pay substantially more in other general taxes (compared to the US), which ends up funding healthcare as well.
>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:
Fractions are mathematical modifiers that can applied to any quantifiable measurement. That said, I imagine they aren't generally used in professional context in metric, because they generally aren't in imperial either. You don't see architectural plans that say 1-1/2 feet, they say 1'-6". Is it common to see fractional amounts in metric when used in a professional context?
Thanks, that's what I assumed (because it makes sense). For metric you often go two orders of magnitude smaller, but I'm thinking a good amount of the reason to usually go straight to millimeters instead of also using decimeters is that decimeters just can't easily represent many common fractions of a meter (1/4, 3/4, 1/3, 2/3), and a base 10 system can never represent some of those perfectly without resorting to a mixed format.
>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.
Sure, I'm assuming that (a) you are trying to encode all strings of length at most n and (b) you have the uniform distribution over those strings. This makes sense in the original context of encoding random 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.
Then the original statement about not being able to use pi as a data compression method is false. It could be the case that 99% of the time you want to encode the string "141592653".
I had a friend who joined the National Guard long before the Iraq War. When the push to invade started she expressed grave reservations about the impact on the world. One thing she said was "if we go to war, do you have any idea how much history will be lost?"
She was called up to serve, and served in a war she honestly believed was unnecessary and wrong. She never was willing to talk about her experiences over there. A year after she got back, she hanged herself.
It is easy to look at the military and assume that these are people without a conscience. It is harder to recognize that people can join the military for a large number of reasons, many good, and when duty calls, the conflict between political opinion and duty is not always an easy one to resolve.
I believe that the majority of those who join the military do so out of the belief that they are doing something good. Those who eventually realize they are not pay a heavy price one way or another. Either like my father they go to jail (my father went to jail for refusing to go to Vietnam--- he was a First Lieutenant in the Army Reserves at the time), or like my friend end up taking their own lives.
read the starship troopers. it's a little entertaining little short story.
But it hit like a punch to face when you finally grasp how the mind of a kid gets turned around in the army. In the end, even you are being proud of his dumb and blind service to the war effort.
If you are looking for an intentionally anti-militaristic message, I recommend the movie over the book. If you enjoy unintentional messages, the book is fantastic too.
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.
It's easy transiting from C++ to Java/C#, the the reverse transition is not as easy.
I would say that the "mental toolbox" of a C++ programmer includes a lot of things that also belong in a Java programmer's "toolbox" (i.e. classes, inheritance, virtual functions), which helps someone who knows C++ pick up Java relatively easily. But there are important aspects of C++ that are NOT in the Java toolbox, i.e. manual memory management, pointers, templates (which are way different from generics in java, by the way), these make the reverse transition harder.
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'.