00:41:15 <esowiki> [[Language list]] M https://esolangs.org/w/index.php?diff=70183&oldid=70166 * PythonshellDebugwindow * (+12) /* D */

03:01:39 <zzo38> Beckett wrote "The costs of DST outweigh the benefits. But if a significant majority of people really want that extra hour of daylight in the summer, just leave the whole country on DST year-round. I prefer standard time, but Ill be happy to compromise if it means not losing an hour every spring."

03:02:17 <zzo38> I agree with Beckett; I also prefer standard time, but permanent DST would still be better than changing it all of the time

03:02:50 <kmc> I haven't formed an opinion on which of the two time zones would be better for permanent use

03:04:05 <kmc> zzo38: did you know that Spain changed to Central European Time during WW2, and never changed back, with the result that in western Spain during the summer the sun doesn't set until after 10 PM?

03:06:00 <zzo38> I think standard time would be better, for use with sundials, so that it is based on noon/midnight (I don't know what is Beckett's reasoning for preferring standard time). However, either way will work as long as there is agreement what time it is, so that if something is scheduled for "five o'clock" then you will know when it is, and so on.

06:10:16 <esowiki> [[Special:Log/merge]] merge * Oerjan * merged [[User:DINAC]] into [[DINAC]] (revisions up to 20200305175450): Fix history after cut and paste move

06:13:49 <esowiki> [[Special:Log/delete]] delete * Oerjan * deleted "[[User:DINAC]]": Remains of cut-and-paste move; history merged into [[DINAC]]

06:15:10 <oerjan> only hitch is that the history says nothing about why the name is now DINAC rather than User:DINAC

06:30:53 <esowiki> [[Special:Log/delete]] delete * Oerjan * deleted "[[User:PythonshellDebugwindow/(Unnamed language)]]": Author request: content before blanking was: "#REDIRECT [[User:DINAC]]"

06:35:04 <zzo38> I am working on adding some more stuff to bystand, including a scoring function. (This might be the only NNTP client which uses both a interactive line-oriented interface and SQLite, and may also be the only one to use SQL as its customization language.)

06:38:48 <zzo38> (Of course, these would not be the features everyone wants, but that is OK, because there are many alternatives.)

06:40:39 <esowiki> [[User talk:Voltage2007]] N https://esolangs.org/w/index.php?oldid=70184 * Voltage2007 * (+98) Created page with "Feel free to add any comments or complaints by editing the page. You ''can'' edit the page, right?"

07:13:34 <esowiki> [[Alchemy]] https://esolangs.org/w/index.php?diff=70185&oldid=36118 * Voltage2007 * (+203)

09:24:03 <HackEso> 1/1:1034) <shachaf> kmc: you gotta tell me if you're an op \ 4) <Warrigal> GKennethR: he should be told that you should always ask someone before killing them.

09:41:49 <cpressey> Welcome to the international center for esoteric programming lingonberry design, development, and deployment

09:48:37 <fungot> int-e: and that information may or may not be covered there? like oop, but after a while

10:34:41 <int-e> The NTM is in the hypothetical play where the opponent tries to find a way to make the deck deal unbounded damage.

10:35:48 <int-e> And the thing is constructed such that damage is all dealt in the end, so for it to happen, the intermediate simulated TMs must all terminate.

10:37:45 <cpressey> This is uncomputable, of course, but that doesn't seem to matter for this hypothetical?

10:40:15 <int-e> But you still have to play the actual busy beaver game to actually deal huge amounts of damage.

10:42:10 <int-e> So basically what's happening here is that they're trying to build an M:tG deck that can deal any conceivable amount of money, for a very wide range of "conceivable".

12:03:24 <cpressey> I might be wrong but I also thought there was a limit of something like 125 water clocks, i.e. a MtG hand corresponds to a The Waterfall Model program with 125 water clocks. In that case, I would say that the maximum damage a MtG hand can do, is literally BBtwm(125), where BBtwm is a version of the busy beaver function adapted to The Waterfall Model.

