I thought it's also mostly to preserve feeling, to obscure the connection between performance and layoff to ease employee transition to another job. That's why sometimes it's a branch all at once from the middle to bottom.
I feel like Turing completeness has always been set as the boundary of programming language if there's any boundary at all. That's what people has been using to not include HTML as programming language for example. Or to include MTG as one.
I think it's a pretty recent thing. Turing completeness is neither a sufficient nor a required property.
HTML is not a programming language, it's a markup language - it's in the name, and it's the way it is used (it's not used to describe any kind of computation, it's straight up data that is parsed by algorithms).
Neither is PowerPoint, or game of life a programming language even though both are Turing complete.
Turing completeness is the upper bound of computability, not the lower bound. It's useful mostly for showing that some thing can express the full range of computable problems, or for snarking that some thing is far more complex than it has any right to be.
Total languages omit partiality and non-termination from Turing completeness.
Partiality is IMO irrelevant when it comes to computability. Any partial function (that is, one whose range is not defined over its whole domain) can be expressed as a total function by either constricting the domain or expanding the range. For example, a "pop" operation on a stack is not defined for an empty stack. You can just loop forever if pop() is called on an empty stack. Alternatively, you can require that pop() is given a witness that the stack is non-empty, or you can require that pop() returns either the top-most element of the stack or a value that indicates the stack was empty. Both let you compute the same set of things as the former.
Non-termination is required to be Turing complete, because being Turing complete means being able to compute functions that one cannot reasonably expect to complete before the heat death of the universe. In _practice_ every function terminates when the computing process dies due to some external factor: process runs out of memory ("real" Turing machines have infinite memory!), user runs out of patience, machine runs out of power, universe runs out of stars, that sort of thing, so _in practice_ doing 2^64 iterations before giving up will generally* give you the same outcome as doing an unbounded number of iterations: it'll either terminate, or the process will be killed (here, due to reaching its iteration limit).
On the flip side, giving up non-termination and partiality only gives you increased correctness. If there's one thing we've definitely established in computing, it's that we will readily discard correctness to gain a little extra productivity. Why make a developer implement code to handle reaching an iteration limit when you can just make the user get sick of waiting and kill your app?
* 18 quintillion is a very large number. Have a try. The most trivial recursive function, on my M4 Mac, when convincing clang to be smart enough to turn it into a loop but dumb enough not to elide it altogether, would take a bit shy of 600 years to complete if iterating ULONG_MAX times; I didn't wait for that, if I'm honest with you, I ran it with a much smaller iteration count and multiplied it out.
I don't know if I read this right, but I thought it's proven that "elementary functions" can't solve 5th degree or higher polynomial, so I'm confused how it's interpreted if elementary functions also include arbitrary polynomial roots. Or is it different elementary functions?
That theorem is not formulated about "elementary functions".
It says that polynomial equations of the 5th degrees or higher cannot, in general, be solved using "radicals".
While something like "polynomials" or "radicals" has a clear meaning, which are the "elementary functions" is a matter of convention.
The usual convention is to include all algebraic functions and a few selected transcendental functions.
In "all algebraic functions", are included the rational functions, the radicals and the functions that compute solutions of arbitrary polynomial equations.
Some conventions used for "elementary functions" describe the expressions that you can use to write such "elementary functions", in which case not all algebraic functions are included, but only those written by combining rational functions with radicals.
For an algebraic function that computes a solution of a general polynomial equation, which cannot be expressed with radicals, you cannot write an explicit formula, but you can write the function only implicitly, by writing the corresponding polynomial equation.
So the difference between the 2 kinds of conventions about which are "the elementary functions" is usually based on whether only explicitly-written functions are considered, or also implicit functions.
So the argument of the post is basically “this definition of elementary functions includes functions without closed form expression, and thus we cannot express these elementary functions with eml”, or sth more (that there exist elementary functions with closed form expressions that cannot be expressed by eml)?
FWIW I never thought that functions without closed form expressions were considered elementary functions, but i guess one could choose to allow this if they wanted
The term 'elementary function' doesn't really have a single universally agreed on strict definition.
Definitions are either a bit fuzzy, or not universally agreed on.
Though interestingly https://en.wikipedia.org/wiki/Elementary_function says "More generally, in modern mathematics, elementary functions comprise the set of [...]". Though at least Wikipedia thinks that 'modern mathematics' has a consensus; of course, there's no guarantee that whoever you are talking to uses the 'modern mathematics' definition that Wikipedia brings up.
Yeah, I've a friend that'll react the same way. This reminds me of a question, why are a lot of early stories a fable? It's because it's the easiest way to discuss an abstract thing, to become something still concrete enough to imagine, but detached enough from reality to not create unnecessary problems.
I think it's mainly in relation to the constraints of the game engine, and also that the game engine being flexible enough to enable the gimmicks. I haven't played DDLC and probably never will, but from what I've read about it, like games with similar core themes (not dating sim) it has some gimmicks that tend to stretch the capabilities of a closed-down game engine, sometimes requiring patches to the engine itself. In this case the game engine Renpy offers an extensive DSL that makes it easy to add story scenes, media and dialogues, but allows you to fall back to python to do some tricky things.
It breaks the fourth wall in unexpected, and deeply unsettling ways.
As a gamer you take for granted that, at any moment, you can simply exit. The UI is a trustworthy boundary between the imagined world of a horror game, and the comfort of reality. In DDLC, you don't even feel safe on the title screen.
Most ren'py games, even the very good ones, barely change the UI at all. Roadwarden doesn't look like a ren'py game at all... until you open the save menu, and then it looks exactly like a ren'py game. Having developed ren'py games, I can tell you why people avoid touching that part of the boilerplate code: it's the one part of ren'py where the abstractions aren't well thought out. It's very fragile. To me, that makes DDLC all the more impressive from a technical point of view. It warps and abuses the most rigid and uncooperative part of the engine, and to great narrative effect.
Ive heard someone saying that, Microsoft or Oracle already has hundreds of those 10x engineers for decades now, and what they produce is... current Microsoft and Oracle.
I tried it when it has the most extensive free offering, and it definitely answers my worldbuilding questions in more detail than I expected and compared to Gemini or Chatgpt. Can't say anything about hallucinations tho.
reply