Hacker News Reader

Comment by JoeAltmaier | Hacker News Reader

No! Even better! "Metric time" - a minute has 100 seconds, an hour 100 minutes, a day is 10 hours (100,000 seconds). Makes perfect sense on a space station so we'll have to face it sooner or later.

View on HN

Well while we're at it, what's the fetish with 10? We should use powers of 2 for everything :)

Powers of ten are easy to manage in base 10?

Yeah, but once you move everything to base 2, you won't have to deal with those pesky powers of 10 anymore ;)

Base 2? Nonono, everything is always base 10.

(If you don't get it, think about it longer.)

Not in gray code.

We should also use base-8 number system! http://infoverse.org/octomatics/octomatics.htm

I would prefer base-12; it has a lot of benefits. See http://en.wikipedia.org/wiki/Duodecimal, especially http://en.wikipedia.org/wiki/Duodecimal#Comparison_to_other_...

Instead of changing our clocks, we could just change our numbering system. Having 50 (that's 5 x 12) seconds per minute, 50 minutes per hour, and 20 hours per day seems perfectly reasonable.

Choosing a radix is a balance between the number of prime factors (and brevity) and the number of symbols to keep track of. I think twelve strikes a good balance as well.

But 12 only gains you one more factor that's not a power of 2, and is 30 times more difficult to implement (operation tables have 144 cells for base 12, compared to 4 cells for base 2).

That's why you should use the digits -n/2 to +n/2 for base n. That shrinks the tables by a factor of four.

Oh no, I just knew someone would come and argue for balanced n-ary on this thread :)

In that case 3 is your number. (Because it's the closest number to e, 2.71)

There is a currency based on it (with the provably least number of coins necessary to make any kind of change), ternary logic, balanced ternary is especially cool, etc.

Why is being close to e a good thing?

Actually, the best number depends. Basically, you want to have as few operations as possible, but you also want them easy.

Having base b for number n, you need log_b n digits where each digit is an element of (0..b-1). So working on those representations takes something like f(log_b n, b) operations. Where the function f depends on the operation you are looking at.

A good base should keep f small in relation to all n.

One very natural choice for f, I can't remember which at the moment, leads to e being the best base in theory---so 3 being good in practice.

If you are working with something like trees on disk (yes, data structures are very intimately related to numbering systems---read Okasaki's Purely Functional Data Structures for more information) a very big b, i.e. branching factor in this case, like 1024 is useful: Loading a new digit/node from disk into memory takes a long time, but once it's in memory, your operations will be fast.

I'd like to use base-11. Prime numbered bases eliminate lots of special cases.

Most of us have 10 fingers, which makes counting easy (although you can count to 12/20/24/40 on your fingers too, I admit).

Why stop there? Lets have base 1024, you can count to that on your fingers too!

http://en.wikipedia.org/wiki/Finger_binary

No, you can represent it with your fingers but not count it. By 'count' I mean an ordinal traversal of the sort you teach kids.

Use gray code.

Good luck teaching that to a 4 year old, or someone who's barely numerate. Higher bases are better for learning counting because the person can count a variety of small quantities without needing to understand the concept of a number base. It's not that I don't approve of binary counting by hand, but it's hardly useful for beginners or primitive societies.

Oh, for that application, my suggestion of gray code is even worse then binary.

Though actually, you are not really arguing for a large base, but for unary. (Or a mixed unary-large base system.)

Because it makes it so that the number four has another meaning that, for whatever reason, people can't get past.

I've tried to explain it to people before, but we never manage to count past four without someone laughing.

Then they're missing a far better number: 132

http://decimalti.me

There's a few ways to do it: as you can see, I like to use the 1/100 as the base unit (it's a little under 15 minutes in current reckoning) and go decimal beyond that since you have a neat percentage as a result, and you can drop off precision as needed.

We often (jokingly) measure time in kiloseconds around my office. As rue points out, that's just a bit over fifteen minutes, so its actually a useful unit.

"See you in the conference room in 2 ksecs..."

Put a bunch of geeks together too long and this is what happens.

Real geeks use milli-fortnight

Indeed.

http://www.google.com/search?q=fortnight+/+1000

1 fortnight / 1000 = 20.16 minutes

decimal time (using SI prefixes to the regular second) is regularly used in (physical) engineering disciplines.

Already done: http://en.wikipedia.org/wiki/Swatch_Internet_Time

And loads of date parsing / string emitting libraries already handle it :)

Reply on news.ycombinator.com