12:04:02 <cpressey> Literally that number, because that number is literally asking "what's the largest number you can compute with this number of water clocks".

12:07:14 <cpressey> If they want to simulate some other machine with that UTM there's the question of how they get the description of that other machine, into the UTM

12:10:51 <int-e> So in actual play, you need to find a busy beaver. But for hypothetical play you actually get the busy beaver function as an upper bound in the end.

12:12:32 <int-e> Actual play: The player sets up a terminating TM of bounded size by making corresponding choices. It is run; the number of steps (or something like that) that it runs for turn into damage at the end.

12:13:17 <int-e> Hypothetical play: We consider all the possible TMs. But only those that terminate produce any damage. So there's an upper bound, given by the busy beaver function.

12:13:24 <cpressey> A TM implemented with 124 water clocks can compute BBtwm(124) and no larger, even if said TM is a UTM and someone guesses a good TM for that UTM to simulate

12:15:34 <cpressey> You don't need to model "hypothetical play" as an NTM, that's what confuses and bugs me

12:18:33 <cpressey> Is there anything really MtG-specific to this problem? Part of it is that I don't want to guess what rules there are in that game, because I don't play it.

12:19:02 <int-e> As I suggested yesterday, we're doing something like this: NTM A(n): *guess* a TM B of size m. Run B to completion, counting steps. Return number of steps taken.

12:20:14 <cpressey> You don't need to "guess" a TM. Rather just say: let B be the TM of size n which terminates and takes the largest number of steps to do so of any TM of size n.

12:20:49 <int-e> And the variant that computes BB(BB(n)): NTM A'(n): *guess* a TM B of size n. Run B to completion, counting steps. Let m be the number of steps taken. *guess* a TM C of size m. Run C to completion, counting steps. Return number of steps taken.

12:22:21 <int-e> cpressey: guessing is essential to escape the fact that the busiest beavers cannot be found effectively.

12:24:05 <int-e> Nobody's *actually* computing busiest beavers here. The busiest beavers just materialize in a proof that the value we get is bounded.

12:24:50 <int-e> But as long as the play is hypothetical, we can actually have those busiest beavers.

12:25:00 <cpressey> "Our hand of cards represents a TM, so the largest damage we can do is a busy beaver number" pretty much follows from the definition of busy beaver function.

12:26:06 <int-e> If you absolutely want to avoid the NTM angel (personally I find it tremendously helpful), you have to allow input instead.

12:28:13 <int-e> cpressey: And the matter of the fact is that we can have a fixed *N*TM without input of small size that computes the busy beaver function for a much higher number of states.

12:31:38 <int-e> But maybe I should make the idea concrete at least: NTM BB_googol: *guess* a TM A with 10^100 states. Use an UTM to run it to completion, counting steps. Return number of steps taken.

12:32:29 <int-e> And recall that the model of computation here maximizes the output of all the possible runs that terminate.

12:35:36 <int-e> The corresponding TM would instead have to take the description of the TM of size 10^100 as input. By virtue of having input, it's not bounded by the busy beaver function.

12:35:54 <cpressey> Are you trying to say that BB numbers on NTMs can be much larger than BB numbers for DTMs? If so, I don't disagree.

12:42:30 <int-e> cpressey: Can you see what that BB_googol thing does and that the result is BB(10^100) where BB is the standard busy beaver function for DTMs?

12:44:25 <cpressey> Or rather: BB_googol is just a NTM for computing BB(10^100) but why do we need that?

12:45:17 <int-e> Well the point is that the NTM can be written up as a program, and perhaps translated to a deck of cards.

12:46:41 <int-e> The whole point is that BB(10^100) is an upper bound on the possible outputs of terminating runs.

12:49:10 <int-e> And of course, in real play, the player will just use the best TM they can prove termination of, not the busy beaver. (And I should probably allow TMs of size less than 10^100 as well :P)

12:51:29 <int-e> It's the maximum of number of steps taken by any TM of size n (or less, but that's monotonic)

