5 ms·

> Claiming that bits are not bits is on a flat earth level stupid Not necessarily, just a statement from the starting end of Dunning-Kruger. Try 0.1 + 0.2 with

> Claiming that bits are not bits is on a flat earth level stupid Not necessarily, just a statement from the starting end of Dunning-Kruger. Try 0.1 + 0.2 with enough decimals and you'll see what he's trying to say. It's not that stupid of a thought if you think about it. Something else that might seem equally stupid the first time you hear about is the fact that 1s have weight compared to 0s. Don't believe me? Look it up. You comparing him to a flat-earther despite domain knowledge is worse than him having enough outside-the-box thinking to entertain the thought.

sebzim4500 4y ago
Not to mention the fact that sometimes bits are not bits, for example see undefined values in optimizing compilers can act as if they have multiple bit representations at the same time. I can kind of see how a little knowledge can be a dangerous thing here, I don't think that the guy who said that is necessarily stupid. Certainly not flat earth level.
buildbot 4y ago
Not sure if you are serious, but that is a flawed understanding of floating point. 0.1+0.2 being slightly off of 0.3 is a floating point issue, but will be exactly the same on any normal FPU. The bits are still just bits. I literally work on floating point stuff. Want to explain the 1 and 0 comment? Because depending on your silicon design and encoding either could be… Outside the box thinking is great, but being bounded a bit is essential.
- worksonmine 4y ago
  Instead of repeating myself I just refer to my other reply: https://news.ycombinator.com/item?id=35139162 https://news.ycombinator.com/item?id=35139162
  - InitialLastName 4y ago
    When you think you're clarifying yourself, you're actually getting less coherent. I can't even parse what you're saying in your deeper replies (and I design mixed-signal audio systems for a living). You're doing the same kind of "affect wisdom by alluding to the elephant without mentioning the elephant" hand-waving that conspiracy theorists do, but as yet you haven't shown a meaningfully concrete example (other than your misapprehension that the same sort of implementation-specific inconsistencies that are found in floating point calculations exist in the fixed-point math used in most audio systems).
    - worksonmine 4y ago
      Look. If I just made the .1+.2 example in passing by as how code doesn't always behave like we expect, does that mean I'm claiming we even use addition to work with sound? If everyone misunderstands a claim I haven't made, and asks me to explain that claim, how exactly do I respond? It was an example I don't know how audio works and don't claim I do. But I do know moving bits doesn't always end up the way we expect, and different functions has different outcomes. I shouldn't have to explain sort and sort-reverse has different outcomes, it's implied and not my point. All I'm saying is don't call people without domain knowledge idiots when they're on the right track, kind of. The rest are strawman arguments I'm supposed to explain. I'll give you an example: > ME: 1s and 0s in the same order are the same, but some data may be lost in the transfer > Poster: Please explain? If the 1s and 0s are still in the same order, what data has been lost? What I say: 2 files 1010 and 1010 are the same at start, but might be 0101 at the destination. How is irrelevant, there are a million ways. What I'm asked to explain: If 1010 is 1010 at destination, how are they different. Then I mentioned transfer, oh-oh. Now we're going into transport protocols and not just moving bits no matter the means. Incredibly frustrating and ironic given the context. I see the misunderstandings, I just can't seem to explain it. It's not hand-waving I just don't get why I have to explain things I never claimed.
      - alex_sf 4y ago
        This is just word soup. You never explained or claimed anything meaningful.
        worksonmine 4y ago
        That's my entire point. I never claimed anything. I'm told I did and asked to explain all these strawmans. I see the title attracted all the "actually" people in the world. Look at my first post. I'm trying explain how I read "bits are bits" and that it doesn't necessarily mean that he's stupid. Are bits always bits? Tell me where you're confused instead.
      - Tor3 4y ago
        This seems to boil down to a claim that when transfering data from A to B then B may be different from A. No, it won't, and that's the point. Data transfer via a reliable protocol, e.g. TCP (and when using UDP you simply apply a framework with its own error correction, as e.g. OpenVPN UDP does). I mean, in my job we transfer petabytes of data.. if B wasn't equal to A.. no. What can, and does, happen is that the data at A or the data at B could experience bit flips typically due to cosmic radiation - this does happen, which is one reason ECC RAM is better for some situations, but if this happens during transport then the protocol will handle that and you still get B = A.
