Hacker News Reader

drt1245on Booting a 486 from floppy with the most up-to-date stable Linux kernel

Recent versions of Debian require a 686.

https://www.debian.org/releases/stable/i386/ch02s01.en.html#...

Additionally, he keeps talking about dereferencing the pointer, which I don't think is right. The pointer never gets deferenced in the code shown.

I'm not an x86 guru, but I think that "movq ptr(%rip), %rsi" is different because ptr needs to be moved from relative to the instruction pointer (because it is on the stack, as a non-const variable).

drt1245on Receding glacier causes Canadian river to vanish in four days

>Let's assume that when a river gets redirected, a scientist goes and investigates it

This is a faulty assumption and is what leads to the wrong conclusion. The probability of 0.5% is for a randomly selected river. That is, if you went and examined 200 randomly selected rivers, 1 of them (on average) would be redirected due to natural variability.

That does not imply that the remaining 199 were redirected due to global warming. It does not even imply that the remaining 199 were redirected at all!

What is needed is the percentage of rivers that have undergone this redirection. Here's a simplified example: If it's ~0.5%, you conclude it's just natural variation. If it's >0.5%, you conclude that something (possibly global warming) is increasing the number of rivers that are being redirected. If it's <0.5%, you conclude that something is decreasing the number of rivers that are being redirected.

drt1245on Receding glacier causes Canadian river to vanish in four days

I think a better analogy is that it's like having many pairs of dice, and rolling each pair in turn until you get a roll of 12. Then concluding "this particular pair of dice must be loaded".

Presumably, the researchers did not select rivers at random to study, they selected this river in particular because of the changes it is undergoing.

drt1245on China

https://www.google.com/search?q=china+income+inequality

If that was the case, China's growth would be stagnating as well. Not everything is caused by income inequality.

drt1245on Infinity is not a number

Where 1 <= x <= 4:

f(x) = (x-1)/9 + 1, maps bijectively from [1,4] to [1,4/3]

g(x) = (x-1)/9 + 4/3, maps bijectively from [1,4] to [4/3,5/3]

h(x) = (x-1)/9 + 5/3 maps bijectively from [1,4] to [5/3,2]

Therefore, [1,2] must contain three times as many numbers as [1,4], right?

It doesn't work like that.

drt1245on Infinity is not a number

> The argument "Addition breaks" proves just as well that zero "isn't a number", since it breaks division rather badly.

Mathematically, numbers (be it natural, rational, real, or complex) are defined as a field. Fields (or, more accurately, rings, which all fields are) are defined by addition and multiplication, not both. [1]

[1] https://en.wikipedia.org/wiki/Ring_(mathematics)

drt1245on Infinity is not a number

Not only does there exist a bijective mapping between [1,2] and [1,4], there exists infinite different bijective mappings between a subset of [1,2] and [1,4].

i.e.: One could map bijectively from [1,1.5] to [1,4] and map bijectively from [1.5,2] to [1,4] (1)

To talk about there being "twice as much" in one uncountable infinity than in another uncountable infinity is nonsense, since you can't apply words like "twice", since the infinities can't be counted.

(1) https://imgur.com/NkKEI

drt1245on Haskell's effect on my C++ : exploit the type system

The problem is a loss of verbosity. The next person looking at the code isn't necessarily going to know how MAX is defined, and saving 1 line of code isn't worth making it less clear.

That said, for me, your code would be clear, as not being in all caps, I would assume it's a function and therefore doesn't have the same weakness.

As someone else pointed out, there's no way you can look at MAX(0,f()) and know that it's enforced that f() is only used once within the macro.

drt1245on Haskell's effect on my C++ : exploit the type system

  int a = f();
  if (a < 0) a = 0;
   has been replaced with
  const int a = MAX(0,f());

I believe the latter will generally result in 2 calls to f() (unless it returns less than zero), which could cause undesired behavior or just be inefficient. Of course, it depends on what f() does.

Assuming MAX(0,f()) expands to something like this:

  if( f() < 0 )
     a = 0
  else
     a = f()