Zero one infinity rule
111–120 of 149 posts
Re: Zero one infinity rule
#112While this has some theoretical merit, IME, limits are quite useful to catch bugs (or prevent degenerate cases). For example I was recently working on a permissions system wherein there can be members of groups. I set a reasonable limit on the size of a group based on a maximum of actual usage and what I could foresee being reasonable. A few days later, this limit was triggered, and I got a bug report. But it turned…
[deleted]
Re: Zero one infinity rule
#113I've read the article but I'm having trouble understanding the context of what this was in response to . The article quotes: > I formulated it in the early 70s, when I was working on programming language design and annoyed by all the arbitrary numbers that appeared in some of the languages of the day. Was it just an issue with languages in the 70's then? Because I'm struggling to think of any "arbitrary number" limit…
Lots of examples (e.g. maximum number of nesting levels), see for example: http://www.tendra.org/tdfc2-config/chapter2 https://www.ibm.com/docs/en/epfz/5.3?topic=reference-limits One aim of finite implementation limits is to define which programs are guaranteed to compile successfully, so that you don’t run into the situation that a program compiles on one implementation but not on another implementation, which would…
In the embedded world you're always mindful of memory consumption. Static allocation of a fixed size array has advantages over the same data in a linked list by simple virtue of eliminating node pointers and bookkeeping overhead associated with dynamic objects. Regardless of concerns about algorithmic complexity. Sometimes you really do need to set fixed limits for the sake of economy.
Minicomputers of the 70s and PCs of the 80s had computing resources comparable to what passes for embedded systems today (i.e. much less capable that an RPi). Those machines required tradeoffs with arbitrary limits to make realizable software and that is still a valid approach for a subset of modern programming where you can't just pretend you have an infinite store that will never be exhausted and if you do hit a limit you can't just throw more hardware at the problem.
Re: Zero one infinity rule
#114I'm consistently shocked by the number of people who have never heard of this principle. Introducing arbitrary numerical limits (emphasis on _arbitrary_, as performance limitations or other actual requirements obviously trump this rule) is a design decision that I find myself having to clean up after frequently. I see a lot of people here questioning the wisdom of the rule, however, like every other principle used in…
Limits are good. Limits mean that you can test your software under both min and max conditions.
If there’s no hard limit, then the limit exists merely in the developer’s mind as what they consider sensible or not.
Inevitably there will be some user who takes your software past what the developer considered sensible. And unknowingly and silently, this user becomes a tester in production.
The real problem is not DRYing your limits. There should always be one central point of truth, one constant that determines what the limit is.
Re: Zero one infinity rule
#115For the complete opposite point of view, see Limits in SQLite: https://www.sqlite.org/limits.html
Re: Zero one infinity rule
#116Earlier quoted context omitted.
You can’t justify infinity. The practical version of the rule is “zero, one, and out of memory”. The data structure doesn’t care about 12,001, but your real system does.
You absolutely can justify infinity - even if your real system can't represent numbers larger than X, you can't guarantee that won't change in the future. For example, in C, integers have minimum sizes, but no maximum. We're lucky nobody ever went, "well, our PDP-11 can only go up to 2^16, so let's set the maximum there." That's not to say it doesn't make sense to limit things after a certain point, but you'd damn we…
I can guarantee it’ll never be able to support infinity records. I can also guarantee that most data structures can’t even support a googol of records and never will. Some won’t ever support a quintillion records due to complexity, and quantum won’t fix all of those. There may be structures that support this, but they aren’t the ones we use today.
And the reason is that complexity theory is on shaky ground these days and needs a revision. Forty years and six orders of magnitude ago we treated a bunch of operations as constant , which is a clever fiction that is blatantly obvious now,but some of you knuckleheads continue to not look at. Most C terms are in fact stair-stepped log(n). Every time log(n) doubles and crosses a threshold, the cost of the operation doubles, and therefore is in log(n), not C. When you’re talking billions of records that distinction is already fairly obvious, and people dealing with trillions have to architect for it.
Memory access, as it turns out, is sqrt(n), not C, and with magic hardware might some day reach the cube root of n, and don’t count on it getting any better until we can bend space. With that sort of memory access a lot of O(1) algorithms perform worst than log(n) operations.
As you go into 128 bit addressing the difference between nlogn and n^3/2 * log(n)² becomes impractical. There’s a wall there, and we won’t get past it without completely different algorithms or desktop FTL technology.
The next order of magnitude of n will require a complete rewrite of that section of the code, so in practical terms the n only goes up in a new program, not the old one, and therefore the old program cannot and never will handle a thousand times more data than it was designed for.
Re: Zero one infinity rule
#117Earlier quoted context omitted.
You absolutely can justify infinity - even if your real system can't represent numbers larger than X, you can't guarantee that won't change in the future. For example, in C, integers have minimum sizes, but no maximum. We're lucky nobody ever went, "well, our PDP-11 can only go up to 2^16, so let's set the maximum there." That's not to say it doesn't make sense to limit things after a certain point, but you'd damn we…
I want to say, INT_MAX, but I know what you mean. It has been useful that the value varies by implementation (and even by compiler flag, on occasion).
I think you both need to watch some YouTube math videos on what exactly infinity means. As Everyday Maths put it, it’s not “count until you can’t count anymore and then add one to the number”. That’s the sort of wrong frame of thinking that makes you think that an infinite pile of hundred dollar bills is worth more than an infinite pile of one dollar bills. They are both worth $infinity.
We don’t have any algorithms that can deal with infinity, so stop pretending like we do. And we couldn’t build one unless the universe is infinite and expansions turns out to be incorrect. So no infinity in computer data structures.
Re: Zero one infinity rule
#118While this has some theoretical merit, IME, limits are quite useful to catch bugs (or prevent degenerate cases). For example I was recently working on a permissions system wherein there can be members of groups. I set a reasonable limit on the size of a group based on a maximum of actual usage and what I could foresee being reasonable. A few days later, this limit was triggered, and I got a bug report. But it turned…
Totally agreed. I think it's absolutely a best practice to set limits. Code is generally designed to operate within certain "reasonable" performance boundaries, and when it goes outside those you need to think whether code should be rewritten to accomodate it. Just a tiny example, but I regularly deal with long (800+ page) PDF's on my iPad, reading parts of them in the stock Books app. When I select text to highlight…
A soft limit would work well here, a prompt saying, “There are a large number of pages, it will take a while to select them all. Do you want to continue?” then it informs the user, rather than (maybe) artificially limiting them.
Re: Zero one infinity rule
#119Earlier quoted context omitted.
I think "should" is a bit strong here. There are always tradeoffs. Having support for very long names can cause other problems, like the opportunity for abuse, making it hard to format UIs, making human inspection of data much harder, or even limiting algorithmic efficiency. For example, US Passports have a relatively small limit for name length (I think it's around 20 characters each for first/middle/last).
“Who you are is inconvenient for me.”
My first name is defined to be the concatenation of all other forenames in the United States.
Re: Zero one infinity rule
#120Earlier quoted context omitted.
So you're confirming what I said. No theoretical basis. You just reaffirmed my position that this rule of thumb is anecdotal with your own anecdotal experiences. If you look through this very thread there are people talking about anecdotal experiences verifying the opposite effect.
Interestingly this sort of thing falls into a special category where reasoning from first principles is less rigorous than pattern matching to experience. That's because we don't have a good theoretical model. We're at the point in history where doctor who noticed less patients dying after they wash their hands argues with the doctor with a very erudite explanation of how that's impossible. Maybe someday we'll discov…
You recall mercury? Mercury was used by doctors for years as medicine and it was validated by anecdotal experiences. But it really had the complete opposite effect. It killed people. That is the reliability of anecdotes and an illustration of how delusional humans and "experts" are. Nowadays there's still no complete "theory" for medical science. We have partial theories like biochemistry but it's not a complete theory as in we can't completely derive which chemicals can cure which disease via a formal model.
In fact given the complexity of reality we may never ever have a formal model for medicine and as such we most likely will have to forever rely on asymmetrical nature of science.
Computing is bounded in a simulated universe axioms and logic. Computers are in actuality a part of reality but we try to use them as if they are seperate universes of pure logic and math games. To say that something has "some theoretical basis" is a very precise statement in computing because unlike medicine it is VERY possible for entities in such a bounded system to have a complete formal theory.
The problem is the Zero one infinity rule is not such a thing. The statement to say it has "some theoretical basis" is therefore completely false. Especially given the fact that in this thread there are a bunch of counter examples and I myself don't fully agree with it. How do you know this Zero one infinite rule is not just some form of mercury in disguise?
My disagreement, however, is NOT the point. The point is that this rule currently has ZERO theoretical basis. Additionally given the existence of counter examples, it likely will ALWAYS have zero theoretical basis. I don't completely deny the validity of anecdotal evidence, but, again, the claim made initially by the GP is false.