The thing about LR parsers is that since it is parsing bottom-up, you have no idea what larger syntactic structure is being built, so error recovery is ugly, and giving the user a sensible error message is a fool’s errand.
In the end, all the hard work in a compiler is in the back-end optimization phases. Put your mental energy there.
I have worked on compilers (mostly) for high-performance computing for over 40 years, writing every part of a production compiler twice or more. Optimization and code generation and register allocation/scheduling are definitely the most fun -- but the hardest work is in parsing and semantics, where "hardest" means it takes the most work to get things right for the language and to deal with user errors in the most graceful and informative manner. This is especially true for badly specified legacy languages like Fortran.
I was just going into the second quarter of compiler design when the dragon book came out. My copy was still literally “hot of the press” — still warm from the ink baking ovens. It was worlds better that anything else available at the time.
It seems to me that compared to your phone, a power brick dangling off a charging cable is much more likely to slip off your lap unnoticed and get wedged in the seat hinge only to get subsequently punctured.
I recently took a flight where I had a laptop, my phone, a power brick, a new power brick for my wife, a second phone (for reasons) and a battery for a piece of ham radio equipment in my backpack. As I got on the plane, I was thinking I was probably one of the risker passengers on board :) Anyway, when I use the brick, I keep it zipped in a jacket pocket with just the charing cable coming out in an effort to keep it from finding its way to a place that it shouldn't.
he he... is that the equivalent of when I was a kid we differentiated by "drive-in", "paper-napkin restaurant" and "cloth-napkin restaurant" in order of how much trouble you would be in if you embarrassed your parents.
It is easy to underestimate how much one relies on senses other than vision. You hear many kinds of noises that indicate road surface, traffic, etc. You feel road surface imperfections telegraphed through the steering wheel. You feel accelerations in your butt, and conclude loss of traction from response of the accelerator and motion of the vehicle. Secondly, the human eye has much more dynamic range than any camera. And is mounted on an exquisite PTZ platform. Then turning to the model -- you are classifying obstacles and agents at a furious rate, and making predictions about the behavior of the agents. So, in part I agree that the models need work, but the models need to be fed, and IMHO computer vision is not a sufficient sensor feed.
Consider an exhaust condensation cloud coming from a vehicle's tail pipe -- it could be opaque to a camera/computer-vision system. Can you model your way out of that? Or is it also useful to do sensor fusion of vision data with radar data (cloud is transparent) and others like lidar, etc. A multi-modal sensor feed is going to simplify the model, which in the end translates into compute load.
No, I don't think that will be successful. Consider a day where the temperature and humidity is just right to make tail pipe exhaust form dense fog clouds. That will be opaque or nearly so to a camera, transparent to a radar, and I would assume something in between to a lidar. Multi-modal sensor fusion is always going to be more reliable at classifying some kinds of challenging scene segments. It doesn't take long to imagine many other scenarios where fusing the returns of multiple sensors is going to greatly increase classification accuracy.
The goal is not to drive in all conditions; it is to drive in all drivable conditions. Human eyeballs also cannot see through dense fog clouds. Operating in these environments is extra credit with marginal utility in real life.
But humans react to this extremely differently than a self driving car.
Humans take responsability, and the self-driving disengages and say : WELP.
Oh sorry were you "enjoying your travel time to do something useful" as we very explicitely marketed ? Well now your wife is dead and it's your fault (legally). Kisses, Elon.
That’s a complicated question. The Wonderwerk Cave in South Africa where we found the first evidence of controlled fire also contained burned plant remains and bones, which could be interpreted as evidence of cooking. There were also burned fish remains found at the Gesher Benot Ya’aqov site in Israel, dated to about 780 kYA, which could also be interpreted as evidence of cooking.
By far the strongest evidence is the Qesem Cave in Israel, which had a central hearth and so many burned animal remains that it couldn’t have been accidental. Unfortunately the dating on that is controversial and the error bar is huge at 300 +- 100 kYA (200,000-400,000 years ago).
i guess the point of having a tag in the shape of a card is to prevent a thief from throwing the obvious airtag away, the card tag may look like an ordinary bank card and kept in the wallet longer
Well, if your manager can see your employee file (which they can.... certainly in Worlday) they will know your birthday. Oddly, at my employer, celebration of individual birthdays is discouraged, I have heard it is because it might make someone feel uncomfortable being called out for aging. As someone who is probably in the oldest 1% of the company... I find that amusingly curious. Birthdays are a good excuse for a team celebration, and that is almost always good team bonding.
Mostly agree, but we don’t have to give up the benefits of direct digital tabulation for quick results. I would like a paper audit trail. Print my ballot-as-cast for on a paper roll that scrolls by under a window. I can verify it before leaving the voting booth. Recounts and challenges can be a computer scan of the paper roll. None of this is hard. Costs a bit more, but buys trust in the system.
This is the system used in the majority of the United States. Direct-recording electronic voting systems were never that common, briefly peaked after the Help America Vote Act as the least expensive option to meet accessibility requirements, and have become less common since then as many election administrators have switched to either prectinct tabulators or direct-recording with voter-verified paper audit trail.
In the 2026 election, only 1.3% of voters were registered in jurisdictions that use direct-recording electronic machines without a voter verifiable paper audit trail (https://verifiedvoting.org/verifier/#mode/navigate/map/voteE...). 67.8% of voters are registered in precincts that primarily use hand-marked ballots, and the balance mostly use BMDs to generate premarked ballots.
You don't necessarily need any sort of electronic counting for quick results. Federal elections in Australia are usually called late on the voting day and I imagine the same is true for other countries that are paper-only.
Votes close at 10pm. Might be a few stragglers left in the queue, so call it 10:15pm. (Exit poll results are embargoed until 10pm.)
Ballot boxes are transferred from individual polling station to the location of the count. The postal votes have been pre-checked (but the actual ballot envelope has not been opened or counted) and are there to be counted alongside the ballots from the polling stations.
Then a small army of vote counters go through the ballots and count them and stack together ballots by vote. There are observers - both independent and appointed by the candidates. The returning officer counts the batches up, adjudicates any unclear or challenged ballot, then declares the result.
The early results come out usually about 1 or 2. The bulk of the results come out about 4 or 5. Some constituencies might take a bit longer - it's a lot less effort to get ballot boxes a mile or two down the road in a city centre constituency than getting them from Scottish islands etc. - but it'll be clear who has the majority by 6 or 7 the next day.
I can appreciate that the US is significantly larger than the UK, but pencil-and-paper voting with prompt manual counts is eminently possible.
That's how it works in Cook County and a lot of other places: it's touchscreen voting, using "ballot marking devices", which produce a paper ballot you hand to an EJ to submit.
Some paper jurisdictions have this, essentially. E.g., where I live: the ballot is a paper ballot. You vote by filling in a circle/bubble. (If you're familiar with a "scantron" … it's that.)
It looks like a paper document intended for a human, and it certainly can be. A machine can also read it. (And does, prior to it being cast: the ballot is deposited into what honestly looks like a trashcan whose lid is a machine. It could presumably keep a tally, though IDK if it does. It does seem to validate the ballot, as it has false-negative rejected me before.)
But now the "paper trail" is exactly what I submit; it's not a copy that I need to verify is actually a copy, what is submitted it my vote, directly.
> I would like a paper audit trail. Print my ballot-as-cast for on a paper roll that scrolls by under a window. I can verify it before leaving the voting booth.
Why should you be forced to trust that what you're shown is also what was being counted? The paper record should be the actual ballot itself, with your actual vote on it.
In the end, all the hard work in a compiler is in the back-end optimization phases. Put your mental energy there.
reply