x2rj

Also with radians the differential equation x''''(t)=x(t) has {exp(t), exp(-t), sin(t), cos(t)} as the (real) canonical base for its solution space. And x''(t)=-x(t) gets {sin(t), cos(t)} where they even result from the simplest possible (non-trivial) initial conditions (x(0)=0,x'(0)=1 and x(0)=1,x'(0)=0).

If you look at all the simplest differential equations you can think of, the sin(t)/cos(t) functions in radians are almost inevitable independent from their geometric usage.

Sadly linux only (and apparently some BSDs). Would love to have more (and more generalized) tcp socket modes like that.

I've always thought a problem with Nagel's algorithm is, that the socket API does not (really) have a function to flush the buffers and send everything out instantly, so you can use that after messages that require a timely answer.

For stuff where no answer is required, Nagel's algorithm works very well for me, but many TCP channels are mixed use these days. They send messages that expect a fast answer and other that are more asynchronous (from a users point of view, not a programmers).

Wouldn't it be nice if all operating systems, (home-)routers, firewalls and programming languages would have high quality implementations of something like SCTP...

You are confusing UG with something like GbR. UG is basically a baby GmbH with constraints of the name of the company and how much money the associates can extract from it (until the company got 25k€ captial and can become a normal GmbH).

If you write cross platform software, you might want MSVC on Windows and gcc on linux and their assemblers masm and gas have very different syntax. nasm outputs object files for both directly. Also the syntax in the context of especially macros is often a little better.

Is is legally binding since the 80s in Germany. Just mostly nobody bothers to protest a occasional error and it would mostly affect the teenager who delivers the ads anyway.

https://dejure.org/dienste/vernetzung/rechtsprechung?Gericht...

GGA-DFT (+ some corrections) used here seems quite ok to me for this system. For more trust into this, I would like similar calculations with other methods to see how similar or different they are. LDA-DFT will most likely not be great (as in most cases), but I would be very interested in some DFT+GW calculations, even though LK99 might not be it's strength.

Atom is an order of magnitude more complex and strict standard by people who really love xml in contrast to the really simple and less strict rss 2.0. For example almost everything is optional in rss 2.0 so you can have a reasonable feed for stuff like tweets or linkblogs where there is no obvious title. In contrast atom enforces a title for every item which makes this a messy expirience.

I have implemented rss 2.0 parser faster then understanding the atom specification. Atom can do encode stuff like encode html inline the xml instead of as a CDATA string. In theory this sounds great, but is ends up in a big mess of complexity (e.g. a blogpost with handwritten invalid html).

These days there is also JSONFeed which is really easy to parse, simple and flexible, but it is not supported everywhere yet.