TedDoesntTalk 4y ago
> 1s have weight compared to 0s Like that one time I set all RAM in my phone to 1s and couldn’t lift it anymore. /s
- xen2xen1 4y ago
  Interesting security concern.. At the next Defcon someone announces they've hacked the NSA by weighing their computer to find the number of 1s and 0s.
  - TedDoesntTalk 4y ago
    … or a new exfiltration technique even for air-gapped devices
    - xen2xen1 4y ago
      Yeah, that does sound like a Defcon talk.
  - worksonmine 4y ago
    I know you're being funny, but researchers in a lab got an encryption key by listening on the spinning discs if I remember the paper correctly. Was front-page few years ago.
    - xen2xen1 4y ago
      Yeah, I've read quite a few stories like that, so that was only half a joke. Even the CPU stuff like Spectre and meltdown are almost as crazy.
- prewett 4y ago
  Technically flash memory storage would weigh more as a 1 (or maybe as a 0, depending), since it works by storing electrons. Apparently it stores something like 500 electrons [1]. My phone has 6 GB of storage, so if they are all ones that gives an extra weight of 2.50e-13 g, which is 0.0001 nanograms. Probably not measurable, though, especially since the large mass of the phone relative to the change in mass eliminates a lot of sensitive measurement techniques. I'm not sure if RAM would have extra weight, as I know less about how it works. [1] https://electronics.stackexchange.com/questions/505361/how-many-excess-electrons-are-in-a-modern-slc-flash-memory-cell https://electronics.stackexchange.com/questions/505361/how-m...
SAI_Peregrinus 4y ago
Audio doesn't use floating-point, it's all fixed-point. So there's no rounding error, only quantization error, and that can be controlled to whatever degree of precision is needed. 1s don't have weight compared to 0s, electrical "high" has mass compared to 0V. Which is "1" and which is "0" (if any) depends on the particular electrical specification of the protocol. E.g. with Ethernet signals are differential, ±3V, with 0V only ever reached momentarily as the + and - switch. There are also lots of cases where the "active" (i.e. "1") is the 0V value, and the "passive" (i.e. 0) is the nonzero voltage. Most reset signals are active-low.
- worksonmine 4y ago
  Haha, you're all making the same misunderstanding as the post I was replying to. The context of the "bits are not bits" is in relation to memcpy, and his lack of understanding that it's not comparing bits to bits, but the method used to transfer said bits. Which is exactly my point with 0.1 + 0.2. Depending on the methods it will give different outcomes, some more precise than others. Guess it wasn't as obvious as I initially thought. 1s and 0s in the same order are the same, but some data may be lost in the transfer and I don't see why that has to be explained, here of all places. And that's where the Dunning-Kruger reference came from, he thinks it's the bits, when in-fact he would mention the transport had he had more domain knowledge.
  - tremon 4y ago
    1s and 0s in the same order are the same, but some data may be lost in the transfer Please explain? If the 1s and 0s are still in the same order, what data has been lost?
    - worksonmine 4y ago
      Please try to read it as I say it I don't know how to be clearer. 0001 == 0001. But 0001 + 0001 does not necessarily end up being 00001. Do you see my point now? You're missing the forest for the trees. 2 things are being discussed, not the outcome. Transport and bits, at the same time, but as separate things. Another analogy in another comment was analog wires, also good, break that and the resistance changes etc etc etc. This many comments for something so simple. Breathe and stop going out of your way to misunderstand me. Ironically exactly how this thread even started. You clearly understand the subject since you already explained floating point arithmetic. I'll give it one last shot: The person being referred to as flat-earth level stupid mentions bits, while he should've mentioned transport. And not taking into account his lack of domain knowledge and using the wrong lingo to misunderstand him and calling him stupid when he is right, just not wording it correctly is the problem.
kabdib 4y ago
> 1s have weight compared to 0s This is a simplistic view how memory and data transmission systems work. Even in days of yore it took a schematic to figure out whether bits were being stored as "lots of electrons means a 1, few electrons means a zero", or the inverse. Modern memory systems and fast serial buses often use whitening to reduce noise and improve clock recovery. A 1 is a 1 when the CPU decides it's a 1, and even then its physical representation is not necessarily static.
- worksonmine 4y ago
  Doesn't make my claim wrong though. It's an interesting fact just to make a point that sometimes it's not as simple as we assume. Also why I asked him to look it up instead of explaining the how and in what circumstance. I'm sure he's able to find that out, it's not important to the point.
  - Tor3 4y ago
    I saw that earlier claim that ones are heavier than zeroes.. could you explain what that even means? And what kind of effect that's supposed to have? I'm genuinely curious about where that comes from.
    - worksonmine 4y ago
      Ones as in has matter. Not the correct wording if we're literal sure, but that's nitpicking. You know what I mean.

