Seriously. This idea that humanity has not spent millennia analyzing these concepts is pervasive in the modern world, and the only thing I can think to attribute it to is a lack of education. Not because I want to be insensitive, but because as soon as you start absorbing material and integrating the real timeline, you can't unsee it.
Not that they didn't start their research and development with a bipedal robot, but you can notice that over time they went from more abstract leg concepts to far more humanoid leg concepts.
That tells us that the latter (for their intended use) is a superior design.
Exactly. Being able to organize your code in a way that provides distinct responsibilities per crate is just good practice.
And then the ability to enforce a formalized layer between crates and the way that they assemble into your application (i.e. the public API) is powerful for comprehension and maintainability. I go as far as documenting each crate with its own README that presents it as a standalone component with usage instructions, much like an open source library, even if it's only ever used in a single system.
I recently used it for a Rust profiler which writes Parquet files, so DuckDB then gives an easy SQL interface for things like summarization, analysis, and joins across runs.
Aren't you really just talking about the level of abstraction being applied? If there are infinite possibilities between zero and one, then it's just our way of relating to it that imposes the perception of a limitation.
No. You might be reading into it a little bit too much.
My point was that finding three needs to be possible for you to find it. If you are looking on the interval 0-1, it is not possible. As other comments have kinda of suggested, you could map every integer to a real and find "three" but if you are going to do that, why not just look on an interval that actually contains the number?
It's unclear to me at least what you mean here. In term of what is logically possible, if we take for granted that all integer numbers and more are mappable from a subset of this interval, then we do have this number.
Now, on logistical level, the mapping procedure is not free, it does have a physical/energetic/mental cost to handle it, and a more trivial representation of integer has a lower cost on this regard.
But the simpler integer representation can represent less many situations. If all one need to deal with in a certain frame is covered by a simpler shipper representation, from an economical perspective it can be argued it worth the risk of hitting a point where the representation will be insufficient as the situation evolved with cases it can't handle.
My impression is that your underlying premises are conflating all of this distinguishable aspects. But of course my impression is limited by my own narrow representation of the world, no matter how open and curious I can be about learning from experiences it makes me go through.
I think you are overthinking it too. The task was to find three, not something that is equivalent to three. However you choose to represent it, it wouldn't be hard to come up with a different "three" that you won’t find within that representation. If you are changing the representation, why wouldn't you just change the interval that you are searching?
What is the difference between 0.3 discrete units and 3 discrete units?
I sometimes wonder how much we allow the map to become the territory.
That said, I accept that literally, 3 never occurs between the ∞ of 0-1 -- unless, we are assuming symbolically, rather than actual, that in our particular ∞, something does not transcend entirely, which we really cannot know, because the closest we have ever come to a real infinity is a representation or symbol of it.
Edit: I realized that the question appears, or is, stupid. But when I see 0.3, I tend to see the 0.0, 0.1, 0.2 between. This is not what 0.3 is supposed to mean though. But on the testability of any real infinity, I do not budge.
I suspect a looseness with language; this often happens with maths done in natural language, and I may be guilty of it even when I try not to be.
If spacetime is infinite in extent yet discrete at the Plank scale, it would be ℵ₀; the Hilbert space is real-valued and therefore (a vector of) ℵ₁.
The Bekenstein bound, in practice, would do limit how much information can be actually encoded, even if all quantum states have an underlying real value and therefore even just one quantum value of one particle is ℵ₁ all by itself.
The easier and more secure way is to just inject sensitive credentials through a proxy service that ideally lives outside of the box in which the agent runs.
Because even if you're doing this in-memory replacement, the content still lives in they system's memory. So, it makes it less obvious to leak a credential, but it certainly doesn't prevent it.
I agree with you with one caveat. Professionally, your obligation is to be qualified for your job and ship work that you stand behind. Complete comprehension is absolutely necessary.
Personally, with side projects and tooling, go nuts. There's no reason to read all of that code.
Complete comprehension has never been a thing. Unless you were working solo with no dependencies, you never completely understood what was being shipped. I don't think an npm import vs an LLM implementation of a well-scoped, well-abstracted library is any different.
The recent DeepSeek release used Opus 5 as a reference point as well. I don't understand it. It's not like they're referencing superseded releases of other open models.
I think it clearly points to where they expect themselves to be, Opus 5.5 and Astra or Sol 6.1 are models that shouldn't exist at those prices without the price competition.
And no new releases from Chinese labs likely means their models that they could compare against those models are still baking largely because they lack compute so severely they need to train models for far longer, or figure out training on Chinese hardware.
Either way it's clear open models a lagging by ~1-2 months compare to frontier, depending on what frontier means to a person. Honestly most new models are just not that much better than at edge cases, they still fail a lot for the kind of stuff I do, but those edge cases matter a lot for un-interrupted long horizon work.
I personally am starting to see a wall here in llm development but that might just be me, given that people are being forced to scale models up considerably for frontier performance.
It's scary thinking that modern models will likely be at best 2-3% better in benchmarks or only useful in 1-2 unique edge cases compared to base models for 100x cost increase in compute required, it's getting absurd.
I can't imagine how Fable models can retain any value once you have to go 100x larger, while 27-32B models start to catch up to the current frontier for coding or other narrow/focused tasks in a year or so.
These models exist because better models exist, these models can't exist without better models existing, you will never beat the frontier with smaller model sizes. Because all these models are trained again larger models, generally a teacher model of sorts.
Lots of synthetic data, distilled data etc.
The problem is if we can pack a Fable in Qwen 4 27B who will pay subscription prices?
Synthetic data, distilled data, etc., does not necessarily mean data coming from outside of an organization. When we see performance increases with models like Haiku, it is because they are able to leverage the knowledge of larger architectures.
I fully expect that we will see increased performance from smaller architectures (to a point) simply because they are refined using larger ones.
> The problem is if we can pack a Fable in Qwen 4 27B who will pay subscription prices?
This is available to everyone developing these systems. Prices per relative unit of intelligence will continue to decrease. And market economics will continue to drive the cost down.
There is nothing inherent in the minimization process that says you must distill from a larger model. It is just the thing we know how to do right now.
It's not really if you mean to point to the bitter lesson, it was models/intelligence scales better with general/simple methods with more compute better than it scales with any hand-crafted human program/method.
Ala intelligence is a function of compute, there was no guarantee that you need to 10x compute for 10% better performance or something like that.
If you ask the labs they will say the scaling is fairly linear or atleast sub-quadratic, they definitely won't say it's exponential.
No one was thinking we need to 10x compute from here again for another 10-20% increase in performance.
It's only been since Opus 4.6 that the compute growth vs improvements are starting to feel this way.
For instance GPT-3 vs GPT-4 was practically a 10-100x jump for a 10-100x increase in compute, we went from broken sentences to fully formed essays writing, speech and so on.
GPT-4 vs GPT-5 was just as massive we went from no agentic capabilities to fully agentic, 10-100x for a 10-100x increase in compute usage.
GPT-5 vs GPT-6 was atleast a 10x (upto 100x) increase in compute, but the difference is not that clear sure people say that one is significantly better than the other, but GPT-5.5 was good enough compared to where we are today.
Even on benchmarks compared to GPT-5.2 Codex we have almost 2x'ed the performance on say artificial analysis (53 vs 29).
This is absurd. 10-100x increase in compute for 2-5x performance improvement is a massive gap.
i am referring to Sam Altman's own words in his "Three Observations" post: "The intelligence of an AI model roughly equals the log of the resources used to train and run it."
Except for all the legacy systems and embedded devices I have to deal with that have no certificate automation functionality and are still within their budgeted lifetimes. Those dumb things still require manual enrollment (or, at the very least, ugly one-off scripting to hand-puppet their stupidity) and the decreasing certificate lifetimes makes the problem that much more excruciating.
reply