Y2GangnamStyle

December 2, 2014 5:14 PM

PSY's 'Gangnam Style' has more views than YouTube can count
posted by mysticreferee (80 comments total)

I'm thrilled. Love Gangnam Style. I feel like I've contributed to this.And so relieved it wasn't Justin Bieber.

I'm currently working on viewing "Blank Space" too much :)
posted by discopolo at 5:17 PM on December 2, 2014 [4 favorites]

catchy tune
posted by mullacc at 5:19 PM on December 2, 2014 [1 favorite]

How can I help. Can I take my view back?
posted by naju at 5:21 PM on December 2, 2014 [6 favorites]

They probably just changed it to an unsigned 32-bit integer so we'll just have this same problem in a few years again.
posted by Talez at 5:26 PM on December 2, 2014 [8 favorites]

Still one of the greatest moments in pop music history.
posted by escape from the potato planet at 5:28 PM on December 2, 2014 [60 favorites]

Psy2k!

(well, actually Psy2g, I suppose)
posted by mr vino at 5:33 PM on December 2, 2014 [10 favorites]

And so relieved it wasn't Justin Bieber.

Yes, what discopolo said. I'm perfectly happy with this honor going to a super goofy South Korean pop star.
posted by AlonzoMosleyFBI at 5:40 PM on December 2, 2014 [11 favorites]

Still one of the greatest moments in pop music history.

That is pretty neat, but my favorite mashup is still Anaconda Style.
posted by Jacqueline at 5:40 PM on December 2, 2014 [1 favorite]

2,147,483,648 is the new 32,786.
posted by localroger at 5:48 PM on December 2, 2014 [25 favorites]

Unsigned is more or less banned in Google code. No really. They'll just go up to 64-bit, which these days just means "long". And only use 63 of the bits.
posted by w0mbat at 5:49 PM on December 2, 2014 [6 favorites]

Finally, my food hoard comes into its own! * Runs off to survivalist retreat and awaits the fall of computers*
posted by lesbiassparrow at 5:53 PM on December 2, 2014 [4 favorites]

Still one of the greatest moments in pop music history.
posted by Wolfdog at 6:05 PM on December 2, 2014 [5 favorites]

Good, I don't like unsigned ints either. It doesn't provide the kind of safety people think it does and it only gives you 1 additional bit of size. In general I think their style guide is quite good. It's mostly free of fussy pedantry but contains some good advice for making readable and maintainable code.
posted by RustyBrooks at 6:08 PM on December 2, 2014 [2 favorites]

Small derail: Just saw the video for Hangover, in which Snoop Dogg guests. I think it's pretty close to the same level of insanity.
posted by Going To Maine at 6:08 PM on December 2, 2014 [7 favorites]

