Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero one infinity rule

en.wikipedia.org

Post reply on HN
Print view View original

41–50 of 149 posts

Re: Zero one infinity rule

#41

Post by psychphysic »

crazygringo wrote: post #21
zeroonetwothree wrote: post #13

While 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…

Although that's also ripe for the annoyance of not being able to select all in border cases.

I'm much in favour of don't fuck with the basics (i.e. the core expect feature UI like select, copy and paste.).

Re: Zero one infinity rule

#42

Post by GauntletWizard »

Kim_Bruning wrote: post #2

Am I the only person who sometimes makes an exception for "two" ?

Wherever I need "Two" I usually find that what I actually need is a one and a many; there's not a master and a replica, there's one master and many replicas. There's not two places that the data is when doing a raid restripe, there's many places the data probably is and one place it should be.

Re: Zero one infinity rule

#43

Post by dragontamer »

alex_sf wrote: post #28
dragontamer wrote: post #17

This is probably a rule I believed in as a beginner, and completely don't believe in anymore today. Lets take a look at an exceptionally well designed system: single-error correction double-error detection codes. Also known as "ECC RAM". The implementation of this only works for *exactly* 64 bits + 8-parity bits. Now sure, we can talk about how we can generalize SECED ECC to different numbers of bits or whatever. But…

I would argue your example is a special case of only allowing one.

But it detects two-bit errors.

Which is nonzero, non-one, and non-infinity.

--------

SEC without DED is the classic implementation of Hamming error correction codes. The double error detection (aka DED) but is grafted on top of the theory, because it's useful in practice.

Re: Zero one infinity rule

#44

Post by neilv »

I first heard of "no arbitrary limits" in connection with GNU software. It was one of ways that GNU software not only had different licensing than alternatives, but was also usually technically superior.

(At the time, there were a lot of different workstation computer vendors, each with their own flavor of Unix. But where GNU tools existed, they'd usually be better than all of the Unix workstation ones. One exception was that the premium vendor C and C++ compilers generated better code and/or were more trusted than GCC at the time. GCC didn't take over until Linux, initially on x86.)

Re: Zero one infinity rule

#45

Post by Nullabillity »

dragontamer wrote: post #17

This is probably a rule I believed in as a beginner, and completely don't believe in anymore today. Lets take a look at an exceptionally well designed system: single-error correction double-error detection codes. Also known as "ECC RAM". The implementation of this only works for *exactly* 64 bits + 8-parity bits. Now sure, we can talk about how we can generalize SECED ECC to different numbers of bits or whatever. But…

It is generalized, you can chain together infinitely many blocks.

Re: Zero one infinity rule

#46

Post by layer8 »

crazygringo wrote: post #19

I'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 raise the question of whether it’s the program or the compiler that is nonconforming. If both are conforming, you want the program to compile 100% of the time. This isn’t possible if programs can have unlimited complexity.

The mindset is similar to embedded programming, where you have limited memory and absolutely don’t want to run into the situation that there’s not enough memory left to perform the operation that needs to be performed.

Re: Zero one infinity rule

#47

Post by HervalFreire »

zeroonetwothree wrote: post #13

While 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…

>While this has some theoretical merit,

What theoretical merit? It sounds like a completely made up rule of thumb based off of a persons anecdotal experience.

Re: Zero one infinity rule

#48

Post by at_a_remove »

I've had a different take on this that goes "Zero, One, Many." And that when you end up really using your software, the things that were "one" often become "many," and the unthinkable zeroes frequently became ones.

Re: Zero one infinity rule

#49

Post by adhesive_wombat »

stefan_ wrote: post #32
adhesive_wombat wrote: post #8

Earlier quoted context omitted.

You can still have both: an algorithm that technically has no formal numerical limit, but have warnings or errors when it reaches some condition that is clearly outside the design scope. For example, you might have a system that warns somehow if you start inserting items at the front of a vector with over a million items (when you originally expected the vector to be used for tens of items). If the structure is sudde…

Nope. "No formal limit" or "infinity" is just another way of saying "dynamic memory allocation". There is a reason you usually find this advice in game adjacent places; to punt everything to the dynamic memory allocator makes it very difficult to know if you are keeping within the memory-starved limits of e.g. the game console you are developing for, or on mobile to keep a garbage collector from stepping in and ruini…

"Nope." An "algorithm" can be about things other than memory allocation. Say you have a collection of sensors the you poll. ZOI is saying that the system that polls them shouldn't[1] have some kind of hard assumption that there will only ever be, say, specifically 4. You could still statically allocate the storage on a given system, for example in an embedded system where the software is compile-time configured for a given hardware.

However, if you pass the "poll_sensors" function a size of 60 million when the system was designed for "about 4, I guess", it's likely that you're operating the algorithm in a regime it wasn't designed for. You may (or may not, this is just another trade-off) wish to know about it.

[1]: of course you can always construct exceptions. If you follow every rule you subscribe to dogmatically, then you're doing something more akin to religion then engineering.

Post reply on HN