Over the last 7 years I've built 3 major products that needed charts. Every time I tested most of (at that time) popular solutions. All 3 times eCharts was by far the best option, across all criteria. Incredible library!
Cheap means small, small means low Q&A scores. I know that this isn't that important for the majority of applications, but I feel that over-reliance on RAG whenever Q&A performance is discussed is quite misleading.
Being able to clearly and correctly discuss science topics, to write about art, to understand nuances in (previously unseen) literature, etc. is impossible simply through powerful-reasoning + RAG, and so many advanced use cases would be enabled by this. Sonnet 3.5+ and GPT 4.5 are still unparalleled here, and it's not even close.
In the console, TPM limit for 3.7 is not shown (I'm tier 4). Does it mean there is no limit, or is it just pending and is "variable" until you set it to some value?
We set the Claude Code rate limits to be usable as a daily driver. We expect hitting rate limits for synchronous usage to be uncommon. Since this is a research preview, we recommend you start small as you try the product though.
Sorry, I completely missed you're from the Code team. I was actually asking about the vanilla API. Any insights into those limits? It's still missing the TPM number in the console.
(Also I believe these letters are 'anonymous' not in the sense that their authorship is unknown, but in that they were published under the institutional name of the Insurance Institute where he was employed, not under his personal name.)
Hey, thanks for jumping into the thread! I stumbled upon Lightcell a couple of days ago after seeing the episode of First Principles [1] podcast, and found it really interesting, so decided to share what you're doing with HN.
Can you please give some real-world example of why it's easier to do calculations? Not disputing what you say, just hard for me to imagine why it would be so.
1 knot is about 100 ft/min which is very convenient for descent at a specific glide slope (i.e. for 100 knots ground speed at 5% slope you want 500 ft/min descent rate). Standard is 3° which is about 5%.
Knots are also handy for navigation as 1 nautical mile equals 1 minute of latitude. And of course a knot is 1 nautical mile per hour. So if you're doing 300 knots, that's 5 degrees of latitude per hour.
The calculation in the metric system would not necessarily be more complicated, but it would be different because the reference points in the metric system are not directly aligned with the geography of the Earth.
"1 knot is about 100 ft/min which is very convenient for descent at a specific glide slope (i.e. for 100 knots ground speed at 5% slope you want 500 ft/min descent rate). Standard is 3° which is about 5%."
You are right. It's an easy calculation. But I would say its easy because its historically based on imperial units. Its easy to think about easy calculations like this in metric units like:
A 5% slope means descending 1 meter vertically for every 20 meters horizontally.
The gradient thing would work if ground speed and vertical speed were both in m/s, but km/h is more common in metric for a ground speed. You don't usually think in terms of hours during a climb/descent!
Glide slope of 3.6% would fit nicely though. Then, 100 km/h ground speed goes with vertical speed 1 m/s.
Metric navigation would use the fact 90 degrees of latitude is 10,000 km.
I suspect that the math is even easier using meters, meters, and meters per second than nautical miles, feet, and knots. I'll eat my hat if you can tell me the conversion from feet or inches to nautical miles without looking it up
This sums it up. Metric is nice and clean tenths, but the real world is seldomly easily expressed in clean tenths.
Another example: The feet is cleanly divisible in thirds, quarters, and twelfths, which is greatly appreciated in industry and particularly construction.
Also to be bluntly mundane, almost everyone can just look down and have a rough measure of a foot which is good enough for daily use.
Also, the "sterility" of metric doesn't do it any sentimental favours. Japan loves measuring size/volume in Tokyo Domes, for example.
If you're an amputee I truly am sorry for you and hope the handicap hasn't disrupted your life too much.
Jokes(...?) aside though, your absolute deference to precision is an example of why metric flies over people's heads. Feets, Tokyo Domes, arguably even nautical miles and so on are relatable at a human level unlike metric which is too nice and clean.
This sort of argument is odd to someone in a country which uses both, where a yard is intuitively "a bit smaller than a metre", a pint corresponds to a pint glass or "about half a litre" rather than anything meaningful and I'm aware that a rod and a furlong are things but have absolutely no idea what they correspond to. A foot is comfortably bigger than the average foot size, and an inch really isn't an easier unit to approximate than a centimeter
The SI was specially aimed to reduce such meaningless discussions, yet we steel have big endians and little endians comparisons, long after the dust settled.
One meter is about one long step for an adult. To approximate the length of a field, you just walk along it with big steps and count. It will not be correct, but pretty close. A cm is a little bit smaller than the width of your index finger. It's all bout what you are used to. Metric doesn't "fly over people's head" where metric is the standard way to measure things, but inches, feet, gallons, pounds, miles fly over our head because we are not used to it so don't have any frame of reference.
Basically solutions that were doing well in arc just threw thousands of ideas at the wall and picked the ones that stuck. They were literally generating thousands of python programs, running them and checking if any produced the correct output when fed with data from examples.
This o3 doesn't need to run python. It itself executes programs written in tokens inside it's own context window which is wildly inefficient but gives better results and is potentially more general.
So basically it's a massively inefficient trial-and-error leetcode solver which only works because it throws incredible amounts of compute at the problem.