Meh, google and their 2³¹ limit. Twitter managed to get all the way to 2⁵³ before hitting the wall. (Javascript; it can't even do numbers right.)

All hell is gonna break loose January 19, 2038.
posted by Nelson at 6:13 PM on December 2, 2014 [2 favorites]

Good, I don't like unsigned ints either. It doesn't provide the kind of safety people think it does and it only gives you 1 additional bit of size.

Everyone's happy to sneer at the extra bit. "Oh, it'll never go that high! Let's keep it signed in case we want to expand into Bizarro Earth, where watching a YouTube video makes the view count go down and the comments are polite and thoughtful."

Right up until PSY hits 2,147,483,647 views.
posted by No-sword at 6:18 PM on December 2, 2014 [7 favorites]

Now is an excellent time to recall the finely-crafted Lo Pan Style. As magnificent as a six-demon bag.
posted by fifteen schnitzengruben is my limit at 6:21 PM on December 2, 2014 [9 favorites]

It doesn't provide the kind of safety people think it does

I'm really curious cause I've never heard anything but the opposite - what kind of safety do people think it provides?
posted by PMdixon at 6:24 PM on December 2, 2014 [1 favorite]

And to think, only a third of those views are from Psy-obsessed 9 month old babies.
posted by deludingmyself at 6:31 PM on December 2, 2014 [10 favorites]

Everyone's happy to sneer at the extra bit. "Oh, it'll never go that high! Let's keep it signed in case we want to expand into Bizarro Earth, where watching a YouTube video makes the view count go down and the comments are polite and thoughtful."

If you think you're going to get anywhere near 2^31, then you need a much bigger number than 2^32. Saving a bit just doesn't gain you that much. If you're banging against the highest number your OS supports, then sure, get the extra bit if you need it. But if you have room to expand, go higher than one bit.
posted by RustyBrooks at 6:34 PM on December 2, 2014 [1 favorite]

I was really hoping for a segmentation fault via youtube via PSY... for the unsigned critics.
posted by Divest_Abstraction at 6:34 PM on December 2, 2014

Still one of the greatest moments in pop music history

Wow, such an amazing clip on so many levels. I wanted to make fun of it but it gave me chills. Then to see the graying music executives in suits, trying to get down, and celebrities turning to the roaming dance cam with laser-like intensity. I wish Chuck Klosterman had written 3,000 words about this.
posted by mecran01 at 6:34 PM on December 2, 2014 [3 favorites]

> They probably just changed it to an unsigned 32-bit integer so we'll just have this same problem in a few years again.

They should really be using float, to count all the partial views and dropped streams.
posted by ardgedee at 6:35 PM on December 2, 2014 [2 favorites]

partial views

I've tried, does not compute...I've always been sucked into watching the whole thing.
posted by maxwelton at 6:45 PM on December 2, 2014 [1 favorite]

Once floating point numbers get big enough, x + 1 == x.
posted by mkb at 6:45 PM on December 2, 2014 [2 favorites]

localroger: 32,786.

Or 32,768. But who's counting. :)
posted by tonycpsu at 6:52 PM on December 2, 2014 [5 favorites]

Still one of the greatest moments in pop music history.

OK, I want to take a class where I can learn the Gangnam horsey dance and the Hammer dance.
posted by droplet at 7:19 PM on December 2, 2014

ok, to update someone else's long lost tumblr post from last year:

2,151,085,980 views, more or less?

2,151,085,980 x about 4min long = 8,604,343,920 minutes

which is 143,405,732 hours

which is 5,975,239 days

which is 16,370 years

is my math way off or has humanity spent the rough equivalent of 16,370 collective years listening to this song
posted by poffin boffin at 7:41 PM on December 2, 2014 [2 favorites]

So? How many years has humanity spent taking a dump or scratching it's balls?
posted by RustyBrooks at 7:46 PM on December 2, 2014 [2 favorites]

Hell, if every takes a 5 minute dump once a day, we spend 1100 years every day pooping.
posted by RustyBrooks at 7:48 PM on December 2, 2014

i think it's fucking awesome, and i don't care what you do to your balls, hoss.
posted by poffin boffin at 7:48 PM on December 2, 2014 [4 favorites]

Whoops, I was wrong, humanity spends 66,590 years/day pooping
posted by RustyBrooks at 7:51 PM on December 2, 2014

OH THANK GOD, this post finally got Shake It Off out of my head.
posted by desjardins at 7:59 PM on December 2, 2014 [2 favorites]

Still one of the greatest moments in pop music history
posted by T.D. Strange at 8:02 PM on December 2, 2014 [1 favorite]

If you think you're going to get anywhere near 2^31, then you need a much bigger number than 2^32. Saving a bit just doesn't gain you that much.

I don't understand this. It gives you double the ceiling. It's literally an additional order of magnitude. And if you're modeling a subset of the naturals, that bit isn't doing anything else.
posted by weston at 8:03 PM on December 2, 2014 [1 favorite]

32,786 / 32,768

Dammit my lysdexia is showing.
posted by localroger at 8:04 PM on December 2, 2014

This reminds me of when you would do the Super Mario Bros free lives trick and eventually weird symbols would start showing up under your life count.
posted by pizzosteez at 8:07 PM on December 2, 2014 [2 favorites]

You need unsigned ints to do expanded precision arithemetic. Addition and subtraction don't care but multiplication and division can be expanded handily from low rez to higher rez with unsigned versions but are a mess with signed versions. You can also do fine-grained scaling without floats by multiplying by a fraction multiplied by 2³² then taking the high order dword. That doesn't work if the multiplication is signed.
posted by localroger at 8:07 PM on December 2, 2014 [1 favorite]

I don't understand this. It gives you double the ceiling. It's literally an additional order of magnitude. And if you're modeling a subset of the naturals, that bit isn't doing anything else.

Increases are more likely to be exponential than linear. So you're more likely to need twice as many bits than you are to need just twice as large of a range. i mean, sure, if you have a counter that's increasing 1 at a time at a regular rate, an unsigned will give you 2x as much time. But for only 2x the space, you get a loooooot more. And if the increase is more than linear, then you've actually bought yourself some room.

That's why, for example, it's a sensible strategy to allocate twice as much memory every time you're short one byte, instead of allocating 1 more byte (or 10 or 100)

I basically never run into problems (as a programmer) where 31 bits isn't enough but 32 is guaranteed to be.
posted by RustyBrooks at 8:09 PM on December 2, 2014 [1 favorite]

I'm really curious cause I've never heard anything but the opposite - what kind of safety do people think it provides?

Arithmetic on a size_t (unsigned) can throw useful compiler warnings.
posted by a lungful of dragon at 8:17 PM on December 2, 2014

This reminds me of when you would do the Activision Decathlon pole vault trick and eventually weird symbols would start showing up under your point count.
posted by Guy Smiley at 8:24 PM on December 2, 2014 [1 favorite]

I'm sorry. Most of these views were me and my two kids. We've been watching the video straight for 16,000 years, apparently.
posted by greenhornet at 8:48 PM on December 2, 2014

Increases are more likely to be exponential than linear.

Sure, I get the argument that once you're counting something that can fill up half the represented space, it's likely you should consider that it may be able to fill up all the represented space (although I would also argue that it's worth being circumspect about the limits of that argument... some domains are in fact linear, and exponential often doesn't continue forever).

I just don't get why someone wouldn't have picked unsigned for this in the first place. At some decision point, someone was clearly evaluating the question and decided 2^31 was going to be big enough instead of 2^15. But since the machine is sizing out space in bytes anyway, why not have chosen 2^32 instead -- if nothing else, giving a future team a 2^31-sized buffer in which to change things on finding out 2^31 isn't big enough? What is the downside to using that otherwise unused bit?

Or if you like, consider the same argument from the present point instead of the past. You'd switch to 2^63 over 2^32 today, right? Maybe that is indeed more prudent. But since the machine is going to reserve the same amount of space for 2^63 and 2^64, what's the argument about why using that additional bit to hold another entire 2^63 space is bad?

This isn't a rhetorical question. If my software is somewhat more likely to catch fire in the future for using unsigneds, I'd like to know about it.
posted by weston at 9:00 PM on December 2, 2014 [1 favorite]

If my software is somewhat more likely to catch fire in the future for using unsigneds, I'd like to know about it.

It's easier for underflow to occur, which some compilers are smart enough to warn about at compile-time in some but not all situations (one example I mention above). It's not a syntax issue — the code will otherwise compile fine — but one of logic, where an unanticipated run-time condition leads your variables into unknown territory and things start breaking.
posted by a lungful of dragon at 9:08 PM on December 2, 2014

There's a problem with using unsigned int in C/C++ because the promotion rules are awful, and it quickly becomes quite complicated to understand what is going on even in simple expressions.

From a draft of the ANSI C standard:

3.2.1 Arithmetic operands

3.2.1.1 Characters and integers

A char, a short int, or an int bit-field, or their signed or unsigned varieties, or an object that has enumeration type, may be used in an expression wherever an int or unsigned int may be used. If an int can represent all values of the original type, the value is converted to an int; otherwise it is converted to an unsigned int. These are called the integral promotions.

The integral promotions preserve value including sign. As discussed earlier, whether a ``plain'' char is treated as signed is implementation-defined.
[...]
3.2.1.2 Signed and unsigned integers

When an unsigned integer is converted to another integral type, if the value can be represented by the new type, its value is unchanged.

When a signed integer is converted to an unsigned integer with equal or greater size, if the value of the signed integer is nonnegative, its value is unchanged. Otherwise: if the unsigned integer has greater size, the signed integer is first promoted to the signed integer corresponding to the unsigned integer; the value is converted to unsigned by adding to it one greater than the largest number that can be represented in the unsigned integer type. /22/

When an integer is demoted to an unsigned integer with smaller size, the result is the nonnegative remainder on division by the number one greater than the largest unsigned number that can be
represented in the type with smaller size. When an integer is demoted to a signed integer with smaller size, or an unsigned integer is converted to its corresponding signed integer, if the value cannot be represented the result is implementation-defined.

But in a halfway sane language, having a type for the natural numbers (or at least for nonnegative fixnums) is quite useful.
posted by Monday, stony Monday at 9:08 PM on December 2, 2014 [3 favorites]

I'm with weston on this. Saying it's "only" one bit doesn't make sense when that bit gets you an additional two billion views.

This isn't the first time the 31-bit limit has hit something I know of. I've noted before, Nethack stores its scores in a signed int, and using a number of tricks its possible to consistently, repeatedly earn a couple thousand points every few turns, which puts MAXINT in range for the truly dedicated player, enough so that the top 22 or so scores at alt.org are all that amount minus one.

In that case, the extra bit probably isn't enough, since it just means that players using those exploits will just do it twice as long. But YouTube videos aren't nearly as vulnerable to score-bumping exploits.

Probably though they should just use a 64-bit variable. Or maybe something like Python's bignums.
posted by JHarris at 9:16 PM on December 2, 2014

In reality, I'd imagine that they started working on support for higher view counts once Gangnam Style hit around a billion views. Yes, storing it as a 64-bit integer might have been better, but we should remember that two billion views is a heck of a lot of views for a video. Probably more than anything else has ever been watched ever.

(That said, I would have stored it as an unsigned int unless the language made it difficult/impossible to use one)
posted by No One Ever Does at 9:24 PM on December 2, 2014

Still one of the greatest moments in pop music Minecraft history.
posted by Celsius1414 at 9:33 PM on December 2, 2014 [2 favorites]

Math.
Bits.
Still one of the greatest moments in pop music history.
Some symbols.
Google.
More math.
Still one of the greatest moments in pop music history.
Symbols.
Symbols.
Math.
Still one of the greatest moments in pop music history.
Standards.
Poop.
Still one of the greatest moments in pop music history.
Mathity math-math.
Still one of the greatest moments in pop music history.

I'm fine with this going on this way for another MA^^T^H comments.
posted by Room 641-A at 9:33 PM on December 2, 2014 [8 favorites]

There's a problem with using unsigned int in C/C++ because the promotion rules are awful, and it quickly becomes quite complicated to understand what is going on even in simple expressions.

This sounds convincing. I left C largely behind in 1998, and sometimes forget how fraught with peril it can be.
posted by weston at 9:44 PM on December 2, 2014 [1 favorite]

his gigantic view count no longer displays any commas

This is the only part I understand.
posted by TWinbrook8 at 9:49 PM on December 2, 2014 [2 favorites]

It may also be relevant that most flavors of SQL don't have unsigned types. Come to think of it, I only know of one that does (MySQL). I'm not sure what Youtube has under the hood, but I'd bet that there's a database in there somewhere.

(And it's probably not MySQL.)
posted by kprincehouse at 9:50 PM on December 2, 2014

I find unsigned to be more useful for small types than large ones. Writing tight data storage structures or network protocols in java vs c# is annoying for precisely this reason - the difference between having ~32000 and ~64000 values comes up a LOT, and when you're storing (or transmitting) billions of whatever container defines the value, allocating 32 bits for each when you only really need 16 is dumb and actually has an impact.

Yes, storing it as a 64-bit integer might have been better, but we should remember that two billion views is a heck of a lot of views for a video. Probably more than anything else has ever been watched ever.

And keeping that in memory/disk for EVERY SINGLE VIDEO EVER is a really nontrivial amount of bytes. That number is going to represented many many times, from source of truth to cache to network chatter to display. Unsigned would make a lot more sense for this instance, good reasons for not using it in general aside. Sometimes there are exceptions to general rules, and those sometimes happen a lot in infrastructures that exceed the normal by orders of magnitude.
posted by flaterik at 10:09 PM on December 2, 2014 [1 favorite]

And keeping that in memory/disk for EVERY SINGLE VIDEO EVER is a really nontrivial amount of bytes.

Bit-shift tricks with C allow space savings.

For argument's sake, let's say 99.5% of YouTube's videos will likely never go over 2^30 hits (~1.1 billion impressions).

This seems reasonable for the time being, since YouTube only gets one billion visitors a month. Power law also suggests that very nearly all videos will not need a 64-bit hit counter, with a very small fraction getting the bulk of all traffic that would go over this limit.

So this allows use of one of the 32 bits (well, 31, signed) in the video's count index as a non-hit flag value, leaving the remaining 30 bits available as a counter value.

If that flag bit is off, then the video hit count is from the first 30 bits of the 32-bit integer. If the flag bit is on, the hit count is calculated from the 30 bits in the first 32-bit integer and the 31 bits from a second, signed 32-bit integer, which could be kept in a special, indexed storage table somewhere.

This kind of manipulation is fairly common in C. If you look at the source for bzip2, for example, you'll find code for constructing 64-bit integers from the "hi" and "lo" bits of two 32-bit int "building blocks".
posted by a lungful of dragon at 1:39 AM on December 3, 2014

Oh, it's sad how I never tire of these stupid elevator memes...
posted by biddeford at 3:06 AM on December 3, 2014 [1 favorite]

This is still my fave version of Gangnam. V creative.
posted by Zerowensboring at 3:36 AM on December 3, 2014 [4 favorites]

> It gives you double the ceiling. It's literally an additional order of magnitude. And if you're modeling a subset of the naturals, that bit isn't doing anything else.

There are a few good reasons for doing it the hard way, though, and they're not all purely technical. First, you don't want to be the project lead whose standards-breaking hack only worked until some other video a couple years from now breaks 5 billion views. You want a fix that ideally only has to be revisited some time after you retire.

Second, this is Google. Their solution of first resort for a data scale problem is logistical, not programmatical. In other words, they will throw more hardware at it. Which doesn't mean changing to 64 bit signed int is suddenly easy, but this makes it a lot easier than at companies that require you to budget storage.
posted by ardgedee at 4:01 AM on December 3, 2014 [1 favorite]

> is my math way off or has humanity spent the rough equivalent of 16,370 collective years listening to this song

"Gangnam Style's" view count represents one view apiece for a third of the world's human population.

Statistically speaking very few people have seen the video.
posted by ardgedee at 4:11 AM on December 3, 2014 [2 favorites]

Who's watching Gangnam Style all by themselves?
posted by Harald74 at 4:45 AM on December 3, 2014

In addition, I'm sitting at work reviewing some C++ code that is doing image recognition. I decide to give my poor head a rest and stop by Metafilter, and what do I find? Thank you, guys!
posted by Harald74 at 4:47 AM on December 3, 2014 [2 favorites]

"Gangnam Style's" view count represents one view apiece for a third of the world's human population.

It's a fairly decent chunk of the 40% or so of the population that has an Internet connection, though :-)
posted by effbot at 4:52 AM on December 3, 2014 [1 favorite]

If you're confused by all the numbers and stuff, most of what people are discussing in this thread is actually to do with minutiae of how the C++ programming language represents numbers. It's not really a math problem, more to do with engineering.
posted by LogicalDash at 5:30 AM on December 3, 2014 [1 favorite]

Rebecca Black wept.
posted by Chitownfats at 6:17 AM on December 3, 2014

RustyBrooks: If you think you're going to get anywhere near 2^31, then you need a much bigger number than 2^32. Saving a bit just doesn't gain you that much. If you're banging against the highest number your OS supports, then sure, get the extra bit if you need it. But if you have room to expand, go higher than one bit.

Nigel Tufnel: The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven and...
Marty DiBergi: Oh, I see. And most amps go up to ten?
Nigel Tufnel: Exactly.
Marty DiBergi: Does that mean it's louder? Is it any louder?
Nigel Tufnel: Well, it's one louder, isn't it? It's not ten. You see, most blokes, you know, will be playing at ten. You're on ten here, all the way up, all the way up, all the way up, you're on ten on your guitar. Where can you go from there? Where?
Marty DiBergi: I don't know.
Nigel Tufnel: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?
Marty DiBergi: Put it up to eleven.
Nigel Tufnel: Eleven. Exactly. One louder.
Marty DiBergi: Why don't you just make ten louder and make ten be the top number and make that a little louder?
Nigel Tufnel: [pause] These go to eleven.

Thank you, Google, for reminding us of that fine -- but important! -- line between clever and stupid.
posted by wenestvedt at 7:04 AM on December 3, 2014

keeping that in memory/disk for EVERY SINGLE VIDEO EVER is a really nontrivial amount of bytes. That number is going to represented many many times, from source of truth to cache to network chatter to display. Unsigned would make a lot more sense for this instance

Bit-shift tricks with C allow space savings. For argument's sake, let's say 99.5% of YouTube's videos will likely never go over 2^30 hits

It's true that at Google-scale, an extra byte here or there can really add up. There was a small bug with gmail where it sometimes stored messages with LF-terminated lines instead of CR LF-terminated or some such thing, but fixing it would have meant an increase in storage on the order of petabytes, so it stayed the way it was.

A huge amount of data at Google is stored in protocol buffer format, which has the ability to use integers with variable-length encoding. You can specify that playcount is an int64 field, but all the millions of videos with playcounts of < 127 will only use 1 byte to record that while the occasional breakout hit will use 4 or 5 bytes.
posted by jjwiseman at 9:00 AM on December 3, 2014 [1 favorite]

RustyBrooks:
I basically never run into problems (as a programmer) where 31 bits isn't enough but 32 is guaranteed to be.

Another point most programmers miss, because it used to be true: that there is some inherent advantage to programming with a mix of int & long, single & double.

If compilers are asked to optimize for size, some will probably cram two 16-bit integers in the memory of one 32-bit, but in general, with most compilers: no difference in size.

Nor is it a difference in size. 32-bit processors obviously process 32-bit addition just as fast as 16-bit.

But what about reals? Surely taking the square root of a 32-bit real takes longer than that of a 16-bit? (Obv. representing the same number.) In my experience on various languages, nope.

All of this is perfectly trivial to test for your usage, of course. But all of this is why I never use int instead of long, or single instead of double. Even if my variable is only going to count from 1 to 3, my code is just a little bit cleaner to read if all my integer definitions are identical, and likewise the reals.

Naturally, there are programmers out there for whom this won't be true (and most of them already know why they wouldn't dare do this) - but the vast majority of code written won't show any advantages in size nor speed by using the lower-limit data types.

If I knew all your code will run on 64-bit machines (like on the tallying machines at Youtube), I'd go further and require 64-bit types whenever possible, without regard to "smallness" of duty.
posted by IAmBroom at 9:50 AM on December 3, 2014

If you'll be dealing with flags and bit shifts unsigned is the way to go. Otherwise sign extension in shifts will annoy you (some other times that the behavior you need)

As a rule of the thumb, any unsigned you'll do -- on has to be watched very closely.
posted by coust at 9:51 AM on December 3, 2014 [1 favorite]

I've programmed in a lot of languages with no unsigned type at all. I've never once missed it.

This silly thing reminds me of a recent much more serious incident: August 12 2014, the day the Internet collapsed. A bunch of network gear had a hard-coded table limit of 512,000 BGP routes for the whole Internet. That stopped being enough and so suddenly random routes were being lost in random parts all over the Internet. Was a total mess for a few days.

While looking this up I found there are 2,716,686,944 currently routable IP addresses on the Internet, or 2³¹ + 569,203,296. By this measure the Internet is 63% full.
posted by Nelson at 10:10 AM on December 3, 2014 [1 favorite]

It's not really a math problem, more to do with engineering.

Since the post is about an easter egg that makes fun of Y2K and similar engineering mistakes, not an actual bug, it could be argued that the discussion here has more to do with engineers than with engineering :-)
posted by effbot at 10:36 AM on December 3, 2014