sebzim4500 4y ago

Not to mention the fact that sometimes bits are not bits, for example see undefined values in optimizing compilers can act as if they have multiple bit representations at the same time. I can kind of see how a little knowledge can be a dangerous thing here, I don't think that the guy who said that is necessarily stupid. Certainly not flat earth level.

buildbot 4y ago

Not sure if you are serious, but that is a flawed understanding of floating point. 0.1+0.2 being slightly off of 0.3 is a floating point issue, but will be exactly the same on any normal FPU. The bits are still just bits. I literally work on floating point stuff. Want to explain the 1 and 0 comment? Because depending on your silicon design and encoding either could be… Outside the box thinking is great, but being bounded a bit is essential.

worksonmine 4y ago
Instead of repeating myself I just refer to my other reply: https://news.ycombinator.com/item?id=35139162 https://news.ycombinator.com/item?id=35139162
- InitialLastName 4y ago
  When you think you're clarifying yourself, you're actually getting less coherent. I can't even parse what you're saying in your deeper replies (and I design mixed-signal audio systems for a living). You're doing the same kind of "affect wisdom by alluding to the elephant without mentioning the elephant" hand-waving that conspiracy theorists do, but as yet you haven't shown a meaningfully concrete example (other than your misapprehension that the same sort of implementation-specific inconsistencies that are found in floating point calculations exist in the fixed-point math used in most audio systems).
  - worksonmine 4y ago
    Look. If I just made the .1+.2 example in passing by as how code doesn't always behave like we expect, does that mean I'm claiming we even use addition to work with sound? If everyone misunderstands a claim I haven't made, and asks me to explain that claim, how exactly do I respond? It was an example I don't know how audio works and don't claim I do. But I do know moving bits doesn't always end up the way we expect, and different functions has different outcomes. I shouldn't have to explain sort and sort-reverse has different outcomes, it's implied and not my point. All I'm saying is don't call people without domain knowledge idiots when they're on the right track, kind of. The rest are strawman arguments I'm supposed to explain. I'll give you an example: > ME: 1s and 0s in the same order are the same, but some data may be lost in the transfer > Poster: Please explain? If the 1s and 0s are still in the same order, what data has been lost? What I say: 2 files 1010 and 1010 are the same at start, but might be 0101 at the destination. How is irrelevant, there are a million ways. What I'm asked to explain: If 1010 is 1010 at destination, how are they different. Then I mentioned transfer, oh-oh. Now we're going into transport protocols and not just moving bits no matter the means. Incredibly frustrating and ironic given the context. I see the misunderstandings, I just can't seem to explain it. It's not hand-waving I just don't get why I have to explain things I never claimed.
    - alex_sf 4y ago
      This is just word soup. You never explained or claimed anything meaningful.
      - worksonmine 4y ago
        That's my entire point. I never claimed anything. I'm told I did and asked to explain all these strawmans. I see the title attracted all the "actually" people in the world. Look at my first post. I'm trying explain how I read "bits are bits" and that it doesn't necessarily mean that he's stupid. Are bits always bits? Tell me where you're confused instead.
    - Tor3 4y ago
      This seems to boil down to a claim that when transfering data from A to B then B may be different from A. No, it won't, and that's the point. Data transfer via a reliable protocol, e.g. TCP (and when using UDP you simply apply a framework with its own error correction, as e.g. OpenVPN UDP does). I mean, in my job we transfer petabytes of data.. if B wasn't equal to A.. no. What can, and does, happen is that the data at A or the data at B could experience bit flips typically due to cosmic radiation - this does happen, which is one reason ECC RAM is better for some situations, but if this happens during transport then the protocol will handle that and you still get B = A.

TedDoesntTalk 4y ago

> 1s have weight compared to 0s Like that one time I set all RAM in my phone to 1s and couldn’t lift it anymore. /s

xen2xen1 4y ago
Interesting security concern.. At the next Defcon someone announces they've hacked the NSA by weighing their computer to find the number of 1s and 0s.
- TedDoesntTalk 4y ago
  … or a new exfiltration technique even for air-gapped devices
  - xen2xen1 4y ago
    Yeah, that does sound like a Defcon talk.
