I have an idea for a gameplay that I think I would enjoy more:
- If the first guess is within a factor of sqrt(10), then you win.
- If not, you are given two choices for the second guess: Up or down.
- Up and down are 10x higher and lower guesses (making them adjacent ranges to the first guess).
- If the second guess is wrong, you lose. No more guesses.
The point is that the second guess makes you rethink the original question once more, to figure out what it was that you missed. Which is more fun that doing bisection.
I wrote 10x and sqrt(10) to make a game literally about orders of magnitude, but you could of course you smaller numbers, like 4x and sqrt(4), to make it harder.
I greatly appreciate your suggestions, munch. I really like it, but I worry that the game loses some of its mainstream appeal through that. I don't know, I have to look into this in more detail.
However, I did find a solution to bring the focus a bit away from the binary search/bisection.
Namely, the game now shows a hint after the second incorrect guess. For example the hint "The US covers 1.87% of the Earth's surface." is displayed for the question about what percentage of the Earth's surface is land.
This of course lets you, just as you wanted, rethink the original question once more now in light of new information.
text:
I think I found a solution to bring the focus a bit away from the binary search and would greatly appreciate feedback from you.
The game now shows a hint after the second incorrect guess. For example the hint "The US covers 1.87% of the Earth's surface." is displayed for the question about what percentage of the Earth's surface is land.
How does the new information received through the hint impact your guess and assumptions?
help
Not only that, the compiler's optimizer might actually do a better job if you split up a big function. Because the smaller functions have less register pressure.
I'm not sure I agree and I think you should try some stuff out on godbolt first. The compiler can see where variables are no longer in use, whereas unless you turn on link time optimization (which is known for being messy so nobody seems to), you'll likely get a lot of unnecessary push/pop between the function calls.
If I'm understanding this correctly then this is about a tax disincentive, making it more expensive for US companies to poach R&D talent from other countries.
That isn't really possible because American Constitution expressly prohibits it. There is no realistic possibility of modifying the Constitution to allow it either.
As far as the US Federal government is concerned it has little practical relevance.
No, lol! That would hamper the USs strongest asset: consumption!
which is likely being hampered anyways due to corporate greed in the financial sector - it is going to be interesting to see the actual breaking point for leveraged consumption
It is precisely a salad for people who don't generally eat salads.
The big uncut leaves are suited for slow nibbling of token amounts of salad.
Croutons are recognizable from a distance as a non vegetable ingredient, making it attractive to someone who'd rather not eat vegetables at all. To me they're just stale bread.
I'd think that peoples' main objection to salad is the uncooked veggies, which isn't addressed at all with caesar salad. I don't generally trust raw vegetables to not make me sick. Especially in the US.
> The big uncut leaves are suited for slow nibbling of token amounts of salad.
Basically anything you put into a salad is better off in a soup or stew, or heavily treated with such low-ph liquid (e.g. salsa, pickled veggies, etc) as to remove the risk. If it isn't suited for canning, I'm not going to eat it.
Perhaps in a country with better-regulated food production it would seem more reasonable.
There were 19 deaths in the US blamed on food-borne illnesses from leafy green vegetables in the 40 years from 1973 to 2012 [1]. If you’re avoiding salad out of safety concerns I hope you never go anywhere near any motorized vehicle.
If it’s an excuse not to eat salads because you don’t like them then fine, but maybe just own your food preferences instead of grossly exaggerating the dangers.
There’s likely multiple orders of magnitude difference between the numbers that “were reported” as part of a known outbreak vs the number of associated deaths that actually took place. People often get admitted without identification of what specific food caused them issues.
Further there’s reasons to avoid things that don’t result in deaths. “Each year in the United States an estimated 9 million people get sick, 56,000 are hospitalized, and 1,300 die of a foodborne disease caused by known pathogens.”
So their salad avoidance isn’t as extreme a reaction as you’re suggesting.
Cooking changes the nutrient profile of ingredients. So eating some raw ingredients makes it much easier to get some vitamins like C which rabidly break down at high temperatures.
If your that concerned consider keeping some raw foods like oranges, bananas, pomegranate, onions etc which involve removing pealing the outer layer before consumption.
Nobody thinks twice in Europe about eating any raw vegetable, fruit, eggs, heck even raw fish or beef in carpaccio.
You are claiming some negligible risk from food poisoning that is in some level present in every country globally, and you are not incorrect. But with such mindset, world is such a very dangerous place that it isn't worth discovering it. Which would be a grave mistake, life is too short and you would miss most of the 'juice' life offers, which never comes without objective risks.
> Nobody thinks twice in Europe about eating any raw vegetable, fruit, eggs, heck even raw fish or beef in carpaccio.
This is one of the weirder “everybody/nobody in Europe does x” claims I’ve seen.
There’s no way you know what the fast majority of Europeans think and I know many Europeans who absolutely do avoid eating raw eggs.
Apologies for my non-native English. I'll try putting more words on it and maybe it will come out less convoluted.
It's easier to eat a lot of salad when it's finely cut. Then you just shovel in a portion with a bit of everything with every grab of the fork or spoon. With a large piece of lettuce, you need to cut it first, and then stab the piece with the fork, and then combine with other ingredients. Which makes eating that kind of salad a slow process. That's what I meant by "suited for slow nibbling of token amounts".
FP does not introduce imprecision. Quite the contrary: The continuous rounding (or truncation) triggered by using scaled integers is what introduces imprecision. Whereas exponent scaling in floating point ensures that all the bits in the mantissa are put to good use.
It's a trade-off between precision and predictability. Floating point provides the former. Scaled integers provide the latter.
I was using imprecision in a more general and less mathematical sense than the way you’re interpreting it, but yes this is a good point about why FP is useful in many financial contexts, when the monetary amount is derived from some model.
The answer is accounting. In accounting you want predictability and reproducibility more than anything, and you are prepared to throw away precision on that alter.
If you're summing up the cost of items in a webshop, then you're in the domain of accounting. If the result appears to be off by a single cent because of a rounding subtlety, then you're in trouble, because even though no one should care about that single cent, it will give the appearance that you don't know what you're doing. Not to mention the trouble you could get in for computing taxes wrong.
If, on the other hand, you're doing financial forecasting or computing stock price targets, then you're not in the domain of accounting, and using floating point for money is just fine.
I'm guessing from your post that your finance people are more like the latter. I could be wrong though - accountants do tend to use Excel.
To get the right answers for accounting, all you have to do is pay attention to how you're doing rounding, which is no harder for floating-point than it is for fixed-point. Actually, it might be slightly easier for floating-point, since you're probably not as likely to skip over the part of the contract that tells you what the rounding rules you have to follow are.
Agreed. To do accounting, you need to employ some kind of discipline to ensure that you get rounding right. So many people erroneously believe that such a discipline has to be based on fixed point or decimal floating point numbers. But binary floating point can work just fine.
Postel's law isn't about accepting arbitrary invalid inputs. It's about inputs that are technically invalid but the intent is obvious from looking at it, and handling those according to intent.
In a distributed non-adversarial setting, this is exactly what you want for robustness.
The problem, as we've come to realise in the time since Postel's law was formulated, is that there is no such thing as a distributed non-adversarial setting. So I get what you're saying.
But your definition of robustness is too narrow as well. There's more to robustness than security. When Outlook strips out a certificate from an email for alleged security reasons, then that's not robustness, that's the opposite, brokenness: You had one job, to deliver an attachment from A to B, and you failed.
Robustness and security can be at odds. It's quite OK to say, "on so and so occasion I choose to make the system not robust, because the robust solution would not be sufficiently secure".
The only area in which is it acceptable to reason this way is graphical user interfaces. (And only if you've provided an API already for reliable automation, so that nobody has to automate the application through its GUI.). Is say graphical, because, no, not in command interfaces.
Even in the area of GUIs, new heuristics about intent cause annoyances to the users. But only annoyances and nothing more.
Like for example when you update your operating system, and now the window manager thinks that whenever you move a window so that its title bar happens to touch the top of the screen, you must be indicating the intent to maximize it.
I suppose the ship has sailed now that people are deploying LLMs in this way and that and those things intuit intent. They are like Postel's Law on amphetamines. There is a big cost to it, like warming the planet, and the systems become fragile for their lack of specification.
> When Outlook strips out a certificate from an email for alleged security reasons
I would say it's being liberal in what it accepts, if it's an alternative to rejecting the e-mail for security reasons.
It has taken a datum with a security problem and "fixed" it, so that it now looks like a datum without that security problem.
(I can't find references online to this exact issue that you're referring to, so I don't have the facts. Are you talking about incoming or outgoing? Is it a situation like an expired or otherwise invalid certificate not being used when sending an outgoing mail? That would be "conservative in what you send/do".)
You are spot on in regards to consideration of adversarial context; however, it is instructive to review the nuanced difference between the RFC761 (1980) statement, viz. "be conservative in what you do, be liberal in what you accept from others" and the substitution of "send" for "do" in RFC1122 (1989). The latter is, with hindsight, an error, since it refocused the attention of some rigid thinkers entirely onto protocol mechanics and away from implementation behaviour, despite the commentary beneath that admonishes such a mindset and concurs wholly with your point.
Or to put it otherwise, Postel was right to begin with, albeit perhaps just a little too cryptic, and has been frequently misquoted and misinterpreted ever since.
It’s not wrong, because it doesn’t stand alone, and yes, if you’re cherry picking half a statement, then you’re like the Australian politicians calling it a “lucky country”, perpetuating a gross misrepresentation of both the letter and the sentiment of the original statement.
This is especially ironic given that the constructive argument against Postel’s law is generally based on the value of a strict interpretation of specification. If you’re intentionally omitting half of the law, then you have an implementation problem.
Furthermore, none of this has much to do with YAML being a shitty design.
I think the other half of the law is more or less good, so I don't have any reason to bring it up. I don't exactly know what it means to be conservative, but it sounds safe, like staying away from generating inputs for other programs that exercise dark corner cases. I don't really have anything to discuss about that half of the law.
The world doesn't need principles that are half good.
> I don't exactly know what it means to be conservative
That could undoubtedly lead to misapprehension. As the GP indicated, and as the word itself means, it references systemic stability and self-preservation behaviour. Reciprocally, however, the obligation to be liberal absolutely does not mean absolving faulty inputs of their flaws. For example, it would not excuse a dud response to an SSH handshake like trying to negotiate RC4. Both Steve Crocker and Eric Allman have been at pains to unpack the understanding of robustness, forgiveness, and format canonicalisation in security context, and they're hardly wrong. It's also why I'm particularly an advocate of the "do", not the "send", formulation. This is a much more systemic and contextual verb in its consequences for implementatation.
> staying away from generating inputs for other programs that exercise dark corner cases
This is exactly the kind of focus-solely-on-the-wire misdirection that I identified above as a common misinterpretation. Conforming to the most precise and unambiguous interpretation of a protocol, if there is one, in regards to what an implementation puts on the wire, can most certainly be a part of that, but that isn't always what being conservative looks like, and processing is equally if not more important.
The introduction of Explicit Congestion Notification (ECN) aka RFC 3168 (2001) springs to mind. RFC 791 (1981) defined bits 14 & 15 of the IPv4 header as "reserved for future use" and diagrammatically gave them as zero. RFC 1349 (Type of Service, 1992, now obsoleted) named them "MBZ" (Must Be Zero) bits but gave them to be otherwise ignored. RFC 2474 (DSCP, 1998) did much the same with what it termed the "Currently Unused field". When ECN was introduced, making use of those bits as a supposedly backwards-compatible congestion signalling mechanism, we discovered a significant proportion of IP implementations aboard endpoints, routers, and middleboxes were rejecting (by discard or reset) datagrams with nonzero values in those bits. Consequently, ECN has taken two decades to fully enable, and this is where both sides of the principle prove their joint and inseparable necessity; to this day many ECN-aware TCP/IP stacks are passive, stochastic, or incremental with their advertisement of ECN, and equally forgiving if the bits coming back don't conform, because an implementation that resets a connection under the circumstances where the developer comprehends the impedance mismatch would be absurd. Thus fulfilling both sides of the maxim in order to promote systemic stability and practical availability and giving ECN a path to the widespread interoperability it has today.
The exposition on page 13 of RFC 1122 (Requirements for Internet Hosts, 1989) broadly anticipated this entire scenario, even though the same section misquotes Postel (or, rather, uses the "send" restatement that I find too reductive).
The statement of the robustness principle is an integrated whole. A partial reading is, perhaps ironically, nonconformant; as with Popper's paradox of tolerance, one thing it cannot be liberal about is itself.
Yes, rejecting must-be-zero-reserved-bits due to being nonzero is obviously incorrect.
"Must be zero" means that when the datum is being constructed, they must be initialized to zero, not that when the datum is being consumed, they must also be validated to be zero.
Violating either rule will cause that implementation not to interoperate properly when it is still found deployed in a future in which the bits have now been put to use.
Rejecting must-be-initialized-to-zero fields for not being zero is not an example of a flaw caused by neglecting to be "liberal in what you accept". It's an example of failing to accept what is required: the requirement is to accept the datum regardless of what is in those reserved bits. It is arguably an instance of failing to "be conservative in what you do". If you are conservative, you stay away from reserved bits. You don't look at them, until such a time as when they have a meaning, accompanied by required (or perhaps optional) processing rules.
Now, I see the point that reading Postel's law might steer some designer away from putting in that harmful check for zero, specifically due to the "be liberal" part of it. But that's just a case of two wrongs accidentally making right. That same designer might refer to "be liberal" again in some other work, and do something stupid in that context.
The only thing that will really help is clear specs which spells out requirements like "the implementation shall not examine these bits for any purpose, including validating their value".
I have an idea for a gameplay that I think I would enjoy more:
The point is that the second guess makes you rethink the original question once more, to figure out what it was that you missed. Which is more fun that doing bisection.I wrote 10x and sqrt(10) to make a game literally about orders of magnitude, but you could of course you smaller numbers, like 4x and sqrt(4), to make it harder.