The main difference is that engineers have a code of ethics they're expected to uphold, with the threat of taking away your certification if you don't.
HN user
gchpaco
If you read the article, they discuss it there.
And said notation causes the generic type system to be Turing complete, as in the Java case.
There are only two "natural" problem classes known that are not either definitely in P or definitely in NP, and this article concerns one of them. (The other is integer factorization / discrete logs). And I'm not sure anybody believes there are any natural problems that are inherently in this in between state.
In general his complaints regarding logic are incoherent. A function is not a messy weird object in mathematics; it's a possibly infinite set of ordered pairs where there are no duplicates of the first element of the ordered pair. That's it all it is, formally. Or "class" is a concept that has highly specific meaning in NBG theory—in ZFC it's not a formal distinction and so there's a transformation that must be obeyed where "x \in Class" means "{ x | x satisfies class definition}"; which due to Foundation must be the subset of some other, preexisting, class (and thus is Russell's paradox defeated). Almost all of these things exist and are present and are extremely well defined in the theory, he just doesn't like them for some reason.
The C and I presume C++ standard has been very carefully avoiding the idea of a preprocessor being separate at all. The standard was very carefully worded to prevent that being necessary, because most C compilers do not have a separate preprocessor. It is only Unix heritage compilers that really have one, and even they're not consistent about it.
There's a number of fisheyes that produce circular images on rectangular film (obviously, not using the entirety of the film surface).
No, but it is the one name that people remember, and saves much explanation. The Rolleicord, the Mamiya C series, and the YashicaMats, one of which is my TLR, were more consumer oriented.
The #2 Brownie came out in 1901 and shot 6cm x 9cm, and all of the surviving Brownies I've seen shot rectangular formats. There was the Brownie 127 which shot square, but I only learned of its existence just now; have never seen one in the wild, probably because finding 127 film is functionally impossible.
Too small, slide mounts were already standardized on 24x36, and the square was never all that popular among the general photographer. The reason why the square shape in 120 was originally developed was a technical hack. Since it outputs a square, there was never any need to hold a Hasselblad vertically; just take the photo and crop it to suit. The only square consumer oriented cameras I can think of are twin-lens reflex cameras like the Rolleiflex, which are delightful but somewhat uncommon. A number of folks started trying to make use of the square format as a square format, but it was not originally, I think, intended for that purpose.
Re: too small; an 8x10, one of the smaller standard print formats for portraits, is about an 8x enlargement from a 35mm frame. With modern materials and good technique, 8x-11x is feasible, but starting to push it at the edges; I have printed 13x17s off 35mm but I would not want to push it much larger. 35mm does 4x6s, 5x7s and 8x10s perfectly reasonably, which is what it spent most of its time doing for common consumer work. It's worth noting that one of the other common consumer cameras of the 1940s was the Brownie, which output 6cmx9cm images and was routinely contact printed, producing something smaller even than a 4x6.
120 produces images that are between 1.8x (in the 645 format) or 2.5x (in most others) as large, physically, meaning that the common enlargements are only 4x-5x. If you push it, with quality equipment, you start getting into print sizes that are super clumsy to handle like 20x24. I've never printed, personally, anything larger than a 16x20. If you do your own wet processing they're also nicer to work with—35mm negatives are real small and kinda fiddly. 4x5 sheets are also delightful to work with, of course, but they require fighting the camera in the field.
I damn near released a (private) message protocol without a version field a couple months ago, and I know better. Fortunately stopped myself and added it before any actual data got released.
A formal language is basically just a mathematical set of acceptable strings made up of symbols in a (typically finite) alphabet; thus the smallest is probably the empty set, or if you insist on an accepting path, a set containing only the empty string.
The interesting part comes up when you want to match an infinite set of strings with an algorithm. Probably the simplest such algorithm would be "regardless of input, accept" which isn't exactly useful but would suffice.
It's dissatisfying to have an algorithm that puts weird, arbitrary restrictions on composing languages; for example it's usually the case that if you take a language L1 and a language L2 that are both acceptable to the algorithm, the concatenation (for every string in L1 and every string in L2, the concatenation of their strings is in the new language) language is usually acceptable to the algorithm.
Some commonly used languages do not have all of these properties; in particular the intersection of two context-free languages may not be a CFL, nor the complement. Deterministic context free languages are even more restrictive. You seem to need to give some things up as you move up the language hierarchy in power; in particular string homomorphism and intersection seem to be mutually exclusive in languages more powerful than regular expressions.
If you're interested, the theory of abstract families of languages has been studied, although I do not know a lot about it myself.
Depends on the database, but Cassandra, for example, has quorum mode for writes, which requires a majority of the cluster members ack the write. This can be enabled on a per-query basis, and also for reads.
The other way of doing it is things like CRDTs (https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...) which have a join operation for any two data values.
You have to keep it in the back of your mind that it's a thing, but working without consistency can be done.
The printing is the fun part, anyway.
I love my X-Pro, and I loved Fuji film before it, but remember Fuji has never been under the anti-trust concerns Kodak has, and that forced them to divest the film processing and professional camera arms.
I'm not competent to explain why Tacoma Narrows failed, but it obviously wasn't up to design load. The existence of large sheets of glass falling off buildings and endangering people from multiple different installations strongly indicates that someone botched something.
There are two major issues that crop up in my experience.
* Node as a runtime is deeply mediocre, in my experience. You can usually solve this by throwing more (usually virtualized) hardware at the problem.
* Meteor's architecture is (at present) tied into MongoDB's oplog tailing. You can scale it up through sharding, through alternate libraries, and DDP itself is not tied to MongoDB at all. IIRC fixing this was a goal for Meteor 2.0.
Both of these can be worked around. If nothing else, the Meteor web side will talk to anything doing DDP, and DDP is not that hard to deal with.
I do not, myself, know why this is the case. I can come up with several plausible reasons; for example, you're basically coming up with an alternate input device for your computer piggybacked onto something that's already there. Additionally these programs basically are the computer if you're blind; you develop a lot of experience with them quickly because the alternative is not using it at all. And some amount of it is probably cultural/historical, we make it hard because it's always been hard. Truly, I don't know, and I don't know anyone who does.
It is ... difficult for me to describe just how dangerous it is to try to use 3 dimensional intuitions in a higher dimensional space. As the number of dimensions increases the amount of "space" there is for things to get weird get much more complicated; for example any knot that exists in 3 dimensions can be untied trivially in a 4 dimensional space.
Suffice to say if you try to use your ordinary everyday life intuitions doing higher dimensional mathematics you will continuously embarrass yourself until you learn not to. Some folks develop the necessary adjustments and have higher dimensional intuitions; I do not and have to do the math anywhere higher than around 4.
Part of the problem is that most accessibility software has a hell of a learning curve, that the blind have implicitly overcome already to use the thing at all. (e.g. emacspeak) It can be very daunting to try to use it as a sighted person with a blindfold over their eyes.
As a counterpoint it's routine in topological mathematics to work with 8 or 12 or 11 dimensional objects.
In addition to what pbsd said, Carmichael numbers are incredibly rare. Your odds of stumbling across one by chance are lower than the odds of a cosmic ray flipping the bit of memory that causes you to believe you have stumbled across one, as I recall.
Bit braces (the C shaped tools) are also the finest Phillips screwdrivers available, I've found. The design makes it easy to exert a lot of force to prevent the bit from camming out, and the amount of torque one can generate is astounding. Braces are measured by the diameter of the rotation; most good ones are in the 8"-10" range, which is probably more appropriate for casual use. 14" and up were generally for driving big augers, and you need every bit of that torque. I have a 6" one that is cute and small but not actually all that useful due to jaw issues.
When you set a large beam of wood on fire, what typically happens is the outside chars but the fire never reaches the core, which stays intact. This won't happen so much with typical dimensional lumber like a 2x4, but when you look at timber framing using 5x5 or 5x10 beams as a stock element, the effect can be quite real.
There are almost no 100 year old brick buildings in San Francisco. Why? Because there was a big goddamn earthquake in 1906, and unreinforced masonry (which is to say, functionally almost all of it) deals badly with earthquakes in general. It deals especially badly with them when they are built on landfill.
There are also lots of mentions of survivorship bias, which is extremely relevant here.
Now that said, I find modern construction to be badly done in general, because it is almost all of it erected as cheaply as possible—and as cheaply as possible as measured by the shortest possible term metric. There is good stuff done still, and it is arguably cheaper over the ten year run or longer, but that's not what people buy and so it's not what the developers make. I'd like to claim this is shortsightedness but I can't shake the feeling that it's because real wages have been stagnant or sometimes declining since around 1972. There just isn't the money to spend.
N.B.: there are a lot of reasons why modern lumber seems like so much crap. About 95% of it is because folks are unwilling to pay for good lumber, as described above. Quality lumber, even quality construction lumber exists, but it's significantly more expensive than #2 common. Of the remainder, it's worth remembering that modern 2x4s are tend to be farmed in sustainable fashion using fast growth species like Douglas fir or Southern yellow pine. The stuff we were building with in the 30s and 40s? Quite a lot of that came from old growth forests, now irrevocably gone.
Truth, I dunno why I have 20 bits stuck in my head.
Acme, too, defaults to variable width, and looks rather better for it. It's always a little awkward in Emacs because a lot of the system packaging (package.el, for example) assumes mono, but it can work.
Don't idly dismiss emoji. They're the first thing from outside the Basic Multilingual Plane that people actually want to use, and as a result the first thing to find all the bugs and hidden assumptions going from a 16 bit wide character set to a 20 bit wide character set. This helps people who actually needed access to the various CJK Ideograph Extensions, most of which are in Plane 2.
Pretty printing is surprisingly tricky. Last time I had to do it, I ended up with this: https://github.com/rethinkdb/rethinkdb/blob/next/src/pprint/... which has become my favorite algorithm for it as it's quite tweakable for specific needs. Fun little algorithm.
Average, yes. But that reflects high infant mortality. Generally speaking if you survived to 20 you would probably make it to 60 barring misadventure or war.