DEV Community: Bill C

Weird Color Stuff In The Terminal

Bill C — Mon, 01 Jan 2024 20:14:00 +0000

I recently got a new mac mini (not the latest and greatest, but plenty for my needs) and my intention is to use it for dev. Something I like to do is setup the terminal so that when I start a new session I get a little quote from Oblique Strategies.

There's lots of implementations for this existing in the wild, from the very old unix command fortune, to sundry web apps, to stuff written in modern languages. But, I wanted to diy the solution.

I had just gone through a fun tutorial for setting up oh-my-zsh with a nice color scheme from iterm2colorschemes.com and a decent prompt and I was wondering: can I make my oblique strategy look nice? how can you actually use the colors from your scheme in the output in your cli?

Terminal Color Basics.

The first clue for how to make your cli text output more colorful comes from the image defining the color scheme that you get from iterm2colorschemes.com. Here's the one for the scheme Peppermint.

Something you might notice is that there are things like 4dm along the top, and like (1;)?3dm off to the left of the table. And that's what this image is, its a table of all the possible text and background color pairs and how they look. But how do you use them?

The answer is an escape sequence. Try something like

echo '\e[1;35;47m walrus'

in your terminal. You should have the word 'walrus' with a preceeding space written in some fancy colors. Play around with different digits where the 5 and 7 are. Delete or include the 1;. Neat!

Of course, the colors will be from your color scheme, either the default, or from whatever scheme you've installed (that tutorial I linked above is super clear about how to do this).

If you're like me and you take your code looking like line noise as a code smell, you might want to try something a little more readable.

tput setaf 13; tput setab 7; echo ' walrus'

That should look the same as what you got from my earlier echo command. ; runs the command but doesn't append a new line to the output. setaf is 'set as foreground' and setab is 'set as background'. The 13 is 8+5: the 5 selects the base color, adding 8 brightens it (like using 1; did in the escape sequence). Like the table shows, there's 18 permissible foregrounds, and 10 permissible backgrounds. I'll let you work out how to get them all.

Strange state

So, I learnt this after some googling and stack overflow and looking at man pages for tput and terminfo and was feeling pretty good, but I wanted the background color to stretch to the end of the line, and for there to be colored lines above and below my one line quote. I reasoned some newlines would do the trick and ended up with something like

tput setaf 11; tput setab 4; echo "\n\n\t"walrus"\n"

and it worked! So I put it at the top of my .zshrc (because other stuff complained if I put it at the bottom) and when I source .zshrc'd it worked! And when I opened a new tab it didn't work!

What the hell? I went backwards and forwards with it a few times, and had a tab where sourcing the file worked, with the background color extending all the way to the ends of my empty lines and the line with text, and another where the color only covered the tab and the word 'walrus'.

This felt pretty crazy at the time. Somehow, the other stuff I was doing in the terminal, like editing files and resizing windows, was occasionally creating persistent state that was telling the terminal to use the background on the full line. And I wasn't alone in seeing this weird behaviour.

The accepted answer at that link talking about using an escape sequence to clear to end of line was good. I just defined \x1B[K as a variable and liberally sprinkled it in my output, and was finally seeing what I wanted. But I didn't like using tput for some escapes and the raw sequence for others. tput el was my friend (found on the man page for
terminfo after searching for the word 'clear').

Getting a random line from a file

Long story short on this one, the code ended up looking like

CLREOL=$(tput el)

oblique_line_no=$(( RANDOM%$(wc -l oblique.txt | awk '{print $1}') + 1 ))
oblique_line=$(sed -n ${oblique_line_no}p oblique.txt)

tput bold; tput setaf 11; tput setab 4; echo "\n${CLREOL}\n${CLREOL}\t"$oblique_line"${CLREOL}\n${CLREOL}"
echo

To decompose that a bit:

RANDOM makes a random number
$((...)) evaluates arithmetic, with % doing mod
wc will count lines of a file, but you need to trim the output a bit (the pipe into awk)
sed has a one liner to print just one line of a file.

Takeaways

