The paper refers to CO2 as "carbonic acid gas". At this time, did they know that CO2 was also produced by burning fossil fuels? Or by respirating living things?
I think other commenters have answered your question, but I thought I'd talk a little on carbonic acid.
Carbon dioxide partitions into water as carbonic acid. This is the key mechanism in ocean acidification. Of course the rate is affected by pH of the oceans, there's a buffering action going on between carbonate, bicarbonate, and carbonic acid depending on how many protons are available. It's also why pure water sitting open to the air will have a slightly acidic pH.
The oceans at the bottom have a decent layer of carbonate material accumulated from shells, which are also at equilibrium with the ocean, but the other direction (accepting protons). But since the oceans are so big, to increase the pH of the oceans you'd have to send the surface water to the bottom. Mixing the oceans is kind of a slow process -- around 500 years. But in theory we'll get some long term climate help from the ocean floor (well, if the methane clathrates don't get us first).
CO2 was first hypothesized specifically as a gas making up the difference in mass between charcoal and the remnants of burning it in the 1600's by Jan Baptist van Helmont[1].
That respiration of animals emits CO2 was determined at least by the 1750's.
A Google Scholar search based on "carbonic acid gas" and "coal" found Babington, William. "A case of exposure to the vapour of burning charcoal." Medico-chirurgical transactions 1 (1809): 83. at https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2128797/pdf/med... :
> When carbon in combustion combines with oxygen we obtain carbonic acid gas, and at the same time in proportion to its moisture, more or less hydrocarbonous gas is evolved.
A Google Scholar search based on "carbonic acid gas" and "exhalation" found Allen, William, and William Hasledine Pepys. "XVII. On the changes produced in atmospheric air, and oxygen gas, respiration." Philosophical Transactions of the Royal Society of London 98 (1808): 249-281. at https://royalsocietypublishing.org/doi/pdf/10.1098/rstl.1808... with quotes like:
> In this experiment we meet with a remarkable fact, viz. that as much carbonic acid gas was given off in 5½ minutes, as in the former experiment in eleven minutes ; so that it appears, whenever atmospheric air is taken into the lungs, it returns charged with about 8 per cent, carbonic acid
Uber's main (only?) advantage here is their ability to take advantage of a shared labor pool. By increasing the demand for driving + food delivery, it makes the Uber labor pool bigger and further increases the lock-in effect so Uber drivers don't want to open other apps.
Agreed. At the very least, when you pull up directions, every road that you have to turn on should have the street name should be visible (at least without too much zooming).
60k per year doing internships? I thought a typical tech internship paid $5-8k/month, which means at most $25k over the summer. (Maybe my number is for undergrads, and grad student interns get paid significantly more?)
Boyer Moore is OK, but there are better algorithms available. The simpler Horspool variant is usually a fair bit faster and also easier to implement.
For short strings, e.g. less than 12 character, the ShiftOr algorithm is hard to beat. I've spent quite a bit of time writing and profiling different search algorithms as part of the byteseek project on GitHub. Let me know if you'd like details on other possible options.
I would most definitely be interested. I always assumed that certain algorithms are better suited for certain string sizes, but I was never sure which ones. The ideal implementation is probably combining multiple algorithms with ranges of the string size.
Absolutely true that there isn't a single algorithm that beats all the others. Of the general string search algorithms which don't use specialized CPU instructions to obtain speedups, I would recommend:
1. ShiftOr for short strings. Easy to implement.
This algorithm is not sub-linear like Boyer Moore - it examines every position, but it uses bit-parallelism to validate a match, making it outperform algorithms that rely on jumping then separate verification stages, for short strings.
2. Variants of Wu-Manber for longer strings. Hard to find a good description, but not too hard to implement.
Wu-Manber is a search algorithm designed for multi-pattern searching, based on Boyer-Moore-Horspool and hashes. However, it also performs really well for single-pattern searching. I have encountered variants of this in various places, e.g. Lecroq's in "Fast Exact String Matching Algorithms".
These algorithms use a hash of a q-gram to look up how far it's safe to shift. Q-grams tend to appear less frequently in search patterns vs. single characters, so you get longer jumps, at the cost of reading more characters and producing a hash.
3. Horspool (or Boyer-Moore-Horspool).
This algorithm performs quite well - not as well as ShiftOr for shorter patterns or Wu-Manber variants for longer ones, but still respectable. It's essentially Boyer-Moore but only using one of the shift tables, which makes it much easier to implement.
4. Qgram-Filtering by Branislav Durian, Hannu Peltola, Leena Salmela and Jorma Tarhio
For longer patterns, this algorithm outperforms the others mostly. However, it can be a bit complicated to implement well, and it has some nasty worst-cases (rarely encountered) where the performance becomes absolutely dreadful. For that reason I tend not to use it.
There are hundreds of possible search algorithms available now (see https://github.com/smart-tool/smart for implementations of many of them with a benchmark tool). However, it's hard to figure out exactly which algorithm is the best given your data and pattern. For that reason, I tend to keep things simple.
I would just use ShiftOr for short patterns, and another one for longer patterns. I would tend to use a Wu-Manber variant there, but Horspool would probably give acceptable performance.
The only other consideration is the time it takes to build the pattern indexes. For short searches, or if you have to re-build the pattern index on each repeated search, it can actually be quicker to just do a naive "check the string at each position" search, since it doesn't require building anything before searching.
In my experience, it is difficult to beat a very simple heuristic in most settings: when provided a string, pick the most infrequently occurring byte in that string, and use that as your skip loop in a vector optimized routine such as memchr. If you guess the right byte, you'll spend most of your time in a highly optimized routine that makes the most out of your CPU.
Picking the right byte can be tricky, but a static common sense ranking actually works quite well. At least, the users of ripgrep seem to think so. :-)
For some reason, I've never seen this algorithm described in the literature. It doesn't have nice theoretical properties, but it's quite practical.
Yes, I think that's a good analogy. Tech is treated like a cool toy in the news, rather than as a corporate sector that has real consequences on everyone's lives. Tech should be covered differently than computer games. (Not making a value judgement about gaming, just saying it has less of an effect on society.)
I think you missed the point regarding whiplash. He's saying journalists should have been more skeptical about these companies all along, and should have dashed in some skepticism into their reporting throughout the last 10 years. Instead, they didn't pay attention to these things until recently, at which point everyone realized there are some things about Facebook and Google which seem questionable. So they waited too long to start looking at these companies critically, and when it became a salient topic and everyone started criticizing Google and Facebook all at once, they also had to jump onto the criticism bandwagon seemingly out of nowhere, causing the readers whiplash.
That said, I don't believe his analysis is correct. I remember the short period of time in which coverage of Google and (a bit later) Facebook went from glowing to extremely nasty. It wasn't due to any sort of intellectual awakening amongst journalists. The cause was much simpler: Google launched Google News, and Facebook's news feed started to really begin kicking off major referral traffic to news sites.
Journalists and their editors started to realise:
a) How dependent they were becoming on G&F for traffic
b) How the decline in their profitability was terminal and not going to be easily turned around via some superficial "digital strategy"
c) How profitable these tech firms really were.
They started attacking G&F not due to any actual or real problems but as part of a negotiating tactic, which you can see still playing out today with the various EU attempts at a "link tax" which is really a tax on Google News. Rupert Murdoch in particular was decisive in this war because at some point he concluded that the iPad was the future of newspapers (because it looked like a newspaper) whereas Google News was a horrible dystopian future. I remember that once Murdoch gave a speech outlining this belief his stable of newspapers turned on a dime to begin attacking Google and praising Apple, often with the most spurious of stories. But hey, they thought (wrongly) that Big Tech was taking away their employment.
