An analog clock does show the exact current moment of time (if the hands move in a linear motion and don't jump).

Then take 10 and divide it by -10 = -1. 10 / -5 = -2. 10 / -0.5 = -20. So from the other side of the y-axis it behaves the exact opposite. It goes to minus infinity. So at x=0 we would have infinity and minus infinity at the same time. Imho that is why it is undefined.

In IEEE 754 math, x/0 for x < 0 is in fact negative infinity.

  >>> np.float64(-1.)/0.
  -inf
  >>> np.float64(1.)/0.
  inf

And you're exactly right, 0/0 is NaN in 754 math exactly because it approaches negative infinity, zero (from 0/x), and positive infinity at the same time.

I always thought the answer to verbal query "let y=1/x, x=0, find y" was "Well, the answer is the Y axis of the plot". Surprising that people have to be reminded that X can be signed. I've had similar conversation IRL.

You seem to have your axes confused. The value of y can’t be “the y-axis”, which is the line x = 0 (for all values of y).

on computers you can have negative zeros

Negative zero is equal to zero, so it's not really a distinct number, just another representation of the same value.

It's equal (as in, comparing them with == is true), but they are not the same value. At least in IEEE 754 floats, which is what most languages with floating point numbers use. E.g., in JS:

  > 1 / 0
  Infinity
  > 1 / -0
  -Infinity
  > 0 === -0
  true
  > Object.is(0, -0)
  false

I think you're misunderstanding me. They are the same value, but a different representation. The equivalence of the value can be shown with math, and has nothing to do with the implementation details of IEEE 754.

Yes.

In a language like C or Rust, you can cast your +0.0 and -0.0 to an integer, and print out the bit pattern. They are different.

-0 is a notation for 1 / -infinity, so it is distinct. For addition it is not.

that's really just an encoding of the number to help you understand how the hell you got here

I was also looking for this. And would like to add: lim(-1/x)_x -> 0 = -inf That is (in my opinion) the whole point why it is actually undefined. On one side of the y-axis it goes to infinity, on the other to minus infinity. I don't see a solution to this and therefore always have accepted that it is undefined.

No. 1/x^2 is undefined at 0 but has the same limit behavior, because limit behavior is not a function from "pairs of (functions from R to R, R)" to R

Infinity is not a real number.

Can limit behavior be defined as Cauchy sequences?

Yes, the units are correct. But currently Germany is generating 33 GW of solar power (according to electricity maps). Therefore the 17GWh is generated after 0.5 hrs. For a whole week this value is way too low, even if it was a cloudy week (which it wasn't).

A thermostat is not an on/off-controller but a proportional controller. The lower the temperature, the higher the flow rate. At least for thermostatic radiator valves this is true.

FWIW everywhere I've lived has an on/off thermostat, maybe it's regional

At least in Europe I've seen plenty of thermostats/boilers that support OpenTherm which allows the thermostat to set the boiler temperature instead of only switching on/off

In northern (and southern) regions the less light you get in winter, the more you get in summer. It is a zero-sum game.

You can't take the power you generate in the summer and use it to heat your house in the winter though.

Zig does have some kind of interfaces, check [1]. I am interested to learn, how Traits in Rust and Interfaces in Go behave differently from this concept.

[1] https://github.com/ratfactor/ziglings/blob/main/exercises/09...

This appears to be done by union-ing the types in question.

The thing about Go interfaces (and C++20 Concepts) is that you can name a type that contains certain methods or behaves a certain way, but you don't actually have to inherit from the interface or concept explicitly - anything shaped correctly that conforms to the interface or concept will work.

And at least with Go, if you try and pass something in that doesn't conform to the interface, it is very particular about telling you what you're missing. One downside of C++ templates is that if you have a problem with what you're passing in, you might get a horrendous error message somewhere deep in the implementation - or worse, your code might compile just fine, but have unexpected behavior - instead of a nice "Hey, you need to add a method named `foo` to this type."

Author should have used this article to propose Go 2.0 changes. For me, I read it like a rant.