The Binary Gospel: 0 is Fake, 1 is True

Description

This image is a two-panel meme, presented as a screenshot of a tweet. The top panel shows a retro computer icon (a CRT monitor and a tower PC) next to the text 'my brother in christ that is the FAKEST statement I've ever heard' and a crudely drawn number 0 with a face. The bottom panel features the same computer icon with the text 'holy SHIT' and a crudely drawn number 1, also with a face. Below these panels, a tweet from user Silvia 'CosmicTailz' reads, 'computers be like "this shit true asf" and it's the number 1'. The meme humorously personifies a computer's interpretation of binary logic, where the number 0 represents 'false' and the number 1 represents 'true'. The joke lies in applying exaggerated, human emotional reactions to the fundamental and unemotional true/false distinction that underpins all of computing. It's a foundational computer science concept presented through the lens of modern internet slang

Common Tags

BooleanLogic DeveloperHumor CodingHumor TechHumor RelatableDevExperience

Comments

Anonymous ★ Top Pick The most insidious bugs are when you accidentally assign instead of compare, like `if (err = 0)`. You're not just ignoring the error, you're forcing the computer to accept a blatant falsehood as gospel

Anonymous ★ Top Pick

The most insidious bugs are when you accidentally assign instead of compare, like `if (err = 0)`. You're not just ignoring the error, you're forcing the computer to accept a blatant falsehood as gospel
Anonymous

Every senior dev knows the pain: months of stakeholder workshops distilled down to if(flag) { /* everything */ }
Anonymous

After 20 years of explaining to stakeholders why their 'simple' feature requires rewriting half the codebase, I finally understand computers' shock at discovering 1 is true - it's the same feeling I get when a PM says 'this should be a quick fix' and it actually is
Anonymous

Ah yes, the fundamental duality of computing: where every architectural decision, every algorithm optimization, and every heated technical debate ultimately reduces to a transistor somewhere deciding between high and low voltage. We've built entire civilizations on top of rocks we tricked into thinking, and their entire philosophical framework is literally '1' or 'not 1.' Meanwhile, we're up here arguing about microservices versus monoliths, when at the end of the day, it's all just very enthusiastic or very unenthusiastic electrons. The computer doesn't care about your elegant abstractions - it just knows if the bit is set or not, and honestly, that's the most honest code review you'll ever get
Anonymous

Hardware gives you one bit of truth; C blesses any nonzero, JS canonizes [], SQL answers NULL - and we still expect consistent feature flags
Anonymous

Holy shit, it's #1... on the cherry-picked synthetic benchmark leaderboard
Anonymous

Two decades of type systems later and truth still rides the zero flag - jz for “fakest,” jnz for “holy” - while a Windows API somewhere insists S_OK == 0, just to keep the congregation humble
@dst212 1y

Quantum computer:
1. @DenDrobiazko 1y
  
  or "well, it's not that simple..."
@deadgnom32 1y

#!/bin/bash true echo $? false echo $?
1. @deerspangle 1y
  
  Yeah, bash immediately came to mind as the counter example
@Araalith 1y