12:54:00 <cpressey> All possible plays of a hand of MtG cards also represents a *set* of Turing machines.

12:55:01 <cpressey> All possible plays of a hand of MtG cards of size n, represents a set of Turing machines of size m (where n and m are, let's assume, linearly related.)

12:55:26 <cpressey> Therefore the maximum damage a hand of MtG cards of size n can do, is proportional to BB(m).

12:57:27 <int-e> You keep missing the fact that a program of bounded size can work on arbtirary sized data.

12:58:16 <cpressey> BB(6) doesn't say *anything* about how much data any TM of size 6 uses or does not use.

12:58:34 <int-e> cpressey: Then stop saying "the" busy beaver function and define what you're actually using. "The" busy beaver function is for programs without input.

13:00:00 <int-e> Which cards to play, how much mana to spend on it, how often to repeat a cycle if they enter one...

13:01:58 <int-e> One of the real challenges they face is to make a TM interpreter that does *not* leave any choices to the players (with some constraints, like refusing to resign; the M:tG rules stipulate that a player may resign at any point during the game).

13:05:25 <cpressey> I guess there's not much point trying to understand this, unless I want to understand the rules of MtG first, and I don't really have any interest in that

13:08:00 <int-e> For me the new insight here was that NTMs can compute (and even iterate computations of) the busy beaver function for DTMs.

13:11:08 <cpressey> If there's an NTM that can compute the BB function then there's also an NTM that can solve the halting problem.

13:11:33 <int-e> (As a two-player game with best play, M:tG might actually be a full ATM. I don't know.)

13:13:27 <int-e> And the usual acceptance condition for NTMs is "there is an accepting run", generalizing what you do for r.e. (accepts the input).

13:15:19 <int-e> One real stumbling block for me is to extend this to a functional model of computation, that actually computes a value from the input.

13:18:03 <cpressey> I have a hard time understanding why someone would think that they could extend "there exists an accepting path" to something that actually finds that path in all cases.

13:18:46 * int-e is beginning to think that cpressey is one of those constructivists he's heard rumors about

13:21:29 <cpressey> I guess my brain pressure is just too high. Occupational hazard of us constructivists, don't ya know.

13:24:29 <cpressey> It would still seem that you're simply saying something like, the maximum damage you can deal in a hand of n MtG cards, is BBN(n), where BBN(x) is the busy beaver number for an *NTM* with x states.

13:27:03 <int-e> It's more bounding BBN(n) from below by (iterated) BB(m) where both iteration and m depend on the concrete n-sized program.

13:28:10 <myname> the amount of damage is obviously bounded by BBN(f(n)) for a function like f(n) = infty

13:33:01 <int-e> cpressey: You're not wrong, there is something resembling BBN(n) for a fixed n here somewhere, namely in the task of finding an M:tG deck that allows dealing a huge amount of damage while having an upper bound on that damage.

13:34:34 <int-e> cpressey: But the point where the discussion started was that they wanted to find an M:tG deck, that is, an NTM, that actually computes BB(m) or BB(BB(m)) for another fixed m instead, so that they had something easier to work with: Busy beavers (for some deterministic model of computation that's easy to implement a universal machine for in TWM).

13:37:53 <int-e> You still need the busy beavers (not necesaarily the best ones) to actually play the game and deal some damage.

13:38:10 <cpressey> I think it is a bad idea to model a hand of cards an as NTM. I think it is better to model (hand of cards + player's strategy) as a DTM.

13:41:16 <int-e> I honestly believe that NTM (and ATM for the full game) is the most natural model for this. I don't want to mess things up by restricting the players to a computable strategy. Not that it matters here... there are only finitely many choices to be made anyway.

13:42:02 <cpressey> Are there really only a finite many choices that a player can make when playing their hand?

13:45:05 <int-e> Yes, you get a tree of computations rather than a line. But that's all. Trees are simple.

13:48:05 <int-e> And "just combinatorics" -- in either case you still get to the point where the model of computation solves the halting problem for you.

13:48:42 <int-e> By simply disregarding non-terminating paths of execution (inputs for which your program doesn't terminate)

13:51:26 <cpressey> It seems to me that you would rather introduce an NTM that represents selecting all possible finite combinations from a finite set, than merely consider all possible finite combinations from a finite set, in your explanation, that's all.

13:53:10 <cpressey> I would call that overkill, not just because it's nondeterministic, but also because it's a TM.

13:53:17 <int-e> (I could argue against the idea that I introduce the NTM... the NTM is already present in the game, to my mind. But meh.)

14:51:31 <cpressey> If you have an NTM that "guesses" an arbitrary DTM description and writes it to a tape, then uses a UTM to simulate that DTM and "produce" its result as an integer, there is no upper bound to the integer the NTM can "produce"; it only needs to "guess" bigger DTMs to get bigger numbers.

14:53:32 <cpressey> On the other hand, if there is a limit to the set of DTMs it can "guess" - if they are drawn from a finite set - then you don't need to talk about "guessing" them and then simulating them at all - you just have an enumeration of DTMs.

15:12:37 <Taneb> Are you two doing the thing where you argue about a fundamentally unimportant detail while agreeing about all the important bits?

15:14:02 <cpressey> I think I disagree about some of the actual conclusions too, but it's hard enough to find out exactly what they are

15:15:15 <esowiki> [[DINAC/STDLIB]] M https://esolangs.org/w/index.php?diff=70186&oldid=70181 * PythonshellDebugwindow * (+223) /* Arithmetic */

15:17:10 <cpressey> The NTM has no limit to the number of states it can "guess" a DTM description to have, then it can simulate it with a UTM

15:18:48 <Taneb> Hmm, wouldn't the definition of the busy beaver function preclude machines that might not halt, and hence preclude any that could be infinite

15:22:59 <cpressey> OK. BB(x) is the largest number of steps any terminating DTM with x states takes before terminating. BBN(x) is the largest number of steps any terminating execution path of an NTM with x states.

15:23:42 <Taneb> Ah, I had taken BBN(x) to be the lagest number of steps of any terminating execution path of an NTM with x states that terminates in all execution paths

15:25:58 <Taneb> Take a non-deterministic turing machine with states (I, H), and transitions I -> {1RI,1RH}

15:29:07 <esowiki> [[DINAC]] M https://esolangs.org/w/index.php?diff=70187&oldid=70182 * PythonshellDebugwindow * (+198) /* Functions */ Clearing up GIVE $

15:29:42 <esowiki> [[DINAC/STDLIB]] M https://esolangs.org/w/index.php?diff=70188&oldid=70186 * PythonshellDebugwindow * (+21) /* Boolean */

15:31:08 <int-e> cpressey: BBN(n) is cleverly defined to exclude not only non-terminating machines but also those that have unbounded results.

15:32:20 <cpressey> "they wanted to find an M:tG deck, that is, an NTM, that [defines] BB(m) or BB(BB(m)) for another fixed m instead, so that they had something easier to work with: Busy beavers (for some deterministic model of computation that's easy to implement a universal machine for in TWM)." My problem with this is in two parts:

15:33:21 <cpressey> 1) If they only have 125 waterclocks at their disposal to make this machine in TWM, then their damage is limited to BB(125) (or something proportional to it)

15:35:53 <cpressey> 2) If they use these 125 waterclocks to make a UTM, and then feed it some kind of TM description as part of how they play their hand, then I need an explanation why they are not allowed to give it an arbitrarily large TM description that produces BB(x) for arbitrarily large x, i.e. it would appear there is no upper bound at all.

15:37:32 <int-e> Which is specifically forbidden by their task description... if the deck produces unbounded damage, it doesn't qualify.

15:38:06 <int-e> Which links back to "BBN(n) is cleverly defined to exclude not only non-terminating machines but also those that have unbounded results."

15:38:15 <cpressey> Why does x need to be encoded in the deck as opposed to the choices that the player takes when they play their cards?

15:39:38 <int-e> The encoding may be indirect, of course. In particular, x may be something like BB(10).

15:41:11 <cpressey> I don't even care about this, it's just frustrating that, every time I say something, hoping to get more clarity, I just get responses that seem to make it more opaque.

15:42:48 <int-e> What frustrates *me* is that you seem to understand everything about this and still are, obviously, confused, and I have no idea what you are confused about.

15:45:05 <cpressey> Unless it's something like: n cards generates BB(n), then BB(n) *plays* of those cards, generates BB(BB(n)). Something like that.

15:45:20 <int-e> BB_BB_googol: Guess a TM A of size 10^100. Run it to its conclusion, counting steps. Let m be the number of steps taken. Guess a TM B of size m. Run it to its conclusion, counting steps. Return the number of steps.

15:46:07 <int-e> You discard all non-terminating runs, and take the maximum length of the terminating ones.

15:46:52 <cpressey> "Guess a TM A of size 10^100" - May I ask to what object in the game of MtG does this A correspond?

15:48:12 <int-e> I really prefer to think of this in terms of (N)TMs, because that's far more familar territory to me.

15:50:46 <int-e> You have given the explanation above: If you /could/ guess a TM of arbitrary size, there would be no maximum result (the results would be unbounded), and we don't want that.

15:52:03 <int-e> The damage is all done in the end, and corresponds to the number computed by the NTM.

15:52:19 <cpressey> The answer seems to be that you can find decks of cards that do arbirarily large finite damage.

15:54:29 <cpressey> OK, so you're modelling this 60-card deck as an NTM with 60 states (roughly speaking).

15:54:56 <cpressey> But there is some reason this 60-state NTM can't guess (and then simulate) arbitrarily large DTMs.

15:57:43 <int-e> cpressey: I doubt that the number of states corresponds to the number of cards in any nice fashion. But I also don't really care about that aspect of the problem.

15:58:28 <int-e> My interest is really this: My initial reaction to the idea that you can iterate the BB function was that this can't be done. No way. Then I homed in on alternation as a possibility, and then I realized that plain non-determinism is enough.

16:04:38 <cpressey> "if there is a line that does more damage we will take it", but "if that amount of damage is unbounded, the deck is disqualified.", so basically this is ruling out any sequence that grows forever.

16:20:59 <cpressey> "Let m be the number of steps taken. Guess a TM B of size m." ... the NTM has to allow guessing a TM as large as m, without knowing how big m is beforehand, but also has to prevent guessing arbitrarily large TMs.

16:22:09 <int-e> So it either fails to terminate (and we're good, the run will be discarded) or produce a fixed result.

16:23:06 <cpressey> I *understand* that A is deterministic; in fact I am assuming that the NTM correctly guessed the DTM which computes BB(10^100).

16:25:16 <int-e> (Where "practice" refers to the scenario where we actually play out one of those runs with concrete choices for A and B)

16:29:51 <cpressey> OK, so there's a deck of 60 cards where there's a possible play that writes a TM A of size 10^100 to the tape and then simulates it to obtain m = BB(10^100) and then writes another TM, this one of size m, to the tape, and then simulates it to obtain BB(m), i.e. BB(BB(10^100)), and then does that much damage.

16:31:32 <int-e> I'm hazy about the actual models of computation (TWM is involved, but it's used to implement a universal machine, and that may be something entirely else still).

16:33:01 <int-e> The important bits to me is that the outer model is non-deterministic (you prefer input, we disagree, let's not reopen that discussion), and that the innner thing that the BB() function is based on is deterministic (so that non-termination of the simulated machine manifests as non-termination of the whole thing).

16:55:29 <cpressey> You *could* do the steps the other way around. You could write a TM B of size BB(10^100) to the tape and simulates it to produce BB(BB(10^100)), then write a TM A that computes BB(10^100) to obtain m, then aborts if TM B consists of more than m states (but it doesn't so you're ok and you output BB(BB(10^100)).)

16:58:44 <cpressey> They're basically getting very, very lucky, if you want to think of it as something that could actually happen.

17:01:51 <cpressey> For obscure reasons, we also want to also disallow NTMs that can produce arbitrarily large numbers.

17:04:14 <cpressey> Details are available in the scrollback, if they can be extracted from the painful misunderstandings.

17:13:05 <int-e> cpressey: It's not all that obscure... it's fairly easy to do unbounded damage in M:tG.

17:13:30 <cpressey> For reasons that will be obscure to anyone who doesn't care much about the MtG angle.

17:13:59 <int-e> (Use any of https://hobbylark.com/card-games/best-infinite-mana-combos-mtg to fuel a Fireball, which does X damage for 1 red and X other mana.)

17:14:44 <int-e> cpressey: But it also makes sense to do that when trying to define the busy beaver function for NTMs ;)

17:17:16 <int-e> cpressey: The reason is not that dissimilar to that 2-state NTM you had earlier... non-determinism means you can expect to turn an infinite loop into an unbounded one very easily.

17:18:05 <int-e> And for some reason the M:tG designers don't consider infinite loops to be a design flaw in the cards... as long as they either don't do anything useful, or are expensive to set up.

17:19:40 <cpressey> tromp: For reasons that int-e will be happy to explain, we want to avoid NTMs that produce arbitrarily large numbers.

17:51:00 <esowiki> [[User:PythonshellDebugwindow]] M https://esolangs.org/w/index.php?diff=70189&oldid=70178 * PythonshellDebugwindow * (-56)

18:05:04 <esowiki> [[User:PythonshellDebugwindow]] M https://esolangs.org/w/index.php?diff=70190&oldid=70189 * PythonshellDebugwindow * (+15)

18:11:21 <esowiki> [[MyScript]] N https://esolangs.org/w/index.php?oldid=70191 * PythonshellDebugwindow * (+131) Created page with "'''MyScript''' is an esolang created by [[User:PythonshellDebugwindow]]. ==Examples== ===[[Hello, World!]]=== say "Hello, World!""

20:58:54 <esowiki> [[DINAC]] M https://esolangs.org/w/index.php?diff=70192&oldid=70187 * PythonshellDebugwindow * (+5)

21:40:21 <zzo38> I think they should add a dot command in the SQLite command-line interface for editing the definition of a view or trigger using an external editor.

22:19:51 -!- LKoen has quit (Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.”).

22:38:52 <zseri> I think it would be interesting to invent a programming language which supports a metatype above "type kinds". ref = https://github.com/YZITE/rfcs/blob/master/proglangs/0004-typelang.md

23:11:22 <arseniiv> posted a thing to ##math to no avail, maybe #esoteric-setminus-##math people will make something of it:

23:11:22 <arseniiv> hey hey you probably know that solutions to ordinary differential equations like P dx + Q dy = 0 are integral curves. The previous night it occurred to me that one could take 2-forms (and higher ones) instead of 1-forms and make an equation like α := P dx∧dy + Q dy∧dz + R dz∧dx = 0 whose solutions would be “integral surfaces” (resp. submanifolds of higher dimension). But I haven’t seen an equation like that anywhere. Do you know why?

23:11:22 <arseniiv> the thing doesn’t seem ill-defined: as with integral curves, every point P of an integral surface should have a tangent bivector A such that α(P, A) = 0. One can also think about nonlinear higher-order equations, again in the same way as for the ordinary “1-form equations”. WDYT?

23:21:02 <zseri> (@arsentiv) I don't really know how to interpret your question, but that might be because I don't really know how to translate your "textification" of integral formulas back into the standard notation. hm. ref = https://en.wikipedia.org/wiki/Surface_integral

23:56:05 <arseniiv> hehe those weren’t integrals, those were differential form fields (equated to zero), but there is a hidden argument to which they are applied to: a vector field, or a bivector field in the second case. So a solution will consist of points with tangent (bi)vectors sticking out of them, and as fields by usual definition are smooth, these points would (in most cases?) make a curve, a surface etc.

23:57:55 <arseniiv> also a person said me that in general there should probably be jets instead of forms