←2023-10-25 2023-10-26 2023-10-27→ ↑2023 ↑all
01:02:31 -!- Lord_of_Life has quit (Ping timeout: 258 seconds).
01:02:37 -!- Lord_of_Life_ has joined.
01:03:58 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
01:30:35 -!- Noisytoot has quit (Quit: ZNC 1.8.2 - https://znc.in).
01:30:59 -!- Noisytoot has joined.
01:53:31 -!- razetime has joined.
02:28:43 -!- ais523 has joined.
02:29:13 <ais523> <fellow> and is TC always a desirable quality? ← the most interesting esolangs are normally those for which either a) it isn't obvious whether they're TC or not, or b) they fail to be TC in an interesting or unusual way
02:29:32 <ais523> or, that are TC despite being extremely simple
02:30:18 <ais523> <int-e> We all know that in practice we'll often run out of memory or time before a computation ever finishes. ← although in practice it is often possible to write an optimising interpreter that can implement the very slow programs in reasonable time
02:31:49 <ais523> <FortyTwoBB> After much headache, I think I understand the FWC TC-ness. I still feel a real dissonance with my intuition, but I've dealt with that before. Really, thank you for the work ais523. I've started again on the writeup and will post it in here when its done. ← I'm looking forward to it; I've been looking at the M:tG BB construction myself and have been making progress on understanding it, although I still don't have a a grasp of how the whole
02:31:51 <ais523> thing hangs together
02:32:52 <ais523> <fellow> must esolang always execute something? can esolang simply be a markup language? ← esoteric non-programming languages are less popular than esoteric programming languages, but do get discussed on IRC sometimes – I'm not sure if people put them on the wiki
02:42:53 -!- ais523 has quit (Remote host closed the connection).
02:44:06 -!- ais523 has joined.
03:19:25 <int-e> ais523: I really had problems in mind that exceed our computing facilities... solving chess would be a very likely example.
03:34:53 <ais523> int-e: ah right, but that sort of computation isn't any better in practical languages than in esolangs
03:35:21 <int-e> Yes. It wasn't about esolangs at all.
03:37:14 -!- wpa has joined.
04:29:15 -!- ais523 has quit (Remote host closed the connection).
04:30:04 -!- razetime has quit (Ping timeout: 248 seconds).
04:30:31 -!- ais523 has joined.
04:38:43 -!- razetime has joined.
05:17:27 -!- razetime has quit (Ping timeout: 240 seconds).
05:20:12 -!- razetime has joined.
06:44:41 -!- tromp has joined.
06:59:56 -!- razetime has quit (Ping timeout: 255 seconds).
07:30:44 -!- razetime has joined.
07:57:45 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
08:04:35 -!- tromp has joined.
08:27:29 <esolangs> [[Special:Log/newusers]] create * Kant2002 * New user account
08:31:24 -!- razetime has quit (Ping timeout: 240 seconds).
08:32:18 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=118410&oldid=118372 * Kant2002 * (+128)
08:41:18 <esolangs> [[GAXT]] https://esolangs.org/w/index.php?diff=118411&oldid=106770 * Kant2002 * (+0)
08:56:34 -!- Sgeo has quit (Read error: Connection reset by peer).
09:02:28 -!- razetime has joined.
09:33:56 -!- Thelie has joined.
09:58:37 <esolangs> [[Idea]] M https://esolangs.org/w/index.php?diff=118412&oldid=102917 * PkmnQ * (-4) a is just a literal, I think?
10:31:41 -!- razetime has quit (Remote host closed the connection).
10:32:50 -!- razetime has joined.
10:37:58 -!- arseniiv has joined.
10:44:39 -!- razetime has quit (Quit: Go back to your cringe 9 to 5. I'll be gaming.).
11:05:20 -!- __monty__ has joined.
12:22:15 <esolangs> [[GAXT]] M https://esolangs.org/w/index.php?diff=118413&oldid=118411 * PythonshellDebugwindow * (+63) /* Grammar */ Categories
12:23:26 <esolangs> [[Homespring]] M https://esolangs.org/w/index.php?diff=118414&oldid=55494 * PythonshellDebugwindow * (+9) Stub
12:53:43 -!- Thelie has quit (Ping timeout: 264 seconds).
12:58:07 -!- Everything has quit (Quit: leaving).
13:08:39 -!- Everything has joined.
13:40:51 -!- Thelie has joined.
14:11:51 -!- Thelie1 has joined.
14:11:58 -!- Thelie has quit (Quit: Leaving.).
14:13:06 -!- tromp has quit (Read error: Connection reset by peer).
14:16:36 -!- tromp has joined.
14:38:24 -!- Sgeo has joined.
14:50:39 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
15:04:59 <esolangs> [[Vertica Smile]] M https://esolangs.org/w/index.php?diff=118415&oldid=25366 * PythonshellDebugwindow * (+24) Category
15:14:16 -!- tromp has joined.
16:58:10 <esolangs> [[User:PaxtonPenguin/Sandbox]] N https://esolangs.org/w/index.php?oldid=118416 * PaxtonPenguin * (+102) Created page with "Welcome to Hell This is where i put my stupid ideas Enjoy. ;) =1= ==2== ===3=== ====4==== =====5====="
17:01:26 <esolangs> [[User:PaxtonPenguin/Sandbox]] https://esolangs.org/w/index.php?diff=118417&oldid=118416 * PaxtonPenguin * (+59)
17:03:03 <esolangs> [[User:PaxtonPenguin]] https://esolangs.org/w/index.php?diff=118418&oldid=118388 * PaxtonPenguin * (+44)
17:20:50 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
17:34:28 -!- zzo38 has quit (Ping timeout: 260 seconds).
17:39:38 -!- sprout_ has joined.
17:42:36 -!- sprout has quit (Ping timeout: 248 seconds).
17:48:18 -!- tromp has joined.
17:50:58 -!- sprout_ has changed nick to sprout.
17:54:22 <esolangs> [[Snek]] https://esolangs.org/w/index.php?diff=118419&oldid=108910 * KingJellyfish * (+11)
18:01:59 -!- Cale has quit (Read error: Connection reset by peer).
18:18:16 -!- zzo38 has joined.
18:37:48 -!- kwii has joined.
18:45:35 -!- FortyTwoBB has joined.
18:47:17 -!- FreeFull has joined.
18:51:39 <FortyTwoBB> ais523 yeah I understand being confused by the rest of the structure. Probably the most mechanically difficult bits are the transitions before/after worldfire and spite. I'm trying to be overly detailed with those explanations to make sure it all works. Conceptually hardest is definitely understanding how higher tier stages even work (well that and
18:51:39 <FortyTwoBB> FWC TC, but you obviously know that already lol)
18:54:56 <FortyTwoBB> Also, our particular construction has computation in an awkward spot that makes the structure even more confusing when you consider where we actually benefit from the output.
18:56:58 <FortyTwoBB> output=BB zombies -> starlight life -> lingering souls casts -> TYS storm count is finally something preserved through worldfires.
19:02:39 -!- Noisytoot has quit (Remote host closed the connection).
19:03:09 <FortyTwoBB> but if you have specific questions I'm happy to provide whatever answers I can
19:03:34 -!- Noisytoot has joined.
19:04:45 <kwii> what's the context of this topic/what is this esolang?
19:06:12 <FortyTwoBB> this is the most damage without going infinite in magic the gathering. the strategy involves implementing https://esolangs.org/wiki/Flooding_Waterfall_Model which was recently proven to be TC
19:07:12 <FortyTwoBB> thus the computation produces busy beaver numbers as output
19:08:08 <FortyTwoBB> The rest of the deck focuses on iterating the computation as many times as possible to get 'higher order' busy beaver numbers
19:09:17 <ais523> FortyTwoBB: it took me a while to work out what the lowest-level output was that's the multiplier for the highest stages
19:09:29 <ais523> but I realised it had to be storm, because it's a resource that can't be spent, only used
19:09:38 <FortyTwoBB> BB_0(X)=BB(X) BB_n+1(X)=BB^N(X)
19:09:58 <FortyTwoBB> err no
19:10:40 <FortyTwoBB> BB_n+1(X)=BB_N^(BB_N(X))(X)
19:11:54 <ais523> does this mean that you don't have busy beaver factors in the lowest stages?
19:12:58 <FortyTwoBB> well storm turns into everything else via fated infatuation
19:13:23 <ais523> one thing I realised is that if you're using an iterated busy beaver function, the first few iterations don't need to be large enough to be TC, just to create a number larger than themselves
19:13:55 <ais523> and then the TCness can start showing up after a few iterations
19:14:15 <FortyTwoBB> yeah, numbers being too small for the first computation is not really an issue anymore
19:15:13 -!- arseniiv_ has joined.
19:15:47 <ais523> what resource is spent to cast Fated Infatuation?
19:15:48 <FortyTwoBB> Older versions had to prove they could break out with like 70 permanents, this version will have more like 70^^^70 permanents at least
19:16:06 <FortyTwoBB> life to pay lingering souls flashback
19:16:17 <FortyTwoBB> triggers spellweaver volute
19:16:30 -!- kwii has quit (Quit: Quit).
19:16:35 <ais523> oh right, there was some discussion in-thread about rulings on Spellweaver Helix
19:16:55 <ais523> you have a choice about whether or not to copy the spell, and if you do, you have a choice about whether or not to cast the copy (you can just let the copy fizzle without casting it)
19:17:13 <ais523> so if the Spellweaver Helix trigger gets copied, you can cast the spell from some copies and not others
19:17:22 <FortyTwoBB> yeah apparently even if the copy is not something that can normally fizzle like worldfire
19:17:48 <ais523> right, even if you can't fizzle due to lack of targets you can just not put it on the stack in the first place
19:18:02 <FortyTwoBB> which is not how I expected the card to work, but its certainly convenient
19:18:06 <ais523> it's weird for the card to give you two choices
19:18:23 <ais523> `card-by-name Spellweaver Helix
19:18:25 <HackEso> Spellweaver Helix \ 3 \ Artifact \ Imprint -- When Spellweaver Helix enters the battlefield, you may exile two target sorcery cards from a single graveyard. \ Whenever a player casts a card, if it has the same name as one of the cards exiled with Spellweaver Helix, you may copy the other. If you do, you may cast the copy without paying its mana cost. \ MRD-R
19:18:29 -!- arseniiv has quit (Ping timeout: 255 seconds).
19:18:31 <ais523> 3/1/2005 The creation of the copy and then the casting of the copy are both optional.
19:19:46 <ais523> wording weird enough that they had to write a ruling to say that the card actually does what it says it does
19:20:52 <FortyTwoBB> also if it has 3 or more cards imprinted on it you cast them from the same trigger.
19:21:36 <FortyTwoBB> so we imprint worldfire, starlight, and the only sorcery we have two copies of
19:21:40 <ais523> I am a little more concerned about that one because IIRC the rules for copying imprint triggers changed recently-ish, so there are some formerly correct rulings floating around online that are no longer correct
19:21:49 <ais523> but maybe I'm thinking about something else
19:22:07 <FortyTwoBB> we double checked that when it changed
19:23:05 <FortyTwoBB> the main difference was with split/double faced cards but it doesn't effect us
19:23:30 <ais523> I'd expect it to work because imprint doesn't have rules text any more, so it doesn't notionally function any differently from, say, Dauthi Voidwalker
19:25:08 <ais523> 607.3. If, within a pair of linked abilities, one ability refers to a single object as “the exiled card,” “a card exiled with [this card],” or a similar phrase, and the other ability has exiled multiple cards (usually because it was copied), the ability refers to each of the exiled cards. If that ability asks for any information about the exiled card, such as a characteristic or mana value, it gets multiple answers. If these answers are used to
19:25:08 <FortyTwoBB> yeah its just cards linked to an ability, there are a few odd corner cases where you can get multiple different linked abilities that don't interact
19:25:09 <ais523> determine the value of a variable, the sum of the answers is used. If that ability performs any actions on “the” card, it performs that action on each exiled card. If that ability creates a token that is a copy of “the” card, then for each exiled card, it creates a token that is a copy of that card. If that ability performs any actions on “a” card, the controller of the ability chooses which card is affected.
19:25:16 <ais523> (from the rules dated October 13 2013)
19:25:22 <ais523> a very clear answer
19:26:06 <ais523> …although I'd hate having to rule that in languages other than English, which don't make a distinction between "a" and "the"
19:26:18 <ais523> (the official ruling is presumably "look at the English card text")
19:29:06 <FortyTwoBB> Constricting sliver can be artificial evolution-d to grant another linked exile ability to say dauthi voidwalker. you can't use the voidwalker's natural ability to cast the card it exiled due to the sliver's ability
19:29:24 <FortyTwoBB> `card-by-name Constricting sliver
19:29:25 <HackEso> Constricting Sliver \ 5W \ Creature -- Sliver \ 3/3 \ Sliver creatures you control have "When this creature enters the battlefield, you may exile target creature an opponent controls until this creature leaves the battlefield." \ M15-U
19:30:10 <ais523> dauthi voidwalker is a bad example, it uses counters to know which cards it can cast
19:30:52 <FortyTwoBB> oh, right
19:31:00 <FortyTwoBB> but even if it didnt
19:33:33 <FortyTwoBB> intellect devourer then
19:33:43 -!- arseniiv_ has quit (Quit: gone too far).
19:35:45 <FortyTwoBB> Jacob Hauken, inspector even has two ways for it to exile cards for it to cast, but couldnt cast something it exiled thanks to the sliver
19:37:05 <ais523> I guess my key question at the moment is: say the volute hyperstage is locked (it has created a whole load of martyr triggers that are currently in use, and can't be reused without destroying them)
19:37:16 <ais523> * martyr tokens
19:37:29 <ais523> is it possible to run a computation for each martyr token? or do we have to unlock the volute first?
19:43:36 <FortyTwoBB> have to unlock
19:44:06 <ais523> this makes me wonder if the foundry stage is worth it at all, then
19:44:30 <ais523> because it's basically increasing things by an Ackermann function factor, but the busy beaver function grows so fast as to make that factor irrelevant
19:45:02 <FortyTwoBB> yes, but thats only the 'topmost' foundry stage
19:45:27 <FortyTwoBB> lower foundry stages power the transitions for more computations
19:45:59 <ais523> couldn't you do that with a layer instead, and save a lot of card slots?
19:46:53 <FortyTwoBB> No, a stage powers many more transitions than a layer would
19:47:28 <ais523> but the number of transitions you get is already a busy beaver number
19:47:43 <ais523> applying any computable function to that doesn't significantly change its size
19:48:08 <ais523> because you could just implement the same computable function inside the Flooding Waterfall Model program instead, using a very slightly larger starting state
19:51:42 <FortyTwoBB> basically because the higher order stage structure is recursive, we can lose some efficiency at the top for more efficiency on the overall structure
19:53:50 <FortyTwoBB> you can think of the martyr/soul foundry stage just below the topmost volute stage as powering a computation per martyr
19:54:29 <ais523> I think that, if you replaced the foundry stage with a layer, and used the card slots saved by that to give you even one more starting token for the first computation, it would produce a larger output – but I don't fully understand the construction so may well be wrong
19:55:46 <ais523> because while the volute stage is locked, you don't run computations, so you're creating some function of the amount of life you have – this is a fast-growing function but it's still computable, and thus an irrelevant part of the overall construction
19:56:15 <ais523> and what's actually needed is to save as many card slots as possible for it, rather than making it grow as fast as possible
19:56:41 <ais523> err, not of the amount of life, of the amount of martyr tokens
19:57:32 <ais523> because you could just get the Flooding Waterfall Model program to compute the same function before outputting, with a constant-sized amount of overhead
20:01:22 <FortyTwoBB> but a layer at the top of a stage doesn't do anything. just go into the stage with 2 more life or one more
20:01:23 <FortyTwoBB> R
20:02:21 <ais523> exactly – my point is that even that does more than putting a stage below the computation
20:03:32 <FortyTwoBB> but its also still a stage for rebuilding the rest of the stack, the real work it does is in providing transitions
20:05:16 <ais523> I feel like a stage is necessarily either too large or not large enough for that
20:05:33 <ais523> it isn't large enough to handle BB levels of output, but a layer would be large enough to handle anything smaller
20:06:03 <FortyTwoBB> consider after we have run out of life for computations above the first worldfire, we run through the awaiting transition triggers to get back into a state to cast worldfire again
20:07:03 <FortyTwoBB> when we cast worldfire, the stack is the same as it was but we are down some fraction of the martyr stage below those transitions
20:10:42 <ais523> OK, so you're casting worldfire at instant speed with a whole load of martyr triggers on the stack below it, and the number of martyr triggers determines how many times you can cast worldfire at that particular stack state
20:10:52 <FortyTwoBB> yes
20:11:24 <FortyTwoBB> the topmost martyr stages are worthless yes
20:11:41 <FortyTwoBB> but in the middle of the stack they get rebuild with updated BB heights
20:11:47 <FortyTwoBB> which a layer could not no
20:11:55 <FortyTwoBB> not do
20:12:55 <FortyTwoBB> most of the time we will be at the top of the stack and BB computations dominate.
20:13:14 <FortyTwoBB> we want to iterate those as much as possible
20:13:26 <ais523> but in any given batch of consecutive martyr triggers, there's no way to increase the size of the batch based on a computation once the batch has already been created
20:13:40 <ais523> and the initial size of the batch is based on a BB output
20:14:31 <ais523> or, hmm, maybe not? this is really confusing
20:14:49 <FortyTwoBB> but the number of BB iterations we get is the important thing
20:15:43 <ais523> what I am wondering about is whether we can just make the batches of triggers larger, rather than using them more efficiently
20:16:20 <FortyTwoBB> they get larger as the combo goes
20:16:31 <ais523> yes, of course
20:17:30 <FortyTwoBB> so when we reach the bottom of the stack, we remake the stack with more layers and stages
20:18:41 <FortyTwoBB> because BB_N(X+1)<BB_N+1(X)
20:19:51 <ais523> so I think the point where the problem is (if there is a problem) is that in the foundry stage, in between creating and using the transition, no computations run, you are just taking tokens and very efficiently converting them to storm
20:20:55 <ais523> err, not tokens, triggers
20:21:07 <FortyTwoBB> only at the very top of the stack, we can leave all of those triggers on the stack and do computations above them,
20:21:32 <ais523> not while the foundry stage is locked
20:21:35 <FortyTwoBB> storm does get converted into computations as well
20:22:10 <ais523> like, the whole batch of ashnod-triggers has to be converted into storm all at once
20:22:20 <ais523> you can't do computations in the middle of converting the batch
20:22:47 <ais523> but that particular conversion might actually already be as simple as possible
20:22:50 <ais523> in terms of card slots
20:23:13 <ais523> so maybe there isn't an inefficiency
20:25:06 <ais523> brb
20:25:08 <FortyTwoBB> we can leave ashnod triggers on the stack and retarget the martys when the ashnods resolve
20:35:08 <b_jonas> oh, you *iterate* the busy beaver function. so that's why you need to capture the output of the busy beaver in a usable form! that's what I didn't understand the last time
20:37:49 <ais523> FortyTwoBB: back
20:37:51 <ais523> I think I was wrong
20:38:04 <ais523> and I think the reason is that I didn't understand the difference between a hyperstage and two stages
20:38:43 <FortyTwoBB> yeah converting the output into the next bb computation input is easy
20:40:21 <FortyTwoBB> technically we might only be able to make BB(BB(X)-1) when we iterate but that -1 is pretty irrelevant
20:41:13 <ais523> b_jonas: it's not just iterating it, it's an Ackermann-like function that has a busy beaver in rather than a multiplication
20:41:14 <FortyTwoBB> yeah higher order stages are kind of crazy
20:41:23 <ais523> and that's just a single stage
20:41:38 <ais523> the higher order stages are somewhat hard to comprehend, as this conversation indicates
20:42:46 -!- Noisytoot has quit (Ping timeout: 260 seconds).
20:42:58 <esolangs> [[Cyclic Amplification System]] M https://esolangs.org/w/index.php?diff=118420&oldid=68232 * PythonshellDebugwindow * (+17) /* Another example for a computation that does many executions finitely */ Rectwrap
20:47:18 <b_jonas> “<ais523> (the official ruling is presumably ‘look at the English card text’)” => it always is, because the other language texts are not generally updated when the oracle text is changed, unless the card is reprinted. also because the comp. rules doesn't have translations, and I don't think there's even an easy way to find the english word from a magic-specific word (eg. keyword or type or
20:47:24 <b_jonas> subtype) in a foreign language, there are no translation tables published. as far as the rules go, nothing but the current oracle text matters, and that exists only in English.
20:47:50 <ais523> also the translations often have major errors in
20:48:10 <ais523> I think as recently as this year, there was a translated card printed with the wrong mana cost for an ability
20:48:14 -!- Noisytoot has joined.
20:49:28 <FortyTwoBB> Yeah they have gotten better, but mistackes still happen
20:50:04 <FortyTwoBB> hasnt been another 'card-by-name walking atlas in english for a while
20:50:19 <FortyTwoBB> 'card-by-name walking atlas
20:50:40 <int-e> `card-by-name walking atlas
20:50:41 <HackEso> Walking Atlas \ 2 \ Artifact Creature -- Construct \ 1/1 \ {T}: You may put a land card from your hand onto the battlefield. \ WWK-C
20:50:57 <int-e> (backtick, not quote)
20:51:33 <FortyTwoBB> yeah thats the oracle text, the printed card is not an artifact
20:51:56 <FortyTwoBB> they just left that word off
20:54:09 <b_jonas> “<ais523> … in languages other than English, which don't make a distinction between ‘a’ and ‘the’” => since last year they stopped printing new sets in korean, russian, and chinese traditional, so there's at most two of those standing, but there are of course lots of other reasons why it can be hard to figure out the rules from the translated text
20:54:57 <FortyTwoBB> But oracle text is almost always good enough to define how the card works within the rules
20:55:02 <b_jonas> I expect "an exiled card" would be used only on cards that normally exile multiple, and on those the translated text is likely clear that the second ability affects only one of them
20:56:51 <FortyTwoBB> `card-by-name dominating licid
20:56:53 <HackEso> Dominating Licid \ 1UU \ Creature -- Licid \ 1/1 \ {1}{U}{U}, {T}: Dominating Licid loses this ability and becomes an Aura enchantment with enchant creature. Attach it to target creature. You may pay {U} to end this effect. \ You control enchanted creature. \ EX-R
20:57:08 <FortyTwoBB> does not work because of layers
20:57:22 <ais523> does nowadays, they finally errata'd it and/or changed the rules so that it would work
20:57:31 <ais523> after a small but vocal minority complained for years
20:57:41 <APic>
20:57:42 <FortyTwoBB> oh? what changed?
20:58:03 <ais523> I can't remember
20:58:59 <ais523> oh, I think the bot may have brought up the post-errata version
20:59:21 <ais523> "You control enchanted creature" is now part of its text even as a creature, so there isn't a layers issue with whether that ability exists or not
20:59:54 <FortyTwoBB> Ah thats a clever change
21:02:52 <esolangs> [[Trigational Pseudoomninumitype]] M https://esolangs.org/w/index.php?diff=118421&oldid=108921 * PythonshellDebugwindow * (+24) Category
21:02:52 <b_jonas> yeah, it's mostly just the oracle text that matters, except (1) you have to find the version of the oracle text as it was at the start of a tournament if it's been updated during the tournament, and (2) between a set releases and the comp. rules is updated you have to use the set FAQ / release notes to determine how any new functionality like new keywords work.
21:02:53 -!- Thelie1 has quit (Ping timeout: 255 seconds).
21:03:03 <esolangs> [[Trigational Pseudoomninumitype]] M https://esolangs.org/w/index.php?diff=118422&oldid=118421 * PythonshellDebugwindow * (+0) /* Examples */
21:05:21 <b_jonas> the numbers go higher than I can imagine then, if your construction really works
21:05:58 <ais523> even one iteration of the busy beaver function goes higher than anyone can imagine, if it's starting from a sufficiently large number (which could be quite small)
21:06:08 -!- __monty__ has quit (Quit: leaving).
21:07:27 <FortyTwoBB> so roughly the stack structure is some layers at the bottom, then three stages, then worldfire transitions for each red, each worldfire has a spite transition for each 2 life, then each of those has a martyr stage in between.
21:07:35 <b_jonas> yes, because the BB of a sufficiently large number will very likely be not determined by ZFC, and even in an esoteric model like this, a few exponentials of code size should be more than enough to reach that stage
21:07:40 <FortyTwoBB> and at the top of the stack is computation
21:08:41 <ais523> unless I made a mistake calculating the complexity class, we're definitely within three exponentials of a Turing machine and probably within two
21:08:42 <FortyTwoBB> isn't the bound down to like bb(700) to break out of ZFC?
21:09:00 <ais523> last time I looked it was a four-digit number, but I haven't been paying that much attention
21:09:51 <b_jonas> FortyTwo: not here, because we're using flooding waterfall, and with the matrix entries encoded in unary (eg. you need as many token copies as the sum of matrix entries), that's much less efficient than turing machines or anything like that
21:10:23 <FortyTwoBB> yeah so we need like BB(700^^^700)
21:10:51 <b_jonas> but I'm hoping that you can generate a large enough number with the parts of the deck outside of the waterfall thing to take off, and that there are enough creature types available
21:11:06 <ais523> b_jonas: fwiw it wouldn't surprise me if one exponential were possible, via using a fixed-size interpreter that decodes the program to interpret from a constant
21:11:40 <esolangs> [[Yoob]] M https://esolangs.org/w/index.php?diff=118423&oldid=42296 * PythonshellDebugwindow * (-6) /* External resources */ Update link
21:11:41 <ais523> there are definitely enough creature types available, the original waterfall model can be done in 7 counters, flooding waterfall model can be done in less than 100
21:12:05 <ais523> and the waterfall thing can take off with hardly any tokens because you don't need to be TC on the first iteration, just generate an output larger than the input
21:12:45 <ais523> and flooding waterfall model can do an exponentiation on incredibly limited resources, as long as you want to output the result rather than doing further computations with it
21:14:17 <b_jonas> you need just one creature type per clock, plus a constant overhead, right?
21:14:44 <ais523> for flooding waterfall model, it's one creature type per flooding waterclock
21:14:55 <b_jonas> good
21:14:59 <FortyTwoBB> yeah, so we can have 250+ clocks
21:15:19 <b_jonas> there are about 280 creature types in Magic these days
21:15:46 <b_jonas> (of course the reality is probably even bigger than what we can prove)
21:16:23 <FortyTwoBB> Its still on the order of BB(X)
21:17:10 <fellow> what is the best way to prove that a language is Turing Complete?
21:17:15 -!- FreeFull has quit.
21:17:21 <b_jonas> sorry, I mean the reality for how small code size you need to start to take off is likely lower than what we can prove is enough
21:18:01 <ais523> fellow: there's a range of languages designed for proving things TC; you have to either write a compiler from one of those into your language, or to write an interpreter for one of those in your language
21:18:07 <b_jonas> fellow: compile an existing simple computational model to it, such as two-stack machines, two-counter Minsky machines
21:18:23 <ais523> one of my big esolang projects has been trying to work out the best languages to use as the source
21:18:29 <fellow> ais523: but then how are those languages proven to be Turing Complete?
21:18:48 <ais523> fellow: normally with a chain of progressively simpler languages implementing each other
21:18:49 <APic> When You really want to prove something, You will find Ways.
21:19:02 <b_jonas> fellow: the same way, just with a few simulation layers until you get to whatever language you take as the definition of Turing-complete
21:19:14 <ais523> but, most of the chain has been proven already, so you only need to do the bit at the end of the chain
21:19:50 <b_jonas> what is relevant here in Minsky machines, which you prove Turing-complete by simulating a finite control multi-stack machine on one
21:19:54 <fellow> b_jonas: sounds circular to me. if Turing completeness is always defined in terms of another language, how can we ever be sure which language is turing complete. somewhere we need to break the cycle, no?
21:20:05 <ais523> for what it's worth, I currently believe that the easiest languages to compile from are either simple queue-based tarpits or simple counter-based tarpits, and which is simpler depends on the nature of data storage in your target language
21:20:12 <fellow> thanks. minsky machine. need to learn about it.
21:20:18 <ais523> fellow: it's rooted at Turing machines, which are Turing-complete by definition
21:20:22 <FortyTwoBB> it eventually comes back down to a turing maching
21:20:33 <b_jonas> fellow: no, you define Turing-completeness in terms of one specific language, and then you take a chain of simulations to that one language
21:21:00 <ais523> you could pick any other TC language as the example that defines the whole set, but Turing machines were picked early and the choice stuck (I guess it doesn't really matter)
21:21:55 <fellow> so Brainfuck without the two I/O commands is still turing complete if given infinite memory cells?
21:22:02 <b_jonas> different people can have different preferences of the definition, it doesn't matter as long as we can prove them equivalent using simulations
21:22:21 <b_jonas> fellow: yes, Brainfuck without IO on an infinite tape is Turing-complete
21:22:29 <ais523> fellow: for what it's worth, my current "simplest picks" for counter-based languages are https://esolangs.org/wiki/The_Waterfall_Model and https://esolangs.org/wiki/Brainpocalypse_II, and for queue-based languages are the various simplified tag machines, https://esolangs.org/wiki/Cyclic_tag_system or https://esolangs.org/wiki/Tag_system are probably the most commonly used there
21:22:50 <ais523> fellow: I/O isn't needed for Turing-completeness, the definition doesn't consider IO at all
21:22:55 <FortyTwoBB> the Church-Turing thesis showed the computational class all being equivalently powerful for computation/work/simulation/etc
21:23:02 <ais523> so we sometimes talk about, e.g., BF-completeness when we care about I/O working
21:23:53 <b_jonas> for the two Magic: the Gathering constructions, M:tG is simulating Flooding Waterfall, which is simualting The Waterfall Machine, which is simulating a Minsky machine, which is simulating a multi-stack machine
21:24:48 <ais523> b_jonas: it's simulating Flooding Waterfall Model, which is compiled to from The Waterfall Model, which is interpreting Spiral Rise, which is interpreting a tag system (and Turing machines can be compiled into tag systems)
21:24:51 <b_jonas> except that the Flooding Waterfall, Waterfall, and Minsky machine stages are strictly limited in how many clocks or counter they can have, because of the limit of 280 or so creature types
21:25:07 <ais523> the Spiral Rise interpreter is known to fit within the required number of creature types, which is the reason to do it that way
21:25:07 <b_jonas> oh, it goes through tag systems instead of Minsky machines?
21:25:11 <b_jonas> I see
21:25:28 <b_jonas> ok, what ais523 says then
21:26:04 <ais523> one weird observation I've had recently, which feels like it might be more than a coincidence, is that it's easiest to compile counter machines into counter machines and queue automata into queue automata (unsurprisingly), but also to interpret counter machines with queue automata and queue automata with counter machines
21:26:06 <FortyTwoBB> yeah 7 clocks is enough for a UTM in waterfall, so like 50 clocks is enough to simulate that in flooding
21:26:29 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
21:26:31 <ais523> 50 would be enough if you could start up with damage marked on the tokens
21:26:47 <ais523> in practice you need a few more because that isn't a valid startup state
21:28:06 <b_jonas> ais523: um, I don't understand. Minsky machines should be able to interpret multi-stack machines more directly than Minsky machines can interpret queue automata
21:28:08 <FortyTwoBB> yeah i dont think we can start predamaged
21:28:47 <ais523> FortyTwoBB: it's fine, there's already a construction to compute a predamaged state rather than starting in it
21:28:55 <ais523> it's just, that computation needs extra counters to work
21:29:08 <b_jonas> how do queue automata come into this if you start from counter machines (as opposed to if you start from M:tG or Waterfall)?
21:29:28 <ais523> b_jonas: so the basic idea is that a stack is encoded in counters using the digits of a number
21:29:54 <ais523> and a queue can be encoded the same way, you just need to know where the back of the queue is in order to push onto it (via addition)
21:30:35 <ais523> but if you don't track the end of the queue and instead just move the push position a set number of place values each time, the resulting language is still generally TC anyway
21:30:57 <b_jonas> ais523: yes, and Minsky machines can only access the lowest digits, like a stack; as opposed to eg. blindfolded arithmetic which could use a number as a deque of digits directly by using an extra counter that stores the unit of the highest digit
21:31:06 <ais523> (in fact it is possible to design simple TC queue automata where every cycle pushes a constant amount onto the queue, so the position of the back of the queue moves linearly)
21:31:20 <b_jonas> oh!
21:31:25 <ais523> b_jonas: they can only *read* the lowest digits
21:31:39 <ais523> writing at the most significant end is not particularly difficult, though
21:32:17 <b_jonas> so in Minsky machine you can have an unshift-push-pop queue (which can't shift) directly
21:32:23 <b_jonas> that's nice, I haven't realized that
21:32:25 <ais523> right
21:32:50 <ais523> this is basically the data structure I used in Esimpl, although I didn't realise at the time how well it mapped onto counter machines
21:33:11 <b_jonas> how many counters do you need for that to start to work? four?
21:33:27 <b_jonas> maybe three is enough
21:33:58 <ais523> two counters can implement any number of counters, so the answer to that depends on the extent to which you're allowed to cheat, which is hard to objectively define
21:34:07 <b_jonas> yeah
21:34:09 <FortyTwoBB> lol
21:35:30 <b_jonas> maybe I didn't realize this because I don't usually *want* to simulate queues instead of stacks
21:35:38 -!- tromp has joined.
21:35:43 <ais523> but, Spiral Rise can be implemented with (6 + 1 halt) Waterfall Model counters or (5 + 1 halt) tag system states
21:36:04 <ais523> which gets around the lack-of-objective-definition problem by charging for the control flow in addition to the data storage
21:36:21 <ais523> err, tag system symbols, not states
21:37:52 <b_jonas> and this matters because the translation from Waterfall to Flooding Waterfall is somewhat inefficient in the number of clocks, right?
21:38:38 <ais523> b_jonas: yes – it's linear but the constant factor is fairly bad
21:38:48 <FortyTwoBB> its like 7 clocks per clock plus some overhead
21:39:07 <b_jonas> ok
21:41:53 <ais523> I think it's 6 clocks per clock, + constant overhead, + startup overhead, but the startup overhead is linear in the number of clocks
21:42:04 <FortyTwoBB> at least with the way ais523 found to do it. its possible that theres a better way, but that's not super relevant
21:42:45 <ais523> there is almost certainly a better way, but not much incentive to find it at this point
21:43:32 <b_jonas> right
21:43:55 <FortyTwoBB> yeah this works comfortably and isn't massively more inefficient than necessary
21:44:41 <b_jonas> because as long as you fit in the 280 or so creature types, the actual number of creature types is unlikely to matter for the M:tG construction
21:44:49 <FortyTwoBB> exactly
21:47:42 <FortyTwoBB> if we were more limited and adding clocks to keep the necromancers alive and a clock or two to keep the output nice was starting to run into the limits of the namespace id be worried, but its nowhere close
21:50:06 <b_jonas> this is so theoretical, in real games I think three is the largest number of different tokens that I've produced, perhaps four if I forgot something
21:50:33 <FortyTwoBB> absolutely
21:51:35 <FortyTwoBB> this deck is unlikely to win any normal game of vintage
21:52:48 <FortyTwoBB> a single force of will or force of vigor or force of negation in the wrong spot kills us
21:53:03 <ais523> or not drawing the correct starting hand
21:53:38 <FortyTwoBB> the correct top like 19 cards
21:54:50 <FortyTwoBB> but I mean even in those 1/60! games we still force the opponent to draw, and nearly every deck has some 0 mana interaction on the draw.
21:54:54 <ais523> my competitive version of the deck (which just aims to do a computation, not to do anything with the output) is now only six sideboard slots away from a real Legacy deck (Legacy rather than Vintage so that there's less disruption to fight through), although that deck cares a lot about its sideboard space
21:55:21 <b_jonas> yes, it's ais's deck that tries to win games, but the part where the Flooding Waterfall program should fit in the 280 or so creature types applies just as much to ais's dekc
21:55:49 <ais523> FortyTwoBB: one of the top Vintage decks at the moment is mono-white initiative, I don't think it has zero mana interaction pre-board other than start-of-game actions
21:56:03 <ais523> so drawing it extra cards is not necessarily going to ruin your chances
21:56:26 <FortyTwoBB> solitude
21:56:46 <ais523> ah yes
21:58:07 <FortyTwoBB> really its just the non-blue shops decks that might just have a mental misstep preboard
21:58:29 <ais523> colorless shops doesn't even run that, apparently (I just checked a list of the top vintage decks)
21:59:00 <ais523> although it has mindbreak traps in the sideboard, in case it goes up against a turn 1 combo deck
21:59:35 <FortyTwoBB> and we don't care about mental misstep
21:59:52 <ais523> that said, the deck might potentially be able to combo through a solitude?
22:00:33 <FortyTwoBB> no solitude can interrupt computations
22:01:10 <ais523> but that makes the deck go cooperatively infinite, and the opponent in this situation presumably isn't cooperating
22:01:46 <FortyTwoBB> well then the exile our riftsweeper and fizzle us
22:02:41 <ais523> ah right, that's the chokepoint
22:03:32 <ais523> the infinite in my competitive deck is *really* janky, it involves using a set of copies of Fractured Identity to transfer a Riftsweeper token back and forth between the players, while there are relevant cards in exile
22:03:32 <FortyTwoBB> I think we can still kill them, but its not nearly as impressive
22:03:54 <ais523> but enough of them so that the opponent can't unexile enough to stop the combo
22:04:15 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:04:49 <FortyTwoBB> yeah trying to make SB cards do double duty as actually reasonable magic cards is tricky
22:07:02 <FortyTwoBB> anyway i g2g soon any thing else i can answer in the next few mins?
22:07:17 <ais523> I don't think there's any pressing issues remaining
22:07:29 <ais523> at least, not that I can think of right now
22:07:41 <ais523> it is fun watching the progress of the construction in the thread
22:07:58 <FortyTwoBB> ill still logcheck if you think of something
22:08:14 <b_jonas> ais523: you should still summarize or at least link your Netrunner construction from the wiki
22:08:28 <ais523> b_jonas: I did on my user page, didn't I?
22:08:33 <b_jonas> unless you are ok with me just reformatting the whole thing to wiki
22:08:42 <b_jonas> ah yes, your user page links to it
22:08:51 -!- FortyTwoBB has quit (Quit: Client closed).
22:08:55 <b_jonas> but even so, it should have a link from the main namespace too
22:09:10 <b_jonas> so that it's found in normal searches
←2023-10-25 2023-10-26 2023-10-27→ ↑2023 ↑all