"Fakest" implies the existence of different levels of fakeness
1. @dst212 1y
  
  1 == 1 && 1 == 0 is not as fake as 1 == 0, I guess. 0 is the fakest of them all
  
  @Araalith 1y
  
  IMO, the greatest fake is 0.2 + 0.1 == 0.3
  
  @dst212 1y
  
  IMO, your statement is true
  
  @anatoli26 1y
  
  You can’t compare 2 floats for absolute equality as with == , check here: https://www.geeksforgeeks.org/problem-in-comparing-floating-point-numbers-and-how-to-compare-them-correctly/
  
  @dst212 1y
  
  Yeah I know that, I said I think "the greatest fake is 0.2 + 0.1 == 0.3" is true... sorry if I wasn't clear
  
  @TheRamenDutchman 1y
  
  This does work, but only with imprecise floats
  
  @Sun_Serega 1y
  
  and only because of output rounding
  
  @TheRamenDutchman 1y
  
  AFAIK it's the precision it stores the data with If sum is a 64-bit floating point integer (the default, here), then it does output 0.30000000000000004
  
  @Sun_Serega 1y
  
  ah, true, 32 bit float's need a different example
  
  @Sun_Serega 1y
  
  for 32-bit ones: 1/13 + 2/13 != 3/13
  
  @Sun_Serega 1y
  
  tho it's not because of better of worse precision
  
  @TheRamenDutchman 1y
  
  That checks out!
  
  @purplesyringa 1y
  
  all floats are imprecise, bruh
  
  @TheRamenDutchman 1y
  
  And reading comprehension is a b- 😁 I never said any kind of float is precise, just that a less-precise floats do add 0.2 + 0.1 = 0.3
  
  @purplesyringa 1y
  
  You're saying "less precise" as if there aren't floats with worse precision like f16
  
  @purplesyringa 1y
  
  This has nothing to do with precision
  
  @TheRamenDutchman 1y
  
  Ah ok. Then what did cause 32 and 64 bit floats to behave differently?
  
  @purplesyringa 1y
  
  Floats can exactly represent numbers like n / 2^m, i.e. an integer divided by a power of two. (Precision affects just the maximum value of n.) Notably, numbers like 0.1, 0.2, and 0.3 can't be represented like this, because their denominator contains 5. So when those numbers are encoded, the closest representable number is chosen instead. Basically the largest possible m is chosen, and then n is computed as round(0.1 * 2^m) (or 0.2, or 0.3 respectively). This rounding introduces the error, which is at most 0.5. (Again, note that this does not depend on the bitness of the float at all.) Adding up two numbers (0.1 and 0.2, both rounded to the nearest representable float) increases the error of the sum to at most 1. If we were lucky and the result was within 0.5/2^m distance of 0.3, we get true as the result of the comparison, because 0.3 is rounded to the same float; if the distance is a bit higher, we get false.
  
  @purplesyringa 1y
  
  To sum it up, the difference is due to how the representable numbers are distributed along the real line. As the precision goes up, the representations of 0.1 and 0.2 get more correct, making the sum more precise, but the representation of 0.3 also gets more correct, making it harder to match. These effects counteract each other, so whether you get true or false for a given float bitness is basically up to chance.
  
  @azizhakberdiev 1y
  
  I believe even web developers know the drills of safely comparing floats with epsilon
  
  @purplesyringa 1y
  
  I don't believe they do. Epsilon comparison has become such a cargo cult that it's done without a reason all the time, and then incorrectly in the few places where it does matter
  
  @azizhakberdiev 1y
  
  I guess those many cannot try learning
  
  @purplesyringa 1y
  
  I'm borderline wondering if you know what you're talking about yourself
  
  @purplesyringa 1y
  
  Not bashing you, of course, but there's quite a few things that seem obvious but aren't
  
  @purplesyringa 1y
  
  Say, how do you chose the right epsilon to compare with?
  
  @azizhakberdiev 1y
  
  usually as a factor of smallest operand
  
  @purplesyringa 1y
  
  Yeah, that's much better than just a constant, I've seen that too many times 💀💀💀
  
  @purplesyringa 1y
  
  Floats are very precise if you use them right. Integers in JavaScript are floats, and no one bats an eye. By the same measure, arithmetic like 123 / 2^32 + 456 / 2^32 = 579 / 2^32 is also valid in floats (64-bit, anyway)
  
  @azizhakberdiev 1y
  
  now that's somehow is optimized by the engine I suppose. Was it V8?
  
  @purplesyringa 1y
  
  Integers are floats as per the specification. As for V8, yeah, it applies some strength reduction like that
  
  @purplesyringa 1y
  
  Probably only for high-tier JITs? I think the interpret must be working with floats
  
  @azizhakberdiev 1y
  
  the last time I tried 0.1 + 0.2 in js it returned precisely 0.3
  
  @purplesyringa 1y
  
  It shouldn't have done that. Perhaps some stray rounding?
  
  @azizhakberdiev 1y
  
  I don't know much about v8 intricacies, but it sure does a lot if things under the hood. I doubt I would know the reason even if I learned v8
  
  @purplesyringa 1y
  
  I think you might just be misremembering
  
  @azizhakberdiev 1y
  
  okay, but I want to sleep peacefully without touching that cursed language
  
  @callofvoid0 1y
  
  i4 is more fuel efficient than v8
  
  @Araalith 1y
  
  .toFixed(x) is a recommended solution that already includes Number.EPSILON
  
  @TheRamenDutchman 1y
  
  Exactly, and 64 bit floats store as more data in the RAM, thus can store a much larger binary value and thus a much preciser representation of the decimal value Since 32 bit floats store less data to represent the decimal number, they are less precise This leads to 32 bit floats sometimes cutting off early, and thus representing the value differently than 64 bit floats in some cases
  
  @azizhakberdiev 1y
  
  Not all floats are IEEE-754. In C floats are originally integers with "floating point". It stores significant digits and exponent separately, achieving precise representation of small floating point numbers. But the more significant digits you have on the left side of the point, the less will be available for the other side
  
  @purplesyringa 1y
  
  Perhaps I'm missing something, but what platforms use something other than IEEE-754 these days?
  
  @azizhakberdiev 1y
  
  the reason ieee-754 is used is basically performance to precision tradeoff. It can equally store large and small numbers with floating point, without compromising either side of the point and basic operations on it are faster
  
  @purplesyringa 1y
  
  Are you saying that IEEE-754 is different from floating point? The former is an implementation of the latter, I don't see what this has to do with anything
  
  @azizhakberdiev 1y
  
  I just forgot how the other format was called
  
  @andrei_nik_kolesnikov 1y
  
  unums and posits are used in some scientific applications and neural networks because of course it would be used there. implementations exist in hardware and software, for instance https://github.com/artecs-group/PERCIVAL
  
  @purplesyringa 1y
  
  True that. It's been a while since I heard about them, I thought they were dead
  
  @andrei_nik_kolesnikov 1y
  
  there is a niche :)
  
  @echedelle 1y
  
  Gave me The Legend of Vox Machina vibes
@LeakyRectifiedLinearUnit 1y

then there's java
@Sun_Serega 1y

it's just different artifacts for different types
@TheRamenDutchman 1y

I also remembered 32-bit floats had trouble with `0.9`
1. @azizhakberdiev 1y
  
  it is as if you are trying to write 2.19191919191919, the number is rational but cannot be expressed in decimal form. Binary form has the same limitations

Use J and K for navigation

The Binary Gospel: 0 is Fake, 1 is True

Description

Categories

Common Tags

Comments

More like this

FPGA 'Field-Programmable' Scam: The Only Field Is GF(2)

Fun With Flags: Norway's Flag Remixed as Logic Gates

The Matrix: Neo Becomes 'The One' by Mastering Bitwise Operators