Firstly, if you're going to dev, you'll spend some time on your command line, maybe even a lot. Make it something you like. I really love the off kilter suggestions from oblique strategies, you might love some ascii art, or a really stripped down experience. Whatever you want, make the terminal your own.

Secondly, test your code. I would never have seen that weird behaviour if I wasn't testing my code to see what it would do in a variety of circumstances, or rather, I would have stepped away thinking the problem solved, only for it to rear its head when I next opened a terminal.

Finally, don't give up! If there's an effect you want to achieve, the tools are almost certainly out there waiting for you to learn about them.

PS touch .hushlogin to remove the 'last login' stuff from your osx terminal. Concise articles are great!

OverThink: The Number of Zeros at the End of a Factorial.

Bill C — Sun, 01 Aug 2021 16:00:14 +0000

This is a deep dive into an interview question that explores several solutions, how you might get from one solution to another, and how you might weigh up which solution is right in which circumstance.

To provide some background about how this article came about, every week cassidoo puts out a newsletter that has some great content in it. A regular feature that I enjoy is the interview question (btw, a place that hits you with a weird question like this in your interview is maybe not interviewing in the best way, but its still pretty common and the idea of an 'interview question' makes sense to folks familiar with it so we're probably stuck with the concept for some time to come).

I use these little problems to practice a language I'm trying to learn, which at the moment is Scala3 (previously known as dotty, a language that is still a work in progress to some extent and whose tooling is not fully developed). In my code snippets in this article, I've tried to avoid using confusing idioms and syntax, so even if you're not familiar with Scala, you can probably still get the gist.

This week the question was

Given a positive integer n, write a function that finds the number of zeros at the end of n! in base 10.

I'm going to talk about 4 different solutions to this (well, 6 really), 3 that make sense in different contexts, and a fourth that is basically silly, but which was the reason I decided to write this all out.

Version 0

This version is correct and straightforward.

def factorial(n: Int): BigInt =
  (1 to n).foldLeft(BigInt(1))((a, b) => a * b)

def numberTrailingZeros(str: String): Int =
  str.split("[1-9]").last.length

def numberTrailingZerosOfFactorial0(n: Int): Int =
  numberTrailingZeros(factorial(n).toString)

We create a function to calculate the factorial, another to split off and count the zeros at the end of a string of digits, and apply the functions in that order, using a conversion to string so the types are right.

Notice that factorial maps from an Int to a BigInt. Scala has 3 integer types, Int, Long and BigInt. factorial(20) is the largest factorial you can represent using Long, so we should use the theoretically limitless BigInt. This brings up the next point.

Factorial values get really huge really fast. Calculating them gets very computationally intense. And all we want is the number of zeros at the end. Is there a way to skip the calculation of the factorial, and still work out how many zeros there are?

Version 1

You can do a little analysis of the question before you dive in to try and answer it. Firstly, the number of zeros at the end of a base 10 number is the number of times 10 can divide the number without remainder, so you could skip the string conversion, and test how many times you can divide the factorial by 10, which is a slight improvement, but there's more to discover.

Even if you're not great at maths, you can look at the values you get applying this function you've made, and notice they go up or stay the same as the number you're inputting increases. You might find yourself wondering when do they stay the same, and when do they go up. Some exploration shows you they increase whenever 5 divides the number, that is

numberTrailingZerosOfFactorial0(5*n - 1) < numberTrailingZerosOfFactorial0(5*n)

is always true.

But sometimes it doesn't go up by just 1.

numberTrailingZerosOfFactorial0(24) == 4
numberTrailingZerosOfFactorial0(25) == 6

What's going on? If 10 divides a number (evenly, without remainder) so do 2 and 5, and if 2 and 5 divide a number, so does 10. If you think about how we construct the factorial, you can see that there are always more 2s dividing it than 5s. So we need to count how many times 5 divides the factorial, because that will be the same as the number of trailing zeros. When we go from factorial(24) to factorial(25), we are multiplying by 5 twice, so it will have two more zeros at the end of its decimal representation.

We might make a function

def timesFiveDivides(n: BigInt): BigInt =
  if (n % 5 == 0 )
    1 + timesFiveDivides(n/5)
  else
    0

def numberTrailingZerosOfFactorial01(n: Int): BigInt =
  timesFiveDivides(factorial(n))

And we could check that it's returning the same values as our first version. But we're still calculating the factorial. That's not great, so let's call this v0.1.

Because 5 is prime, we can note that the sum of the number of times 5 divides the multiplicands is the number of times 5 divides the product. That is,

def timesFiveDividesFactorial(n: Int): BigInt =
  (1 to n).map(i => timesFiveDivides(i)).sum

val numberTrailingZerosOfFactorial10: Function[Int, BigInt] = timesFiveDividesFactorial

And finally, we're not calculating the factorial. Worthy of a v1.0. But, is this the best we can do? Not really.

Notice that the types are kinda weird. The arguments in (a to b) are necessarily Int. (a to b) is a lazy collection, by which I mean Scala represents it as an object that will tell you what is next in the collection, or if nothing is left in there, but it never creates the whole collection in memory, so its memory footprint is small. But it does kind of create a todo list, and Scala knows it can't deal with one that's absurdly large, so it restricts the types of the arguments to its smallest integer class, Int. Here, the todo list is as big as the initial input, so we're taking that many steps in our calculation.

We've stopped ourselves from calculating the factorial. Can we avoid taking so many steps?

Have a look at this intermediate value in our calculation of timesFiveDividesFactorial.

(1 to n).map(timesFiveDivides(_))

If you plug in, say, 32 for n, you get

Vector(0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0)

There are some pretty easy to see patterns, the 4 zeros then the non zero value, and those non zero values are 4 ones then a two. You could experiment and find out that for inputs above 125 its four twos and then a three, and in between those twos and threes you get identical patterns of zeros and ones, all 24 long and identical to the first 24 terms in our sequence.

We'll be talking about these sequences a lot in what follows. Summing the values of the sequence of length n accomplishes the same thing as counting the zeros at the end of factorial(n), so if we can understand these sequences and their sums, we might find better algorithms for our problem.

In fact, these sequences have a self similarity to them. By that I mean, if you take one of these sequences, of length n say, filter out the 0s and subtract one from everything left over, you get the sequence for n/5. You might want to try it out with your favourite language, this is key to understanding our next solution.

Using that self similarity we can write the following.

def betterTimesFiveDividesFactorial(n: BigInt): BigInt =
  val next = n / 5
  if (next == 0)
    0
  else
    next + betterTimesFiveDividesFactorial(next)

val numberTrailingZerosOfFactorial11: Function[BigInt, BigInt] = betterTimesFiveDividesFactorial

This is very simple as code, we're not creating large collections and we're certainly not performing large integer products. It will return after ceiling(log5(n)) steps, and each step is a comparison, an integer division and an addition. In a lot of ways this is what I would call the reference solution to this problem. Its the best solution in the majority of cases.

Version 2

What if you were going to be counting the zeros at the end of factorials for millions of people, hundreds of times a day each, over and over again? What if it was worth your time to find a faster algorithm?

Have a look at the sequence for 573. The highest number in the sequence is 3. It occurs 4 times, at places 125, 250, 375 and 500. The first 125 values in the sequence are repeated in the next 125, the 125 after that, and the 125 after that. Whats left has two 2s, at places 525 and 550, and the entries from 501 to 525 are identical to those from 526 to 550, and to those from 1 to 25. Then 4 copies of 0, 0, 0, 0, 1, which is how our sequence starts, and finally 3 zeros.

What's more, those first 125, 25 or 5 entries are the same in every sequence that's long enough to contain them, so if we know the sum of their values, we could use those sums to get to the number of divisors.

Using these insights we can do the following.

case class Power5(index: Int, power: BigInt, sum: BigInt) {
  def next: Power5 = Power5(index + 1, power * 5, power + sum)
}

object PowersOfFive {
  var cache = collection.mutable.Map[Int, Power5](0 -> Power5(0, BigInt(1), BigInt(0)))
  var highestPower: Int = 0
  def get(n: Int): Power5 =
    if (n <= highestPower)
      cache(n)
    else
      cacheMore(cache(highestPower), n)

  @tailrec
  def cacheMore(pow: Power5, n: Int): Power5 =
    if (pow.index == n) 
      pow 
    else
      val newPow = pow.next
      cache(newPow.index) = newPow
      highestPower += 1
      cacheMore(newPow, n)
}

val log5 = math.log(5)

def logBase5(n: BigInt): Int =
  math.ceil(math.log(n.toFloat)/log5).toInt

def ctfdf(n: BigInt, pow: Power5): BigInt =
  pow match {
    case Power5(i, power, sum) =>
      if (n < 5)
        0
      else if (power > n)
        ctfdf(n, PowersOfFive.get(i-1))
      else
        sum + ctfdf(n - power, pow)
  }

def cachedTimesFiveDividesFactorial(n: BigInt): BigInt =
  ctfdf(n, PowersOfFive.get(logBase5(n)))

val numberTrailingZerosOfFactorial2: Function[BigInt, BigInt] = cachedTimesFiveDividesFactorial

There's a lot going on there. An instance of Power5 stores

index - the power we're raising 5 to
power - the power of 5 itself
sum - and the times 5 divides the factorial of that power which is the sum of the first power terms of the sequence. It also has a method, next, to make the next Power5 instance for the next index.

The object PowersOfFive is a singleton that is caching all those Power5 instances, and storing them in a map, so we only need to calculate those once. It's worth noticing that we don't do it in a thread safe way, which would be a problem in a production environment.

Then we have cachedTimesFiveDividesFactorial which uses the helper function ctfdf. It finds the biggest power of 5 less than n, then pulls up the Power5 data we need, and starts using that to sum up the terms in the sequence.

Is it much faster? I ran a pretty unscientific test, and for all that extra, confusing code that won't work in a production environment, we only went about 50% faster. Not super worth it.

Version 3

Because I'm a recovering mathematician, I noticed something odd.

Power5(0,1,0)
Power5(1,5,1)
Power5(2,25,6)
Power5(3,125,31)
Power5(4,625,156)

Look at the power and the sum (the second and third entries in the triple): power == sum * 4 + 1 is always true. And if you know a bit about geometric series you can see how to prove that.

So, we have a calculation that is blindingly fast, and is right for all the powers of 5.

def approxTimesFiveDividesFactorial(n: BigInt): BigInt =
  (n-1)/4

But it starts getting stuff wrong pretty quickly. It thinks factorial(9) will end with 2 zeros, its actually 362880, which only has 1. But then its right again for a while, but guessing high by 1 on 13, 14, 17, 18, 19, 21, 22, 23, 24, before getting it right again at 25.

But if you're looking for patterns, there's plenty to see. Its right on the multiples of 5. Its wrong a lot when its one less than a multiple of 5. The wrong streaks build up, initially just a one off, then two together, then three, then 4.

We can get a bit more info by running

(26 to 50).map( i =>
  (i, 
  approxTimesFiveDividesFactorial(i) - 
  betterTimesFiveDividesFactorial(i))
)

which yields

Vector((26,0), (27,0), (28,0), (29,1), (30,0), 
 (31,0), (32,0), (33,1), (34,1), (35,0),
 (36,0), (37,1), (38,1), (39,1), (40,0),
 (41,1), (42,1), (43,1), (44,1), (45,1), 
 (46,1), (47,1), (48,1), (49,2), (50,0))

We've got our first multiple of 5 with some positive error at 45, and our first size 2 error at 49. But its all good again at 50.

Lets get a little bit more information.

def toBase5String(n: BigInt): String =
  if (n == 0)
    ""
  else
    toBase5String(n/5) + (n % 5).toString

(26 to 50).map( i =>
  (i, toBase5String(i),
    approxTimesFiveDividesFactorial(i) - betterTimesFiveDividesFactorial(i))
)

which yields

Vector(
(26,101,0), (27,102,0), (28,103,0), (29,104,1), (30,110,0), 
(31,111,0), (32,112,0), (33,113,1), (34,114,1), (35,120,0), 
(36,121,0), (37,122,1), (38,123,1), (39,124,1), (40,130,0), 
(41,131,1), (42,132,1), (43,133,1), (44,134,1), (45,140,1), 
(46,141,1), (47,142,1), (48,143,1), (49,144,2), (50,200,0))

In the triples, the first term is the number base 10, the second is the number base 5, and the third how much our approximation overestimates the number of times 5 is a divisor.

It turns out that if the sum of the digits in the base 5 representation is between 1 and 4 inclusive, the approximation is accurate. If its between 5 and 8, its over estimating by 1, if its between 9 and 12, its over estimating by 2 etc. It took me a while to notice this, and it took longer to realise why it was the case, and this article is already a bit long and tedious, so I'll just write down our final version.

def base5digitsSum(n: BigInt): BigInt =
  if (n == 0)
    0
  else
    base5digitsSum(n/5) + (n % 5)

def error(n: BigInt): BigInt =
  (base5digitsSum(n) - 1)/4

def sillyTimesFiveDividesFactorial(n: BigInt): BigInt =
  approxTimesFiveDividesFactorial(n) - error(n)

val numberTrailingZerosOfFactorial3: Function[BigInt, BigInt] = sillyTimesFiveDividesFactorial

What is worth noting here is that even though we found out more about how the values are moving around, and related them to something else, it didn't end up reducing the amount of work that we needed to do to get to our answers: we're still doing all the divisions of v1.1, plus some extra work. Our approximation wasn't a profitable avenue to consider when looking for good solutions to this problem.

Conclusion

I was hoping to help the reader realise a few different things with this article.

Firstly, a solution is a solution. Our first solution might be slow, but that might be good enough for what we're doing at the time.

Secondly, that if we want to work out how to take a slow, inefficient solution and turn it into a fast one, we should look at what we're asking the computer to do, what it will have to build in memory, how many steps it will need to take to get through our implementation and then try to imagine ways we can take shortcuts or rearrange and regroup the steps performed. Creating some concrete examples of the things you're creating can be really helpful.

Thirdly, good code isn't the same as fast code. v2 was quicker than v1.1, but it was ugly and complicated and would be hard to maintain, as well as having problems with parallel computations. v1.1 was a better solution in the vast majority of real situations.

Fourthly, having a clever insight into the problem isn't quite the same as a good algorithm. v3 used an interesting idea, but to make it work you had to do the same calculations as you did for v1.1, and a few more besides. It was still interesting to pursue though. I enjoyed running down what was going on and how to make the approximation work, even if it wasn't productive in the end.

Finally, Scala3 is a complete rebuild of the language in a lot of ways. They've done a lot of stuff that makes it a really great way to transition from object oriented code, to functional flavoured OO code, to fully fledged functional approaches. Its syntax is pretty clean and expressive. I strongly recommend it if you're looking to get into a compiled, strongly typed language from loosely typed, interpreted languages. The type system mostly gets out of your way. IntelliJ CE has good support for the language, and the worksheets feature means that if you copy my code from that gist I linked at the start, you can start running things, and writing your own functions, very quickly. The getting started guide is a great place to get started with an interesting language that is trying to do interesting things in a performant and production ready way.

Finally finally, if you go to cassidoo's page you can subscribe to her newsletter. Its reliably got something that I find worth my time, either the interview question or an article or a thought provoking quote. I strongly recommend it.

Thanks for reading!

Javascript's Numbers Are Weird but You Can Live With Them If You Understand Them

Bill C — Sun, 25 Dec 2016 15:07:42 +0000

Recently a friend ran into a pretty perplexing problem. They were storing IDs in the client as javascript numbers, and they started to see a difference between what was being sent by the backend and what was being seen after parsing the AJAX response. It wasn't a huge difference, but any difference was causing problems (as you'd expect).