- worksonmine 4y ago
  I know you're being funny, but researchers in a lab got an encryption key by listening on the spinning discs if I remember the paper correctly. Was front-page few years ago.
  - xen2xen1 4y ago
    Yeah, I've read quite a few stories like that, so that was only half a joke. Even the CPU stuff like Spectre and meltdown are almost as crazy.
prewett 4y ago
Technically flash memory storage would weigh more as a 1 (or maybe as a 0, depending), since it works by storing electrons. Apparently it stores something like 500 electrons [1]. My phone has 6 GB of storage, so if they are all ones that gives an extra weight of 2.50e-13 g, which is 0.0001 nanograms. Probably not measurable, though, especially since the large mass of the phone relative to the change in mass eliminates a lot of sensitive measurement techniques. I'm not sure if RAM would have extra weight, as I know less about how it works. [1] https://electronics.stackexchange.com/questions/505361/how-many-excess-electrons-are-in-a-modern-slc-flash-memory-cell https://electronics.stackexchange.com/questions/505361/how-m...

SAI_Peregrinus 4y ago

Audio doesn't use floating-point, it's all fixed-point. So there's no rounding error, only quantization error, and that can be controlled to whatever degree of precision is needed. 1s don't have weight compared to 0s, electrical "high" has mass compared to 0V. Which is "1" and which is "0" (if any) depends on the particular electrical specification of the protocol. E.g. with Ethernet signals are differential, ±3V, with 0V only ever reached momentarily as the + and - switch. There are also lots of cases where the "active" (i.e. "1") is the 0V value, and the "passive" (i.e. 0) is the nonzero voltage. Most reset signals are active-low.

worksonmine 4y ago
Haha, you're all making the same misunderstanding as the post I was replying to. The context of the "bits are not bits" is in relation to memcpy, and his lack of understanding that it's not comparing bits to bits, but the method used to transfer said bits. Which is exactly my point with 0.1 + 0.2. Depending on the methods it will give different outcomes, some more precise than others. Guess it wasn't as obvious as I initially thought. 1s and 0s in the same order are the same, but some data may be lost in the transfer and I don't see why that has to be explained, here of all places. And that's where the Dunning-Kruger reference came from, he thinks it's the bits, when in-fact he would mention the transport had he had more domain knowledge.
- tremon 4y ago
  1s and 0s in the same order are the same, but some data may be lost in the transfer Please explain? If the 1s and 0s are still in the same order, what data has been lost?
  - worksonmine 4y ago
    Please try to read it as I say it I don't know how to be clearer. 0001 == 0001. But 0001 + 0001 does not necessarily end up being 00001. Do you see my point now? You're missing the forest for the trees. 2 things are being discussed, not the outcome. Transport and bits, at the same time, but as separate things. Another analogy in another comment was analog wires, also good, break that and the resistance changes etc etc etc. This many comments for something so simple. Breathe and stop going out of your way to misunderstand me. Ironically exactly how this thread even started. You clearly understand the subject since you already explained floating point arithmetic. I'll give it one last shot: The person being referred to as flat-earth level stupid mentions bits, while he should've mentioned transport. And not taking into account his lack of domain knowledge and using the wrong lingo to misunderstand him and calling him stupid when he is right, just not wording it correctly is the problem.

kabdib 4y ago

> 1s have weight compared to 0s This is a simplistic view how memory and data transmission systems work. Even in days of yore it took a schematic to figure out whether bits were being stored as "lots of electrons means a 1, few electrons means a zero", or the inverse. Modern memory systems and fast serial buses often use whitening to reduce noise and improve clock recovery. A 1 is a 1 when the CPU decides it's a 1, and even then its physical representation is not necessarily static.

worksonmine 4y ago
Doesn't make my claim wrong though. It's an interesting fact just to make a point that sometimes it's not as simple as we assume. Also why I asked him to look it up instead of explaining the how and in what circumstance. I'm sure he's able to find that out, it's not important to the point.
- Tor3 4y ago
  I saw that earlier claim that ones are heavier than zeroes.. could you explain what that even means? And what kind of effect that's supposed to have? I'm genuinely curious about where that comes from.
  - worksonmine 4y ago
    Ones as in has matter. Not the correct wording if we're literal sure, but that's nitpicking. You know what I mean.