keeping that in memory/disk for EVERY SINGLE VIDEO EVER is a really nontrivial amount of bytes.

You are actually worrying about adding an extra FOUR BYTES to the size of each video they store. Expressed as a fraction of the storage required to store the video itself, that is precisely DIDDLY/SQUAT (in least terms). Which is another way of saying a really trivial amount.
posted by Wolfdog at 10:39 AM on December 3, 2014 [2 favorites]

The viewer count data is not like the video stream data though. The viewer count is probably being kept in RAM on many machines and has some complex distributed transactional system to be sure that it's updated consistently and atomically. Doubling the storage requirement for that counter could have a significant impact on those systems.
posted by Nelson at 10:53 AM on December 3, 2014

You don't have to store two ints for every video. Just ones that need it.
posted by a lungful of dragon at 10:59 AM on December 3, 2014

You are actually worrying about adding an extra FOUR BYTES to the size of each video they store.

As Nelson points out, it's adding it to the metadata, which almost certainly lives in different physical storage than the stream.

I do actually do this stuff for a living

Variable length encoding is a pretty good solution, and is one I'm using now to get around java's insistence that unsigned doesn't exist.
posted by flaterik at 3:31 PM on December 3, 2014

It's not really a math problem, more to do with engineering.

Finite math is math, and it's math that generally isn't taught any more even to computer majors because of ridiculous ideas about optimization being useless and double precision being adequate for everything and floats not being wasteful because coprocessors. Which is all fine and dandy until a rounding error floors you (which shows up in double precision but not single because of the way the libraries are written) because you don't know how the goddamn math works.
posted by localroger at 5:16 PM on December 3, 2014

BCD!
posted by PMdixon at 5:32 PM on December 3, 2014

BCD!

The only format in which money transactions should ever be handled.
posted by localroger at 8:01 PM on December 3, 2014

(And yet there's at least one major slot machine manufacturer that handles progressive awards as doubles.)
posted by PMdixon at 4:35 AM on December 4, 2014 [1 favorite]

PMdixon: (And yet there's at least one major slot machine manufacturer that handles progressive awards as doubles.)

All those words are English, and yet even Google can't explain to me what they mean. Help?
posted by IAmBroom at 9:30 AM on December 4, 2014

Slot machines and progressive awards are explained by wiki.

What PMdixon says is that the progressive award which is adjusted upward each time one of the machines is played is stored in a 64-bit double precision floating point variable, which means they are well prepared in case the jackpot doesn't hit before the Sun goes nova.
posted by localroger at 9:41 AM on December 4, 2014

(And also that fractional cents, which are basically unavoidable, are dealt with... Poorly.)
posted by PMdixon at 9:51 AM on December 4, 2014