What was going on?

To work it out, you need to understand how javascript represents numbers.

Javascript's Numbers Are a Little Weird

You can do the below calculations in your browser's console.

0.1;
// 0.1
0.1 + 0.1; 
// 0.2
0.1 + 0.2;
// 0.30000000000000004

Some folks get a laugh out of this dumb error, pointing out that computers are still kinda garbage. I even heard a guy joke that this error was why Matt Damon got stranded on Mars a few years back.

Now, fun is fun, but lets explore.

var martianError = function(){
  var epsilon = 1;
  while(((1-epsilon) !== 1) && ((1+epsilon) !== 1)){
    epsilon *= 0.5;
  }
  epsilon *= 2; // little bit more error for the hell of it (more or less).

  var maxDistanceFromEarthToMars = 410000000000;
  var distanceError = epsilon * maxDistanceFromEarthToMars;

  console.log("If you represent the distance to mars with "
            + "IEEE754 on this machine, you are out by "
            + distanceError + " metres, which is "
            + distanceError*1000+ " millimetres.");

  var thinPaperThickness = 70*0.000001;
  var thickPaperThickness = 180*0.000001;

  if(distanceError > thickPaperThickness){
    console.log("This is more than the thickness of thick paper.");
  } else if(distanceError < thinPaperThickness){
    console.log("This is less than the thickness of thin paper.");
  } else {
    console.log("This is about the thickness of a piece of paper.")
  }

  var averageDiameterOfHumanHair = 0.000100;
  var errorInHairWidths = distanceError / averageDiameterOfHumanHair;

  if (errorInHairWidths < 1) {
    console.log("Its less than the average diameter of a human hair.")
  } else {
    console.log("Its about " + errorInHairWidths.toFixed(0) + " human hair diameters.");
  }
}

