00:19:25 -!- SGautam has joined.
00:24:58 <esolangs> [[Goto Considered Harmless]]  https://esolangs.org/w/index.php?diff=112539&oldid=110930 * Ninesquared81 * (+9) 
00:38:39 -!- FreeFull has quit.
02:39:23 -!- razetime has joined.
03:28:51 -!- SGautam has quit (Quit: Connection closed for inactivity).
03:32:58 -!- razetime has quit (Remote host closed the connection).
03:58:59 <esolangs> [[Brainfuck(B,R,A,I,N,F,U,C,K)]] M https://esolangs.org/w/index.php?diff=112540&oldid=111885 * None1 * (-1) /* See also */
04:00:40 <esolangs> [[Scratch is dumb]] M https://esolangs.org/w/index.php?diff=112541&oldid=112437 * None1 * (-1) /* Turing completeness */
06:46:33 -!- tromp has joined.
07:40:10 -!- siesta has joined.
07:43:14 -!- siesta has quit (Client Quit).
08:25:57 -!- tromp has quit (Read error: Connection reset by peer).
08:58:50 -!- Sgeo has quit (Read error: Connection reset by peer).
09:39:48 <esolangs> [[Stacks]] N https://esolangs.org/w/index.php?oldid=112542 * Yetyetty1234567890 * (+854) Stack
09:40:23 <esolangs> [[Stacks]]  https://esolangs.org/w/index.php?diff=112543&oldid=112542 * Yetyetty1234567890 * (+4) 
09:40:36 <esolangs> [[Stacks]]  https://esolangs.org/w/index.php?diff=112544&oldid=112543 * Yetyetty1234567890 * (-2) 
09:40:45 <esolangs> [[Stacks]]  https://esolangs.org/w/index.php?diff=112545&oldid=112544 * Yetyetty1234567890 * (-2) 
09:42:54 <esolangs> [[Stacks]]  https://esolangs.org/w/index.php?diff=112546&oldid=112545 * Yetyetty1234567890 * (+11) moar
09:44:13 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
09:44:53 -!- Lord_of_Life has joined.
10:33:29 -!- ddff has joined.
11:25:21 -!- Melvar has quit (Quit: WeeChat 3.6).
11:35:17 -!- razetime has joined.
11:41:49 -!- Melvar has joined.
11:51:40 -!- Melvar has quit (Quit: WeeChat 3.6).
11:58:35 -!- Melvar has joined.
12:22:10 <esolangs> [[So is your face.]] N https://esolangs.org/w/index.php?oldid=112547 * None1 * (+639) Created page with "So is your face. is an esolang created by [[User:None1]]. ==Syntax== So is your face. uses a stack, the stack is initially empty. Every line is a command, commands other than <code>So is your face</code> pushes itself into the stack. The command <code>So is your f
12:22:28 <esolangs> [[So is your face.]] M https://esolangs.org/w/index.php?diff=112548&oldid=112547 * None1 * (+1) 
12:23:19 <esolangs> [[Language list]]  https://esolangs.org/w/index.php?diff=112549&oldid=112534 * None1 * (+23) /* S */
12:36:46 -!- ddff has quit (Read error: Connection reset by peer).
12:42:11 -!- ddff has joined.
12:52:07 <esolangs> [[Stacks]]  https://esolangs.org/w/index.php?diff=112550&oldid=112546 * Yetyetty1234567890 * (+37) /* Stacks */ loop
13:56:57 -!- gugu256 has joined.
14:15:51 -!- gugu256 has quit (Ping timeout: 245 seconds).
14:23:37 <esolangs> [[Strvar]]  https://esolangs.org/w/index.php?diff=112551&oldid=73461 * Kaveh Yousefi * (+145) Added a hyperlink to my implementation of the Strvar programming language on GitHub and changed the category tag Unimplemented to Implemented.
14:24:26 <esolangs> [[Strvar]]  https://esolangs.org/w/index.php?diff=112552&oldid=112551 * Kaveh Yousefi * (+26) Supplemented the category tag Output only.
14:26:11 <esolangs> [[Strvar]]  https://esolangs.org/w/index.php?diff=112553&oldid=112552 * Kaveh Yousefi * (+114) Added a further example in a simple counter.
14:46:39 -!- ddff has quit (Read error: Connection reset by peer).
14:51:54 -!- FreeFull has joined.
14:52:03 -!- ddff has joined.
14:55:26 -!- ais523 has joined.
14:57:02 -!- ais523 has quit (Client Quit).
14:57:27 -!- ais523 has joined.
14:57:50 <ais523> I'm guessing the following language is sub-TC, but it would be nice to have a second opinion: you have two unbounded bignums x and y, and commands "increment x", "increment y", "decrement x", "decrement y", "restart the program if x==0", "restart the program if x<y"
14:59:03 <ais523> I have observed this, or something that trivially reduces to this, "naturally" occurring twice now
14:59:05 <ais523> I suspect this is pretty similar to two-variable Subtractpocalypse, but that isn't known TC on two variables
14:59:24 -!- ais523 has quit (Remote host closed the connection).
14:59:43 -!- ais523 has joined.
15:00:18 <ais523> anyway, the reason I think it's sub-TC is that you need two counters to store data in a Minsky machine, meaning that you have nowhere obvious to store the IP when the program restarts
15:00:27 <ais523> ("restart the program" here means "goto the start", you don't reset x and y)
15:02:24 <ais523> oh, just realised that this is trivially implemented by two-variable Subtractpocalypse, where the variables are x and (y-x)
15:02:38 <ais523> so even less likely to be TC than two-variable Subtractpocalypse is
15:04:43 <ais523> although thinking about this, maybe three-variable Subtractpocalypse is TC? the variables would be the IP, a counter that stores data and is manipulated by multiplying and dividing it, and a counter that remembers temporary values during the multiplications and divisions
15:04:58 <ais523> that would be big news because it would prove FTL Turing-complete
15:05:15 <ais523> (FTL: Faster Than Light, a roguelike computer game)
15:05:22 -!- gugu256 has joined.
15:05:48 <ais523> (well, roguelike-ish, it's approximately halfway between roguelike and roguelikelike based on the Berlin Interpretation)
15:32:44 <int-e> We can replace "restart the program if x<y" by "restart the program if y < 0", right...
15:33:51 <int-e> (Where the new y is y-x... ah I guess that's what you did to get into Subtractpocalypse territory.)
15:40:12 <ais523> right, we both had the same idea there
15:40:28 <APic> ☺
15:44:38 <int-e> Anyway, yeah, I'm convinced this is not TC without more variables... if we start far away from the axes, then we either terminate or be stuck in a loop with a fixed offset. So that either doesn't terminate or it brings us into the visinity of at least one of the axes. If we're close to one of the axes but far away from the other we can do essentially the same thing, but with a finite state...
15:44:44 <int-e> ...machine to keep track of the near-axis value... there's only one counter left, so we can determine whether it's stationary, going to infinity or approaching 0. And if we're close to both axes, that's a proper finite state machine.
15:46:05 <int-e> This breaks horribly with three variables because we just /might/ be able to simulate a two-counter Minsky machine.
15:46:27 <int-e> I don't see how, but the crude analysis I did for two variables can't rule that out.
15:47:27 <int-e> Basically... the observation is that we need to sacrifice at least one variable for control flow.
15:47:54 <int-e> (~ state transitions in a finite state machine)
15:52:31 <ais523> right, the key observation is that when far from the axes, all we can do is move with a fixed vector; if that moves away from both axes it's a trivial infinite loop, if it moves towards one or both then it is impossible to get more than a finite distance away from that axis unless we let *both* variables get near 0, which is only a finite number of states
15:52:54 <ais523> so this can always be implemented by a finite state machine + 1 counter, which is not enough to be TC
15:53:56 <APic> ais523: What would a Turing Machine need more? More than one Counter? Or other Operations?
15:54:01 <ais523> and the observation breaks down when there are three variables because now it's possible to maintain two counters in addition to the finite state machine
15:54:36 <ais523> APic: so if your counters can only be incremented and decremented, the normal Turing-completeness construction involves two counters and a finite state machine to determine how to change them
15:54:53 <int-e> Subtractpocalypse 
15:54:55 <int-e> whoops
15:55:00 <ais523> and the tricky part with the language I mentioned above is not that the counters are missing, but that the finite state machine is missing
15:55:08 <APic> ais523: Thanks for the Explanation
15:55:28 <int-e> In Subtractpocalypse, the program even just terminates unless one of the variables is close to 0.
15:55:51 <int-e> So the same observation applies, but in a bit simpler form.
15:55:57 <int-e> (for two variables)
15:57:32 <ais523> in three-variable Subtractpocalypse it is trivial to get one variable to control the "movement vector" for the other two, so the only interesting part is what happens when you hit an axis with two of the variables near zero (your control variable, and one of the data variables)
15:59:30 <ais523> oh and I think this gives you full FSM + control flow? the idea is that the program is written in order, first you have all the cases for control variable 1, then 2, then 3, then so on
16:00:35 <ais523> you can do an unconditional goto, from one value of the control variable to another, by first adding the difference between the old and new value, then subtracting the new value + 1, then adding the old value + 1 as three separate commands
16:01:03 <ais523> the control variable can't be lower than the old value you're checking for because the cases are written in order, if it's higher then nothing happens, and if it's equal it causes a restart with the new value
16:01:47 <int-e> yeah I think that works
16:01:56 <ais523> or, hmm, this is still not quite a valid proof because conditional gotos may fire too early
16:02:03 <int-e> mmm
16:02:09 <int-e> right, meh
16:02:23 <ais523> if the data adjustment for control value x happens to go out of bounds even though the IP is x+1…
16:03:09 <ais523> ooh, can't you fix *that* by using the same technique to add a constant to both data values whenever a conditional goto condition is met?#
16:04:45 <ais523> like, before testing the data values, you increase them by a lot, so that if the decrease fails they're now large enough that you can move one update in any direction
16:05:58 <ais523> I'm not sure you can trivially write any program in that form, but I think it's possible to at least write the "multiply and divide one variable by various prime numbers by using the other one as a temporary" program and that's enough to be TC
16:09:34 <ais523> or, actually, what about this: you use the FSM/control variable to manually store values near 0, using the data variables to remember the values only when they aren't near 0
16:10:12 <ais523> or, no, doesn't work, you don't know when a value which was large has become near 0
16:14:52 <int-e> How about this... for a Minsky machine, increment all counters by 1. Then, instead of  a: dec A b c, first do a non-failing decrement  a: dec A a' a', then the testing decrement a': dec A b' c', and then increment the value back up, b': inc A b, c': inc A c. Then assign the state numbers first to the increments, then to the testing decrements, and then to the non-failing decrements.
16:15:14 <int-e> Ah
16:16:08 <int-e> That still gives us only one test per variable. So we need to modify the state tracking for that.
16:17:47 <ais523> ooh – make it so that we only change counters 1 at a time (I think we were doing that anyway), number states so that all successful-decrements and all failed-decrements change the state number by the same amount (different for successful and failed cases)
16:18:37 <ais523> using plain gotos to fix up the numbering if needed
16:18:44 <ais523> now there is only one possible false positive: a failed decrement of x (or whichever variable gets decremented first) when we were meant to be decrementing y
16:18:54 <int-e> "by the same amount" - yeah I was about to suggest this too
16:19:17 <int-e> (negative amount of course, so that we get to the saving increments early)
16:19:23 <ais523> and that false positive can be fixed by incrementing x whenever control flow goes to a state that could decrement y (and decrementing it again when leaving that state)
16:20:17 <int-e> the false positive is what I was intending to fix by keeping the variables at at least 1 except for testing
16:20:37 <int-e> (yeah I realize we're developing similar ideas in parallel here)
16:21:39 <ais523> I'm pretty sure 3-variable Subtractpocalypse is TC at this point
16:21:53 <ais523> although it might take me a while to formally prove it / write a compiler as I'm busy with something else atm (and keep getting distracted)
16:22:51 <int-e> So basically the states will be assigned for increments, the there's a huge gap in the state numbers where we subtract a fixed offset from the state and then tentatively decrement all three variables. And then there's still room for all the non-failing decrements.
16:26:05 <ais523> this is going to work but I think there might be a still simpler approach – for both data variables, unconditionally do a failable decrement, that *increments* the variable when it fails, also *adding* a fixed constant to the state variable when it fails
16:27:11 <ais523> oh, simpler still, you can actually just decrement both variables at once, adding the same fixed constant if either decrement fails (it can even be the same statement), arranging things so that a failed decrement of either variable increments both
16:27:12 -!- ais523 has quit (Remote host closed the connection).
16:27:27 -!- ais523 has joined.
16:27:46 <ais523> now, you can just write the rest of the program with increments and unconditional gotos
16:27:48 <int-e> right
16:27:56 <ais523> and decrement a variable by not incrementing it
16:28:51 <ais523> (the failed increment is better adding to the state variable rather than subtracting because then you don't have to worry about a failed subtraction from the state variable)
16:28:57 <int-e> so instead of dec A you do inc B followed by dec A,B
16:29:44 <ais523> right – or well, the program starts as A+=1,B+=1,S+=something;A-=2,B-=2
16:30:00 <ais523> then S-=same_something
16:30:23 <int-e> so we have a variant of a Minsky machine with two-argument decrement (just two labels) :)
16:30:40 <int-e> (small but cute variation)
16:30:44 <ais523> this has the effect of either decrementing both A and B, or adding something to S, and there are no other options (if the subtraction fails on one pass it will always succeed on the next)
16:30:54 <int-e> dec_all <fail> <success>
16:31:46 <ais523> then the whole rest of the program is done by adding to A and/or B, then the "goto from S to T" routine, then putting A and B back to their original values; only the goto can fail
16:32:22 <ais523> and writing it in ascending order of S means that restarts only happen in the one specific situation where they're meant to happen
16:52:00 <int-e> It really looks rather straightforward: http://paste.debian.net/1287318/
16:56:17 -!- ddff has quit (Read error: Connection reset by peer).
16:56:51 <ais523> oh, that's probably a little smaller in terms of the size of the generated program than the order I was doing things in, with the single decrement first
16:57:02 <ais523> but I think it works both ways, there's a lot of slack here
17:01:11 <int-e> I agree with that
17:01:53 -!- ddff has joined.
17:02:06 <int-e> it's funny how the "big negative offset" became S+k (because S has already been decreased be k+l at this point)
17:03:31 <int-e> actually that suggests changing the offset to k+l
17:06:30 <int-e> so like this: http://paste.debian.net/1287320/
17:07:08 <int-e> (just a tweak of course)
17:08:19 <int-e> http://paste.debian.net/1287321/ ... S-(L(a)-1) should be S-L(a)-1... tsk, tsk.
17:12:58 -!- chiselfuse has quit (Ping timeout: 240 seconds).
17:13:15 -!- chiselfuse has joined.
17:23:44 -!- example99 has joined.
17:27:19 <example99> hi!!!
17:28:02 -!- razetime has quit (Remote host closed the connection).
17:35:29 -!- razetime has joined.
17:42:32 -!- razetime has quit (Ping timeout: 244 seconds).
18:01:18 <gugu256> example99: hi!
18:04:38 -!- example99 has quit (Quit: Client closed).
18:06:24 -!- FreeFull has quit (Ping timeout: 250 seconds).
18:16:19 -!- example99 has joined.
18:18:20 -!- APic has quit (Quit: Lost terminal).
18:19:05 -!- APic has joined.
18:20:20 -!- example99 has quit (Client Quit).
18:25:18 -!- Sgeo has joined.
18:38:19 <esolangs> [[Strvar]]  https://esolangs.org/w/index.php?diff=112554&oldid=112553 * Kaveh Yousefi * (+1) Rectified the second interpreter test case, which lacked a semicolon (;) for the penultimate statement line's conclusion.
18:43:14 -!- gugu256 has quit (Read error: Connection reset by peer).
19:04:06 -!- ais523 has quit (Quit: quit).
19:20:00 -!- chiselfuse has quit (Remote host closed the connection).
19:20:22 -!- chiselfuse has joined.
20:07:48 <esolangs> [[Esolang:Introduce yourself]]  https://esolangs.org/w/index.php?diff=112555&oldid=112507 * Airscript * (+216) feat: add airscript
20:08:08 <esolangs> [[Analscript]] N https://esolangs.org/w/index.php?oldid=112556 * Airscript * (+15120) feat: create analscript wiki page
20:15:39 <esolangs> [[GolFunc]]  https://esolangs.org/w/index.php?diff=112557&oldid=107659 * Joaozin003 * (-1) /* Example programs */
20:16:02 <esolangs> [[Analscript]]  https://esolangs.org/w/index.php?diff=112558&oldid=112556 * Airscript * (-24) refactor: change code tag with space
20:16:06 <esolangs> [[GolFunc]]  https://esolangs.org/w/index.php?diff=112559&oldid=112557 * Joaozin003 * (+19) /* Basic concepts */
20:16:26 <esolangs> [[Analscript]]  https://esolangs.org/w/index.php?diff=112560&oldid=112558 * Airscript * (-12) refactor: remove code tag with space
20:18:26 -!- chiselfuse has quit (Remote host closed the connection).
20:34:43 -!- chiselfuse has joined.
21:23:17 -!- ddff has quit (Quit: leaving).
21:38:58 -!- tromp has joined.
21:53:24 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:40:47 -!- Cale has quit (Ping timeout: 264 seconds).