martianError();

If you copy and paste that into the js console (and you're using an up to date chrome client), you'll find out how little error there is when we represent quantities in javascript.

So, sometimes numbers in javascript do stuff that is kind of stupid, and they're crazily precise at the same time. How can both of those be true?

Like every tool you use, to use it well, its a good idea to try and find out what problem it was designed to solve, the strengths and weaknesses of its design, and to clearly have in mind what you're trying to do with it.

Lets start by understanding what javascript numbers are.

Javascript's Numbers Are IEEE 754 Floating Point Numbers

Whenever javascript is representing a number, the computer uses a format for that number called IEEE 754.

The IEEE is the Institute of Electrical and Electronics Engineers, and its objectives are the educational and technical advancement of electrical and electronic engineering, telecommunications, computer engineering and allied disciplines. It has a standards association, and they periodically create standards. They mostly describe key aspects of modern computing hardware, and how modern floating point numbers work was standardised in the 80's in IEEE 754.

Floating point numbers are the computers attempt to describe quantities like Ï€ or the square-root of 2 as well as measurements of things, like the distance to mars and the width of a hair, and the outcomes of calculations using these quantities. They do it in a complicated way using a sign bit, a base, an exponent for the base, and some digits, or rather bits, of the number, which are called the mantissa. Used together, these describe magnitudes in much the same way that scientific notation does. On your computer now, you probably have 11 bits used to describe the exponent, and 52 bits to describe the mantissa (which is where the precision of the representation comes from).

The representation of 0.1 looks like

0 01111111011 1001100110011001100110011001100110011001100110011010

The first bit is saying that the number is positive, the next 11 say that its between a sixteenth and an eighth, and the rest of the bits are there saying where exactly it is between those two powers of two, using binary (there's actually a hidden extra bit, making 53 a magic number, and the rounding is done in a smart way, but these are technicalities). You can experiment with how other numbers are represented here.

The biggest reason I can be so confident about how your floating point numbers are represented is because the IEEE 754 standard was so successful. When it came out a lot of computing was about the scientific modelling of complex physical and economic systems. There were massive mainframe computers being designed and sold and they had different ways of representing floating point numbers, and new and different floating point architectures were frequently being designed. Sometimes good choices were made in these designs, and sometimes bad.

Mathematics libraries had to be checked against, and frequently rewritten for, every new architecture, and there were't any guarantees that your calculations and mine would end up with similar conclusions (especially when calculations dealt with a thing called underflow).

IEEE 754 made good architectural choices so the designers of new mainframe architectures could worry about implementing the standard, rather than working out a new floating point system. Code involving complicated calculations could be shared between researchers on different systems with the certainty that the architecture would do the right thing by the floating point calculations.

IEEE 754 made computing massively more productive. And then what we did with computers changed. We stopped using them for scientific calculation and started using them for money and social media and MMOs and probably dozens of other things besides. IEEE 754 wasn't built for these, but it was still a pretty good choice for a number system because it is good with 3D modelling, and can represent integers and fractions with one system.

But there are quirks.

Floating Point Numbers Aren't a Great Fit for Money or Internet Points or Database IDs

Remember my friend with the weird database ID problem? They realised that the values where the IDs started to get wonky was in the high 16 digit numbers. The smallest positive integer that 64 bit floating point numbers can't exactly represent is 2⁵³ + 1 which in decimal is 16 digits long and starts with a 9. My friends values were getting truncated to fit in the 52 bit mantissa of their IEEE 754 representation. So we can conclude that javascript's numbers are incompatible with the 64 bit integers that are used as IDs for most of our database tables.

Moral of the story: never store database IDs as numbers in the client. Pass them to the client as the decimal string representing the number. It probably won't bite you in the first year of operation, but its easier to do a little sensible planning before you're scratching your head on a really tough bug like this. Also, notice that you're never going to want to do a computation with an ID, so storing it as a number is unnecessary anyway.

What about money? 10 cents plus 20 cents is exactly 30 cents, not approximately 30 cents, and people are pretty picky about calculations and numbers involving money. I think people are okay with a bit of waiting on the server when they're purchasing, so my advice would be to do your monetary calculations in the back end, using a numeric type like ruby's BigDecimal, and to pass them to the frontend as strings. Other approaches, like working in integer representations of the smallest value you're interested in (and perhaps trusting that your numbers will be smallish) can also work. However, if that smallest value changes (suddenly the business wants to track tenths of a cent, for example) you'll be in for a rewrite of some pretty important business logic. Using a dedicated decimals library, on the other hand, is pretty future proof.

For things like game scores, or the number of likes a tweet has, or the number of seconds since you last posted on your timeline, you need to think through how much errors will be tolerated, how important the values are to people, and how big those values are likely to get (getting more than 2⁵³ likes on a tweet might be possible one day, but its not going to be tomorrow). Weighing these is a lot easier now you know the limitations of javascript's numbers.

IEEE 754 is actually pretty cool

If you had said to people working during the 1980s on mainframes doing massive scientific modelling tasks that folks would do masses of commerce on computers that fit in their pockets, they would probably have been at least a little surprised.

If you went on to describe the values social media tracks, and MMO points, and all the numbers that our modern web apps track, they would have been even more surprised and they might have said "floating point numbers probably aren't a great fit for those purposes". If you'd mentioned using them to track database IDs they would have had questions about how many bits were in the integers and the floating point numbers, and quickly concluded that you were heading for a problem.

These days our lives are a bit simpler. The vast majority of integers are 64 bit integers (still sometimes called long) and our floating point numbers are all IEEE 754 and more often than not, 64 bit (called double sometimes). But a language which doesn't give you a separate numeric type for integers, like javascript, makes life a little tricky when you try to represent large integers in that language.

One thing that floating point numbers are great for is 3D graphics, which makes things like three.js and augmented reality apps possible, which are super cool. All the weather modelling and sundry other things that IEEE 754 have made possible have allowed humanity to progress in important ways and that's also super cool (in a less trendy way).

For the problem they were made to solve IEEE numbers are great. Its only when we try to stretch them outside of their use case, which javascript tempts us to do, that things fall apart. We can avoid that by leaning on the server when we need to, not using numbers when we don't have to, and giving people meaningfully truncated values when they don't need more than a dozen digits of precision.