00:03:44 <b_jonas> do you own that or is that a work or research machine that you have access to?
00:03:55 <Lymia> It's just a fairly high end laptop.
00:04:52 <esolangs> [[PyFuck]] https://esolangs.org/w/index.php?diff=144608&oldid=144603 * Ais523 * (+70) formatting
00:04:56 <Lymia> That's $240 of laptop RAM lol.
00:05:32 <zzo38> Is there TLS implementation that only implement the protocol, and you can include your own code for other stuff (without having dependency on specific libraries; you can use any function that implements them)?
00:06:05 <esolangs> [[PyFuck]] https://esolangs.org/w/index.php?diff=144609&oldid=144608 * Ais523 * (+17067) /* Variants */ move the Hello World program here from the Hello World list, because it's too long for that page
00:06:38 <Lymia> https://www.newegg.com/mushkin-enhanced-96-gb-262-pin-ddr5-so-dimm/p/0RM-001Z-000X4 this stuff
00:07:50 <zzo38> (The functions such as hashes, encryption, public key handling, ASN.1, etc are things that would be usable independently, and a program might have them for other reasons, even if there is a conditional compilation for use or not use oF TLS)
00:08:01 <esolangs> [[Hello world program in esoteric languages (N-S)]] https://esolangs.org/w/index.php?diff=144610&oldid=144606 * Ais523 * (-22302) /* PyChr */ /* PyFuck */ these programs are too long for this page, move them onto the language page
00:08:27 <korvo> zzo38: Twisted Python comes to mind.
00:08:52 <korvo> Oh, no, sorry, that's only SSH. I think their TLS is via OpenSSL or other system libraries. Nevermind.
00:09:10 <b_jonas> Lymia: you it's not just the RAM, you need a motherboard that can use it all
00:09:30 <esolangs> [[PyChr]] M https://esolangs.org/w/index.php?diff=144611&oldid=144607 * ShirAko * (-378) Shortened Hello World by 2% !
00:10:16 <Lymia> Wtf, desktop RAM is more expensive than laptop right now?
00:10:41 <b_jonas> the motherboard that I'm using for my personal desktop supports at most 64 GB of RAM, and I bought this in 2021
00:11:24 <b_jonas> desktop RAM is more expensive? hehe, that's like how micro-SD cards are cheaper than SD cards with the same speed and capacity
00:11:47 <esolangs> [[Hello world program in esoteric languages (N-S)]] https://esolangs.org/w/index.php?diff=144612&oldid=144610 * Ais523 * (+5) /* PyChr */ better link
00:11:49 <b_jonas> even though you get a free SD card converter with the micro-SD card
00:11:52 <korvo> I have a space-heater workstation purchased used on eBay. It has 150 GiB of RAM and cost me $150. Model's Dell Precision T3910; I think it listed for like $1500 originally, so I got a 90% discount buying used.
00:11:57 <Lymia> This was 2023Q4, so, definitely newer.
00:12:02 <zzo38> I am using C and not Python.
00:12:18 <Lymia> I got a very new laptop since, uh... I don't intend on fully replacing it for years.
00:12:25 <korvo> If you *want* RAM, then it's very cheap in the secondhand marketplace. Lots of old workstations needing some love.
00:12:27 <esolangs> [[PyChr]] M https://esolangs.org/w/index.php?diff=144613&oldid=144611 * ShirAko * (+236) Added Translator/Encoder
00:12:43 <Lymia> And I expect RAM is going to be what fucks me up 10 years down the line.
00:12:50 <esolangs> [[PyFuck]] https://esolangs.org/w/index.php?diff=144614&oldid=144609 * Ais523 * (-17423) remove content that's duplicated in the [[PyChr]] article, replacing it with a "See also" section
00:12:54 <Lymia> Looking at the trends over the past decade. x.x;
00:13:38 <b_jonas> 96 GB might be enough to run bovex
00:13:40 <esolangs> [[PyFuck]] https://esolangs.org/w/index.php?diff=144615&oldid=144614 * Ais523 * (+100) restore the categories, which I deleted by mistake
00:13:55 <b_jonas> though you also need an expensive graphics card
00:14:22 <esolangs> [[PyChr]] https://esolangs.org/w/index.php?diff=144616&oldid=144613 * Ais523 * (+30) see also
00:15:13 <korvo> Is that a "bovine database"? My search engine seems to think it's cattle-related.
00:16:13 <b_jonas> no, https://esolangs.org/wiki/BoVeX
00:16:36 <b_jonas> the "bov" part comes from the name of Harry Q. Bovik, a fictional person in whose honor the joke conference is held
00:18:44 <salpynx> in the context of BoVeX, i don't know if "parahgraphs" is a typo, or an in-joke
00:19:16 <esolangs> [[BoVeX]] https://esolangs.org/w/index.php?diff=144617&oldid=129698 * B jonas * (-1)
00:21:06 <Lymia> BoVeX is absurd, lmao.
00:21:26 <Lymia> Yeah, no, I only have iGPU right now.
00:21:31 <Lymia> Will have an eGPU some day, but that day isn't today.
00:21:37 <Lymia> And it probably won't be high end enough for that nonsense.
00:22:52 <b_jonas> yeah, tom7 specifically explains somewhere in the article that “largest video card” (commercially available at the time) is not an exaggeration
00:23:15 <b_jonas> or maybe it was on the blog, not the article
00:23:37 <b_jonas> wait, why doesn't that wiki page link to the video?
00:31:33 <b_jonas> http://radar.spacebar.org/?month=1&year=2024 mentions it only in brief, it's the article that says “the world's (physically) largest video card […] the GeForce 4090”, and also his computer has 256 GB of RAM, of which 130 GB is needed for the language model that he uses, so no, 96 GB wouldn't be enough
00:32:31 <esolangs> [[BoVeX]] https://esolangs.org/w/index.php?diff=144618&oldid=144617 * B jonas * (+159)
00:35:32 <esolangs> [[PyFuck]] M https://esolangs.org/w/index.php?diff=144619&oldid=144615 * ShirAko * (+14) Thank you Ais523! I had to change the Hello World program again because of an edit conflict when I tried to correct it. (previously, it was Hello world! without a capital W)
00:35:33 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).
00:36:16 <esolangs> [[PyFuck]] M https://esolangs.org/w/index.php?diff=144620&oldid=144619 * ShirAko * (+4)
00:37:32 <esolangs> [[User:ShirAko]] M https://esolangs.org/w/index.php?diff=144621&oldid=144497 * ShirAko * (+81)
00:46:14 <Lymia> I'm wondering if there's a way to do a modified markov that's more stable.
00:46:35 <Lymia> Watching the (zem) hill for a while, I'm starting to think that markov overvalues beating the strongest bot on the hill.
00:47:30 <ais523> I play duplicate bridge tournaments quite frequently (although usually not major ones)
00:47:57 <ais523> they often use a scoring method called "VP" where you get points for beating opponents, and more points for beating them by more, but with diminishing returns
00:48:08 <ais523> I've pondered what a BF Joust hill would look like if it were scored by VP
00:48:39 <ais523> (it goes the other way round, too – losing means you get less VP and losing by more still less, but again with a diminishing penalty)
00:48:48 <b_jonas> ais523: does that involve a fixed or variable number of hands within the match?
00:49:08 <ais523> can be a variable number of matches but each match itself is fixed size
00:49:29 <ais523> it seems to correspond quite well to BF Joust, because that also has fixed-size matches between pairs of opponents
00:51:44 <ais523> I'm pretty sure that there's some mathematical reason to get a particular amount of VP for a particular victory margin, but the guides don't tell you the formula, just a whole load of oddly specific numbers
00:57:19 <esolangs> [[PyFuck]] https://esolangs.org/w/index.php?diff=144622&oldid=144620 * ShirAko * (+302)
00:57:27 <esolangs> [[PyFuck]] M https://esolangs.org/w/index.php?diff=144623&oldid=144622 * ShirAko * (+38) Final small adjustements...
01:03:28 <Lymia> VP would be a nice balance between rewarding decisive wins and marginal wins, it sounds like.
01:03:53 <Lymia> (Since both... do represent useful strategies.)
01:04:40 <esolangs> [[PyFuck]] M https://esolangs.org/w/index.php?diff=144624&oldid=144623 * ShirAko * (-110) It is finally done.
01:05:26 <b_jonas> it's kind of different because in Bfjoust each game result is just win or lose or draw, while bridge has more different results with different values. but that might not be enough of a difference to matter for scoring.
01:05:49 <ais523> you can play win/lose/draw bridge, it's in theory my favourite way to play team games but I've never had the opportunity
01:06:23 <ais523> the advantage is that it means that every board is equally valuable, rather than slam boards being worth over 10 times as much as overtrick boards
01:06:30 <b_jonas> how would win/lose/draw bridge?
01:07:07 <ais523> it's played in teams of four players, each team sits north/south at one table and east/west at the other, you have the same cards in the same directions at each table
01:07:27 <b_jonas> right, so still duplicate bridge
01:07:34 <ais523> and whichever team gets a higher-scoring contract wins (with penalties scoring as though they were a contract made by the other side)
01:08:30 <ais523> so, e.g., if one team makes 2S+1 sitting N/S and the other makes 2H= sitting N/S, the team making 2S+1 win because that scores 140 to 2H='s 110
01:09:03 <ais523> if a team "goes plus" (makes a contract or takes a penalty) at both tables (despite sitting in opposite directions) that wins the board automatically, obviously
01:09:14 <Lymia> I do have the basic idea in mind of a "reverse markov scoring" too.
01:09:16 <ais523> but normally you are comparing differently-sized plus scores
01:09:29 <Lymia> Where rather than beating strong bots being strongly reward, beating weak bots gets you marginal gains.
01:09:38 <Lymia> But I'd need to think about how to formalize that.
01:10:49 <b_jonas> but if it's normalized to just win/lose/draw for each one duplicate deal, doesn't that make it so that even if you play several such duplicate deals there's too few entropy in your total score (adding up just your wins minus losses), and so there'll too often be ties for winning a tournament?
01:11:17 <b_jonas> because there'll be like two teams who each have the same number of wins
01:11:46 <ais523> not normally – imagine a coin-flipping tournament, the odds of a tie are fairly low even though everyone is equally skilled
01:12:02 <ais523> and in practice one side will usually be more skilled than the other, and is very likely to win
01:12:25 <b_jonas> that's because a coin flip is much faster than a game of bridge, so you can play much more coin flips within the time that a tournament lasts
01:12:45 <ais523> the other forms of scoring often make it easier for a lesser-skilled side to win through luck, because they happened to make a lucky decision on one of the few boards that matters
01:12:48 <b_jonas> "one side will usually be more skilled than the other" => sure, but I mean in tournaments with more than just two teams
01:13:32 <ais523> big tournaments are usually either Swiss (where ties are acceptable) or knockouts with very large numbers of boards played (in the US I think the standard is 60 board per match)
01:14:21 <ais523> the odds of a tie in a 60-flip coin-flipping tournament are pretty low; and if you account for skill differences (effectively giving you a biased coin) the odds of a tie are much lower
01:16:28 <Lymia> ooh, impatience is the first bot in a long long time to beat nyuroki on score.
01:16:32 <Lymia> I should examine it closer sometime.
01:17:08 -!- earend1 has quit (Quit: Connection closed for inactivity).
01:18:04 <Lymia> So, hmm. Whether a bot in BF Joust wins against another is kinda... a factor of 3 variables I'd say (estimating). General "overall power" (what hill ranking should measure), archetype matchups (e.g. Nyuroki has anti-defense, so stuff like ash should beat it), and just "noise" from exact timings and unfortunate "silver bullet" matchups.
01:18:05 <ais523> Lymia: it is a slow rush program with a flexible timer clear on a very short timer, and it moves onto the next cell when the timer expiers
01:19:04 <Lymia> Markov overvalues silver bullet matchups vs the top of the hill. Score overvalues bots that are dominant over very low "overall power" levels at cost of its matchups vs more advanced bots.
01:19:22 <ais523> this gives it an unusual but generally pretty good speed-versus-opponent's-decoy-size relationship – against small decoys it can't out-offset it is as fast as a turtle, against larger decoys slightly slower but not by much
01:20:18 <ais523> and this also gives it an obvious huge weakness against flag-defence bots, although if it notices a cell being changed away from 0 it will make sure it's zero on two consecutive cycles before moving on, so you have to defend the flag without impatience observing a 0
01:20:39 <Lymia> That explains rowdy-mate massacuring it.
01:20:52 <ais523> yes, it is expected to lose against competent flag-defenders
01:20:59 <Lymia> They just weren't on the hill before.
01:21:11 <ais523> I think some of them were, and they beat it even when it was submitted
01:21:17 <ais523> just not enough of them to mess up the ranking
01:22:07 <ais523> it makes up for it by being very good against front-of-flag defenders, given that it can sneak past their tripwires on one polarity and will escape locks if it doesn't see a zero
01:22:30 <Lymia> Oh, that's clever!
01:22:35 <ais523> and I feel like front-of-flag defence has traditionally been better than defending on the flag
01:22:39 <Lymia> It expects "true" locks where it doesn't see the flag change at all.
01:22:52 <Lymia> So it doesn't need to use something like a timer.
01:23:07 <Lymia> That is, timer into a different clear cycle.
01:23:09 <ais523> well, it's the same timer that's used for abandoning cells that seem to be wrong-polarity decoys
01:23:50 <Lymia> (Seems ash/impatience/nyuroki is the current top of hill defense/fast rush/slow rush overall?)
01:23:58 <ais523> unfortunately I think the control flow is still buggy
01:24:06 <Lymia> Control flow is always the biggest pain. u.u;
01:24:09 <Lymia> So, understandable.
01:24:24 <ais523> impatience is slow rush
01:24:34 <ais523> in that is has a long decoy setup
01:24:40 <ais523> it's just that the speed of the rush itself is fast
01:24:57 <ais523> maybe "fast rush" should be renamed "early rush"
01:25:30 <Lymia> I imagine nyuroki should still be classified as slow rush, even though it's capable of abandoning it.
01:25:32 <ais523> in general I think there are two distinctly different slow/late rush strategies
01:25:51 <ais523> yes, short-tape special cases normally aren't counted when categorising bots
01:26:07 <ais523> e.g. margins3 is unable to reach the far end of the tape if it's long enough, but it will attack if the tape looks short
01:26:14 <ais523> but it's still a defence program
01:26:48 <ais523> so, one slow rush strategy involves trying to out-decoy the opponent: more decoys, bigger decoys, big offsets to get past the opposing decoys
01:27:22 <ais523> the other involves trying to make "enough" decoys rather than more decoys, and speed up the clear loop by avoiding fancy things like big offsets, in order to try to outrace the previous sort of slow rush strategy
01:28:10 <ais523> generally speaking it has fewer decoys, maybe starts the rush a little earlier, and clears faster against an opposing slow rush program (the tradeoff being that it can be significantly slowed by the fairly small decoys that other strategies use)
01:28:45 <Lymia> (From experience fast/early rush seems to have trouble currently.)
01:28:54 <ais523> and I've increasingly become a fan of the latter strategy, it has been doing very well recently and makes pokes feel like they're something that aren't usable in pure slow rush programs any more
01:29:07 <Lymia> (But I could be trying the wrong things.)
01:29:17 <ais523> yes, fast rush is definitely struggling, although I feel like it's maybe always been struggling?
01:30:07 <Lymia> oh interesting, lugh beats Ash.
01:30:26 <ais523> I feel like the future of fast rush probably involves mixing a rush with a decoy setup, and maybe even some flag repairs
01:30:40 <ais523> but it's hard to write a program like that
01:32:10 <Lymia> Lugh's my attempt at poke + early rush. It's not good, but... could probably be refined into something that is.
01:33:04 <ais523> Lymia: so this seems to be because it re-offsets immediately after the triplock trips, and is able to clear its own offset before ash can get back to the cell to restore the triplock
01:34:42 <ais523> most programs, if they observe the cell changing away from 0 after the timer has expired, use an anti-defense loop that doesn't have an offset, because the cell is clearly either a flag or a lock cell, and you've been there for ages already, so why would you offset?
01:35:15 <ais523> but, ash is attempting to send opponents all the way around from 0 back to 0 again, giving lots of time to attack, and the offset prevents that working
01:38:32 <ais523> I could possibly avoid that by using a more traditional (+)*128 style triplock, but that would have a number of other bad effects and probably make ash score worse overall
01:38:35 <Lymia> Wait it reoffsets the same cell.
01:38:37 <fizzie> The "traditional" scoring also gives you more rewards for beating stronger opponents, by giving each opponent a "worth" (based on the raw points), and making each of your wins give you a fraction of that program's worth. It's probably more stable since it doesn't involve any fixed-point nonsense.
01:38:38 <Lymia> That's a bug, lol.
01:38:41 <fizzie> (In the "true" traditional scoring, the fraction is 100% if you win on all tape lengths, and 0% if you tie, and linearly interpolated between them; in the "tweaked" one even the most marginal of wins gives you ~50% of that program's worth, with the argument that any kind of a win should be meaningfully better than a tie.)
01:39:46 <ais523> huh, ash does fairly well even in traditional (although it isn't near the top of the leaderboard)
01:39:56 <Lymia> fizzie: that's good to know. :o
01:40:10 <ais523> given how many draws it gets, it is not very good at traditional scoring
01:42:15 <Lymia> Lugh shouldn't offset twice on the same cell, anyway.
01:42:22 <Lymia> Except its large reverse offset.
01:42:32 <Lymia> If it does a traditional offset on a cell, something's fucked.
01:42:38 <Lymia> cell it's already seen clear*
01:42:51 <ais523> I feel like a carefully-sized re-offset may be a surprisingly simple way to beat many types of defense program
01:43:37 <Lymia> Ah? To defeat the push-pass-0 approach?
01:43:58 <ais523> or just timing-based locks in general
01:44:09 <ais523> the problem is, you wouldn't want to do it as a consequence of observing 0 because that means you're already on a good timing
01:44:19 <ais523> maybe it could be a good response to timer expiry
01:44:53 <Lymia> Doesn't switching to a different clear cycle length already mess things up on timer expiry?
01:44:58 <Lymia> That's how nyuroki tries to break locks.
01:45:17 <ais523> so a probabilistic lock might be able to lock the new timing too
01:45:27 <Lymia> !ztest lugh_fixed https://dl.rimin.moe/paste/lymia/lugh_1q845r2xf5w9ygslx2vq7ma7f952lzbzb0g9l6y48nr394z82c9i.bf
01:45:28 <ais523> I remember writing a program that changed polarity every 620ish cycles in order to eventually try all possible timings and hit the gap in probabilistic locks
01:45:30 <zemhill> Lymia.lugh_fixed: points 3.05, score 22.86, rank 19/47
01:45:34 <Lymia> !ztest lugh https://dl.rimin.moe/paste/lymia/lugh_1q845r2xf5w9ygslx2vq7ma7f952lzbzb0g9l6y48nr394z82c9i.bf
01:45:37 <zemhill> Lymia.lugh: points 2.38, score 22.75, rank 18/47 (--)
01:45:57 <Lymia> Did find a case where it'd reoffset unintentionally, but doesn't seem to be it.
01:46:08 <ais523> that difference in position is probably losing the mirorr?
01:46:29 <Lymia> !ztest lugh https://dl.rimin.moe/paste/lymia/lugh_0cycvz4xdgzwfk48pgir6a82aqqjwdvn2phcp1fbzvlfs09j0653.bf
01:46:32 <zemhill> Lymia.lugh: points -0.26, score 19.92, rank 24/47 (-6)
01:46:34 <ais523> testing programs that are already on the hill is a little awkward because of the mirror matches, bug fixes normally cause a program to lose the mirror by making it very slightly slower
01:46:52 <Lymia> Yeah, it goes down a lot if you fix that bug.
01:46:57 <Lymia> Probs becuase the bug was screwing over ash.
01:47:06 <ais523> arguably this is not a bug
01:47:13 <ais523> all sorts of behaviour that looks like bugs will beat specific programs
01:47:42 <ais523> e.g. you can get a huge advantage against growth2 by doing a rule of 8 and attacking a cell that can't possibly be the flag
01:48:13 <ais523> because it tries to detect the first cell you clear, and start 9 spaces away from there
01:49:17 <ais523> but that's clearly a bug, so why would programs do that? (and when I've experimented, doing so loses more against other programs than it gains against growth2, so it isn't a worthwhile strategy unless growth2-alikes are dominating the hill)
01:53:54 <zzo38> I think now I had managed to implement 32-bit floating points into ASN.1 DER, although it uses IEEE 754 instead of using the C library functions for that, so might not work on computers that do not have IEEE 754.
01:55:10 <ais523> recently I wrote a program that calculates buffer sizes using floats by reading raw bytes from their in-memory representation, in a way that can lead to out-of-bounds reads if the floats aren't IEEE 754
01:55:36 <ais523> it's basically the fast inverse square root trick, except for calculating the number of digits in an integer, instead
01:56:04 <ais523> I'm not expecting it to lead to problems but maybe I should add some sort of runtime check to ensure that the floats are formatted as expected
01:56:40 <zzo38> What program is that?
01:57:05 <ais523> it's a compiler for a language that might or might not be an esolang
01:57:09 <zzo38> The documentation for my program does mention that the asn1_encode_float function will not work correctly if the C "float" type is not 32-bit IEEE 754 format.
01:58:11 <ais523> which is intended for writing compilers that don't fully understand their input and are just translating syntax in one language to syntax of the same shape in another language directly, without attempting to figure out what the code means
01:58:39 <b_jonas> zzo38: libecb has functions to convert floating point values to or from the common IEEE 754 formats, you can use those
01:59:21 -!- FreeFull has quit (Ping timeout: 252 seconds).
01:59:53 <b_jonas> ais523: you can avoid the out-of-bounds reads at least with something like static_assert(sizeof(float) == sizeof(uint32_t))
02:00:06 <ais523> oh, I have a static assert that float is 4 bytes long
02:00:32 <ais523> that's not the problem, though – I'm using this to calculate the number of bytes it takes to express an integer in ASCII and then blindly writing into the resulting buffer
02:00:51 <ais523> so if the result is low it leads to an out-of-bounds write later on
02:00:53 <zzo38> I don't know what is libecb, but I am not intending to add dependencies other than the C standard library, although some GNU functions may be used (and one part of the program (for sorting items in a set) uses GNU nested functions)
02:01:08 <b_jonas> zzo38: http://software.schmorp.de/pkg/libecb.html
02:01:19 -!- FreeFull has joined.
02:01:33 <ais523> (if the result is high it causes the program's output to be wrong, but doesn't lead to UB)
02:01:41 <zzo38> Is the ISO 2022 also related to the same program you were doing, or different program?
02:02:14 <ais523> the compiler-generator works with raw bytes and doesn't handle character encodings at all
02:02:45 <b_jonas> zzo38: it consists of just one not very long header file so it's not too hard to add as a dependency, and you can even try to slice it to keep only the parts that you need for this program, because it has a free enough license
02:04:42 <b_jonas> ais523: IIRC the J interpreter used to have a bug like this, not because of wrong floating-point format I mean, but a bug in a function that turns an integer to a sequence of digits but sometimes it returns one fewer or one more digit than needed (I don't remember which)
02:04:59 <b_jonas> it's documented but I think it's still a bug
02:06:11 <ais523> I went and iterated over all 4294967296 int32_t values to make sure the lengths were correct, and have added a test that tests a representative subset (including all the values that are expected to be awkward) so that I can quickly rerun it on a new computer or if I make changes to the code
02:07:08 <b_jonas> that's good, it's just much harder to do with doubles
02:07:14 <b_jonas> (or with two float parameters)
02:07:25 <b_jonas> also I really should report that floating-point bug in qemu
02:08:27 <ais523> now I am reminded of the floating-point bug in the Wii Virtual Console which made it possible to complete Super Mario 64 without ever pressing the A button
02:08:57 <b_jonas> is that the one about the rising and falling water level?
02:09:16 <ais523> not water level, there are platforms which rise and fall out of lava
02:09:48 <ais523> but the Wii Virtual Console rounds towards 0 (as opposed to the N64 which rounds to nearest) and the rounding errors accumulate to make the platforms gradually and very slowly rise upwards, because they start at a negative height value
02:10:32 <ais523> it takes several days before they get to a point that allows you to get past the otherwise unsolved spot in the level, but they get there eventually and you can stand on them in the process
02:13:57 <Lymia> Thinking a little about a better hill scoring algorithm, I think a property comes to mind:
02:14:20 <Lymia> Copies of weak programs should not change the hill much (and by implication, many weak implementations of similar strategies should not change the hill much)
02:14:26 <Lymia> Bonus if this can also be achieved for stronger programs.
02:14:57 <ais523> I wonder if this runs into Arrow's Theorem at some point
02:15:31 <b_jonas> that's exactly what I thought, not quite Arrow's theorem, but just impossible combination of desirable properties of the scoring
02:16:03 <ais523> I don't think it's exactly Arrow's Theorem either
02:16:43 <ais523> although it reminds me a lot of Condorcet voting, in that the main piece of information we have is which programs beat which when they are compared pairwise
02:17:15 <Lymia> Can still make a best try.
02:17:50 <Lymia> An idea that comes to mind is just eliminating the worst program and then rescoring until you end up with a hill of one. I'm not sure I like the implications of that, though.
02:17:56 <ais523> as such, a hill-scoring algorithm is in effect a Condorcet tiebreak, isn't it? so maybe Arrow's theorem does actually apply directly
02:17:59 <Lymia> (Which, is in fact, drawing on voting and such.)
02:20:04 <ais523> if we have an election we want to find the winner of, we do it as follows: for each pair of candidates, treat them as BF Joust programs for which the head-to-head score is based on which of them was preferred by more voters; then score the BF Joust hill; the program that wins is the winner of the election
02:21:00 <ais523> Arrow's theorem says that this method of determining an election has to fail to have at least one of the desirable properties, and that implies the hill scoring algorithm must also fail to have at least one of the desirable properties
02:23:23 <b_jonas> ais523: excuse me, who are the voters for the Bfjoust elections in this analogy? Arrow's theorem depends on that the voters are symmetric, i.e. they have equal votes, and there's more than one voter.
02:24:29 <Lymia> Intuitively speaking: The value of a bot for scoring should be halved when it's duplicated.
02:24:39 <Lymia> However, they should have equal score themselves...
02:24:54 <ais523> b_jonas: it's the other way round, the BF Joust hill is created from a set of voters and preferences via treating each candidate as a program, and one program beating another if more voters rank that candidate above the other than vice versa
02:25:21 <ais523> i.e. we are not treating BF Joust as an election, but rather showing that a hill-scoring algorithm could be used to create an election-scoring algorithm via treating the election as a hill
02:27:33 <b_jonas> so in the election that you're starting from, voters are choosing their preference between each undordered pair of two candidates?
02:28:17 <b_jonas> or is it some more usual form of election?
02:29:21 <ais523> b_jonas: it's sufficient to just have them rank the candidates, then calculate their preference between unordered pairs by looking at which is higher in the ranking
02:30:34 <b_jonas> I think at least part of the problem here is that the bfjoust scoring algorithm can and probably will allow ties, which Arrow's theorem forbids (otherwise you'd just use an election method that always gives a tie unless the votes are unanimous)
02:30:36 <esolangs> [[PythOwO]] M https://esolangs.org/w/index.php?diff=144625&oldid=144294 * RaiseAfloppaFan3925 * (+0) TwT I forgot that pythowo has while loops lol
02:31:31 <b_jonas> but that needn't be the most serious problem
02:32:56 <esolangs> [[PythOwO]] M https://esolangs.org/w/index.php?diff=144626&oldid=144625 * RaiseAfloppaFan3925 * (+30) i fowgot to fix the twuwuth machine code again
02:34:10 <Lymia> First proposal that comes to mind: Use an underlying "simple" scoring method. At each step, eliminate the worst bot, then distribute its score to the remaining bots based on win count. Repeat until all bots are accounted for. Final score for each bot is the number of points it had when it was eliminated.
02:34:45 <Lymia> Can't think of any clean theoretical basis for this, but... may work pretty okay in practice. Will have to try it out.
02:35:35 <b_jonas> ok, what I said earlier about the voters being equal is wrong, Arrow's theorem works with a much weaker assumption than that
02:36:41 <Lymia> Duplicate bots "should" all be eliminated around the same time because they win and lose against the same bots. A duplicate bot should harm its duplicates more than other bots, in fact, because they're taking their score from the same bots.
02:37:07 <Lymia> Then, once it's passed to bots that are higher on the hill, they should recieve about the same amount "gathered" from bots lower on the hill.
02:38:02 <esolangs> [[9]] N https://esolangs.org/w/index.php?oldid=144627 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+4863) Created page with "'''9''' is an [[esolang]] designed by [[User:Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff]] with the goal of compiling to [[90]]. As such, it cannot perform infinite loops, but has bounded loop
02:42:09 <esolangs> [[9]] https://esolangs.org/w/index.php?diff=144628&oldid=144627 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+319)
02:42:27 <esolangs> [[User:Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff]] https://esolangs.org/w/index.php?diff=144629&oldid=143862 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+7)
02:42:34 <Lymia> Eeh. Still not sure about it thinking it through. Maybe traditional scoring is "good enough" with the value system. Adjust it so ties are 0.5 wins, maybe?
02:43:00 <Lymia> Markov scoring starts to feel like a mistake to me, because it's so unstable in extreme circumstances (and slightly unstable in more normal circumstances.)
02:43:52 <esolangs> [[9]] https://esolangs.org/w/index.php?diff=144630&oldid=144628 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+6) /* Transforming this into 90 */
02:44:03 <esolangs> [[9]] https://esolangs.org/w/index.php?diff=144631&oldid=144630 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+5) /* Transforming this into 90 */
02:44:19 <esolangs> [[9]] https://esolangs.org/w/index.php?diff=144632&oldid=144631 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (-15) /* Transforming this into 90 */
02:44:55 <esolangs> [[9]] https://esolangs.org/w/index.php?diff=144633&oldid=144632 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+47) /* Transforming this into 90 */
02:45:02 <esolangs> [[9]] https://esolangs.org/w/index.php?diff=144634&oldid=144633 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (-2) /* Transforming this into 90 */
02:45:16 <esolangs> [[9]] https://esolangs.org/w/index.php?diff=144635&oldid=144634 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+0) /* Transforming this into 90 */
02:46:01 <ais523> I am not sure why you would need a macro system for 90?
02:46:34 <ais523> unlike most languages, it is not going to let you make more powerful programs
02:49:53 <esolangs> [[9]] https://esolangs.org/w/index.php?diff=144636&oldid=144635 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+197) /* Example Program */
02:51:31 <Lymia> Tweaked traditional (of the scoring methods on zemhill) seems "good enough" thinking about it.
02:52:16 <Lymia> I wonder why it punishes ash so hard?
02:52:47 <ais523> ash draws a lot, and has many incredibly narrow wins
02:52:48 <Lymia> (... why the FUCK does lugh go to #4 on iterative traditional)
02:53:14 <esolangs> [[PythOwO]] M https://esolangs.org/w/index.php?diff=144637&oldid=144626 * RaiseAfloppaFan3925 * (+124) TwT i forgot that <code>input</code> is actually <code>inpwt</code> also that one true was supposed to be twue
02:53:18 <ais523> markov scoring lets it exploit the incredibly narrow wins to shoot up the hill, most scoring methods don't let it do that
02:56:16 <ais523> fwiw, even traditional scoring breaks with a bot that beats everything – you can clear the hill by submitting the bot multiple times
02:56:28 <ais523> (an exploit which IIRC was actualy used once)
02:56:39 <Lymia> That exploits hill size rather than the scoring though.
02:57:06 <ais523> it's been a while since we had an omni-winner
02:57:19 <Lymia> I can put one on the hill right now if I can dig out the code.
02:57:35 <ais523> the most recent handwritten may have been omnipotence, and that was special-cased to beat two bots it couldn't beat otherwise
02:57:50 <Lymia> Do you think it's still possible?
02:58:01 <ais523> handwritten without special cases? yes but very difficult
02:58:22 <Lymia> IIRC nyuroki2 came close, but still was a few bots short.
02:58:33 <ais523> impatience is very close, but has a clear weakness that will be very difficult to fix
02:58:47 <ais523> and, well, it wouldn't really be the same program if you fixed it
02:58:54 <Lymia> (Open question is: Should narrow wins count for as much as they do in Markov?)
02:59:16 <ais523> I like margins-ish programs too much, so for me, yes – I'm not sure whether it's healthy, though
02:59:29 <Lymia> Yes, but with the provision that the wins aren't unstable to mild tuning.
02:59:32 <ais523> if a program always wins tape length 10 and draws everything else, shoud it be a top winner?
02:59:40 <ais523> yes, assuming stability
02:59:50 <Lymia> Yeah, that's also my thought.
03:00:07 <ais523> ooh, I just realised you could probably control for stability – delay programs by 1, 2, 3, etc. cycles before starting and see if the result is still the same
03:00:14 <Lymia> I was thinking the exact same thing.
03:00:22 <Lymia> This was the thought process that led to it, though.
03:00:32 <Lymia> Oh, well, no, that idea is different.
03:00:44 <Lymia> Mine was just adding the delayed programs as "configurations".
03:00:53 <Lymia> Similar to tape length + polarity.
03:01:09 <Lymia> cycle advantage -2,-1,0,1,2
03:01:13 <ais523> well, even if not identical, the ideas are pretty similar
03:01:41 <ais523> I feel like your omniwinner program could probably detect cycle advantage too, though?
03:01:55 <ais523> there would be more cases to check but it would still conceptually work the same way
03:02:41 <ais523> interestingly, there are a couple of matches on the hill which come down to a few cycles in a flag race, but consistently (the same program always wins by a few cycles even if you change the tape length)
03:02:58 <ais523> I forget exactly which matches it is, but IIRC (and I might not have done!) one of quintopia's programs was involved
03:03:20 <ais523> so despite being close in terms of flag timing, they aren't close in terms of match results
03:04:12 <ais523> oh, this reminds me, I also thought of a way to detect near-duplicate programs: you take the match result against each opponent and configuration, and also the length of time the result took to achieve
03:04:28 <ais523> and two programs are considered similar if the results and time-to-results are similar
03:06:34 <Lymia> Oh, length as a side channel is pretty clever.
03:06:41 <ais523> hills could perhaps use that as a method of preventing multiple similar programs coexisting on the hill (if two programs are similar you keep only the one that has better scores against other programs, ignoring the head-to-head matchup)
03:07:27 <Lymia> Cycle advantage can also be negated by synchronization.
03:07:39 <ais523> one nice thing about length-to-victory is that a) it's rather correlated with strategy and b) it makes it possible to tell two programs apart even if they both beat most of the field
03:07:41 <Lymia> But I imagine that falls apart on very short tapes.
03:08:29 <Lymia> Another possible "stability" thing.
03:08:41 <Lymia> Adjust the flag height -10, -5, 0, 5, 10 or something.
03:09:11 <Lymia> No, just generally for stablizing timings.
03:09:30 <Lymia> It's mostly relevant for flag defenders now that I think about it.
03:09:40 <ais523> that is going to have a disproportionate impact on vibrators and turtles, and a randomizing effect mostly only on flag-defenders
03:10:00 <Lymia> (An extreme configuration option may also be cell size)
03:10:06 <Lymia> (256, 254, 252, 250)
03:10:22 <Lymia> (But I think this screws up existing programs far too much to be viable.)
03:10:24 <ais523> lots of locks and shudders are critically dependent on cell size
03:10:53 <ais523> 256 being a power of 2 has major strategic implications, defensive programs could look quite different in height-255 BF Joust, for example
03:11:11 <ais523> it doesn't matter so much for attackers, except when they're trying to beat defenders
03:11:29 <Lymia> Do you think synchronization+tripwires would negate the stability from cycle advantage as a configuration too much?
03:11:57 <ais523> no – constantly checked tripwires are a thing occasionally, but they're rare
03:12:24 <ais523> cycle advantage can change the probability of sneaking past an occasionally checked tripwire
03:12:26 <Lymia> Yeah, that makes sense.
03:12:42 <Lymia> I might experiment with introducing cycle advantage and see what the matchups look like.
03:12:44 <ais523> also, tripwires are more commonly behind the lock cell than in front nowadays
03:12:46 <Lymia> What'd be a good test bot there?
03:14:05 <ais523> it has a lot of timing-dependent matchups, but is designed so that they mostly average out – lots of matches have a 25% win rate and 75% draw rate, normally with the wins showing up on alternate tape lengths of one polarity because that's what hits the timing that lets it win
03:14:24 <ais523> and a tripwire behind the lock cell, although it isn't checked very often
03:15:00 <ais523> omnipotence is also interesting for this sort of thing because it's an entirely unsynchronized defence program, the only time it reads the tape is during the poke
03:15:58 <Lymia> -3 to 3 might be a good range as well.
03:16:28 <ais523> mist is probably also somewhat timing-dependent in some matchups, although I'm less familiar with how it works
03:16:48 <ais523> although mist *does* have a constantly checked tripwire
03:16:55 <Lymia> The bots I've made should be fairly timing resiliant, since... they don't really use precise/etc mechanisms.
03:17:06 <Lymia> I'm not great at that kinda coding.
03:17:18 <Lymia> (Would like to try and make a defense bot at some point, but. Haven't yet.)
03:17:21 <ais523> although I'm OK at that kind-of coding I kind-of hate doing it
03:17:53 <ais523> anticipation2 has fallen off the hill, that was something of an extreme example in precise timing measurement with tripwires
03:18:45 <Lymia> Wait, it actually got killed?
03:18:47 <Lymia> Did not expect that.
03:19:09 <Lymia> !ztest anticipation2 http://ais523.me.uk/esolangs/bfjoust/codu-archive/fb826add7501-ais523_anticipation2.txt
03:19:09 <zemhill> Lymia.anticipation2: points -4.40, score 15.12, rank 40/47
03:19:19 <Lymia> Geez, it holds up worse than I thought.
03:19:35 <ais523> it is over 10 years old at this point
03:19:58 <ais523> although, so is omnipotence and it is surviving much better
03:20:26 <ais523> anticipation2 can be easily beaten using an anti-vibration loop that's a timer clear, and its strategy has no way to avoid that
03:20:40 <ais523> (although, people normally don't put timer clears in their anti-vibration loops)
03:21:47 <ais523> amusingly, it also lost to the sample program because it needs the opponent to have at least one of anti-shudder, a wiggle, or an offset, otherwise it leaves cells faster than it's possible to detect
03:23:08 <ais523> oh, also its "backup" defence strategy only works against integer-speed clear loops, and I have been consistently using non-integer clear loops against programs detected as defence programs for many years now
03:24:27 <Lymia> non-integer clear loops?
03:24:54 <ais523> my current standard is [-[+.++]]
03:24:59 <ais523> this adjusts the cell by 3 every 5 cycles
03:25:31 <ais523> will zero a cell eventually if the opponent isn't there, and typically even if the opponent is there
03:25:51 <Lymia> I've been relying more on 7-cycle clears, on the theory that it's the prime number that's one too high and too ridicilous for defense programs to try.
03:25:56 <ais523> also 129 is divisible by 3 so this will zero an unattended flag the first time through
03:26:18 <ais523> (assuming it didn't get adjusted to stop turtles)
03:27:50 <ais523> I feel like it's important to have an anti-shudder that can always clear an unattended cell – sometimes programs end up in their antishudder by mistake (e.g. due to clearing a cell while the opponent is setting a decoy in it) and it's very embarrassing if they end up locking themselves on a cell that the opponent is leaving unchanged
03:28:08 <ais523> which rules out the old-fashioned +--+ (which I'm not sure ever worked particularly well)
03:29:36 <Lymia> Yeah, that makes sense.
03:29:57 <Lymia> I think this should be incontrovertial when it comes to BFJoust scoring, though:
03:30:49 <Lymia> Should winning +42 games be twice as valuable as winning +21
03:31:00 <Lymia> ... and I think the answer is "no".
03:31:08 <ais523> I also think the answer is no
03:31:59 <ais523> one big advantage of the Markov hill is that it makes it more valuable to try to shift the breakpoint in cases where one program wins short tapes and the other wins long tapes
03:32:25 <ais523> like, one program is winning tape lengths from 18 upwards, that's much better than winning tape lengths from 22 upwards
03:32:40 <ais523> but that's a relatively small difference in terms of absolute score
03:34:00 <ais523> nyuroki is particularly affected by this when playing against poke programs – against a good poke program it can't consistently win on the entire range of tape lengths, but that's OK because it can win large enough subsets of tape lengths in the ranges that are favourable to it
03:34:38 <ais523> if the range of tape lengths were expanded, then the pokes would become better relative to nyuroki because they generally win the very long tapes
03:36:23 <ais523> (I should clarify here to pokes that use the poke to set more decoys on large tapes, as opposed to pokes like lugh which set the same number of decoys regardless of poke distance)
03:42:13 <Lymia> Main problem with tape count is that it does break a lot of existing programs.
03:42:27 <Lymia> e.g. nyuroki's codegen uses tape length as an end point to make the program length, uh. Reasonable.
03:42:51 <ais523> some of my older programs have a special case to never go beyond tape length 30 regardless of circumstances
03:43:18 <ais523> in theory impatience would be slightly improved by adding that special case, although most of my other programs can't go beyond the opponent's flag anyway
03:43:53 <ais523> and "lock and full-tape clear" strategies naturally end at a particular tape length rather than continuing to clear forever
03:43:59 <Lymia> (I wonder if a smaller minimum tape would be nice as well, though. Something like 5-40)
03:44:11 <Lymia> (It'd probably change the game too much.)
03:44:20 <ais523> I have been seriously considering 8-32 for my Lua Joust-inspired BF Joust derivative
03:44:49 <ais523> I think changing the low end matters more than changing the high end, but I don't want to make early rush even weaker than it already is, so giving it a few more short tapes to play with may help
03:45:31 <ais523> this has the advantage of a) being nice round powers of 2 and b) meaning there are 50 matches in a set, meaning that the score of one bot against another can be expressed as an integer percentage (e.g. 49 losses and 1 tie is a 1% win rate, treating draws as half a win)
03:47:20 <ais523> I have the derivative mostly designed in broad details (you get one unbounded counter, and one marker you can set on a tape cell you've been to – you can test counter value, distance from marker, or distance from own flag in zero time, and set marker or change counter in zero time, plus the usual wait/move/adjust/test commands that take a cycle – apart from that you have a finite state machine but limited space)
03:48:34 <ais523> and am currently planning to make it a 2D language in which tests turn 90° for "different value" or go on straight for "same value", but programs have to be written in a fairly small playfield and don't get abbreviations
03:49:42 <ais523> most of the standard BF Joust tactics can be written in this without abbrevations – it's sufficient for pokes, defensive locks with full tape clears, timer clears, anticipation-like synchronization, etc., but without being TC
03:50:17 <ais523> (in fact, it has decidable halting, which would make it possible to run an "infinitely long match" or to determine whether a match was locked up and doesn't need to be simulated out to the cycle limit)
03:50:36 <ais523> ah, "deadlock" is the term I was looking for, I think
03:51:05 <Lymia> On the generation side, it'd be amendable to gradient descent probably, which.... interesting.
03:51:06 <ais523> it's also sufficient to write nyuroki without the macro system, assuming there's room for three clear loops (and there should be)
03:51:47 <Lymia> I'd consider if there's a good alternative to the 2D aspect, just for reasons of "not making coding bots too difficult".
03:52:05 <ais523> well I was thinking about making a GUI
03:52:46 <ais523> leaning into the computer-game-like aspects of BF Joust a bit more, maybe even making a game that people outside the esolang community might want to play
03:52:56 <ais523> I am probably overly ambitious :-D
03:53:36 <ais523> still, I have fun thinking about what the ideal would look like even if I'm unlikely to find time to program it
03:53:42 <Lymia> I'd actually consider a fairly large playfield, fwiw.
03:53:49 <Lymia> Fairly large relative to a reasonable screen size, anyway.
03:54:17 <ais523> I think ¼ of the screen is about right, and have mostly been wondering what size the cells should be to make that work
03:54:39 <ais523> that way, you would be able to have a game viewer which showed the bots' thinking in the bottom-left and bottom-right, and the tape at the top
03:55:04 <ais523> complete with cartoonish blindfolded robots desperately feeling around for flags
03:55:34 <Lymia> My reasoning here is that... it's only recently been that we've had most major bots use some kinda of repetition/codegen to make up for BF's ... inadequacy in expressiveness.
03:55:34 <ais523> ¼ here being half horizontally and half vertically
03:56:14 <Lymia> So, likely BFJoust's "very high level" (as in, future hills) expressiveness is much higher than the simple to descirbe but technically long bots we have right now.
03:56:39 <Lymia> So some wiggle room for complex strategies that are mainly possible using more powerful control flow seems like a good idea.
03:56:49 <Lymia> 100x100 or so, maybe.
03:56:51 <ais523> my main concern with Lua Joust is that it's too easy to make programs act unpredictably and kill off most defensive programs
03:57:24 <Lymia> (Maybe even lean into the problem being the lack of a crossover operation rather than bounded playfield size?)
03:57:45 <ais523> I was planning to allow crossovers, and banning them probably won't do what you want
03:58:04 <ais523> people would be able to duplicate parts of the program using the extra space, for example
03:58:34 <ais523> I feel like lock-based defense is in serious trouble at the moment because it is too easy to break the locks
03:58:49 <Lymia> I'm not sure it can be reasonably preserved even in 2D.
04:00:01 <ais523> well, one of my goals defining this language was to help make a lock-and-full-tape-clear concise to write, so that you could write it even if you had a small space, whereas flexible timer clears are not easy to write in this subset and take a lot more space
04:00:25 <ais523> you can do inflexible timer clears just fine, but that may leave an exploitable window, etc.
04:01:55 <Lymia> Is the key point of a flexible timer clear its early return?
04:02:01 <ais523> looking for lock-and-clear-based programs on the current scoreboard (as opposed to other styles of defense), the top scorers are omnipotence at 13 and quicklock at 23 (preparation is at 16 but it abandons the lock to attack, as it doesn't have enough free cycles in the lock to reach the far end of the tape)
04:02:31 <ais523> there are a few things it can do over an inflexible timer clear, although some of them are BF-specific advantages
04:02:56 <ais523> but a big one is that you can vary the clear loop details from cell to cell, meaning that it's pointless for opponents to try to learn how your clear loop works and take advantage of that
04:03:28 <ais523> for example, impatience's timer gets longer and offset gets smaller as it clears more cells
04:03:57 <Lymia> Fwiw, Nyuroki doesn't really vary from clear to clear (in a significant way), it just says "you have to special case or die".
04:04:54 <ais523> when I discovered the flexible timer clear I thought BF Joust was dead, in that it would invalidate all defensive strategies
04:05:00 <Lymia> The heart of it is that it tries a 2-cycle for 2000 cycles, then switches to a 7-cycle anti-vibration clear. If it observes zero two times, it bails. This should be very brief in the 2D language, and leave plenty of room for more complexity.
04:05:06 <ais523> it turns out it didn't, but it has made traditional locks mostly obsolete
04:05:21 <ais523> yes, Nyuroki is the sort of thing I wanted to allow
04:05:26 <Lymia> I may not fully understand flexible clear. Is it just about changing the details of the clear from cell to cell?
04:06:26 <ais523> the major difference from inflexible is that you are in a different section of the program from one cell to the next, meaning that you can do all the usual fanciness like checking if a cell is 0 before offsetting it, and that also lets you change whatever details you like from one cell to the next
04:06:56 <Lymia> So Nyuroki uses the same structure, but doesn't exploit the full nastiness possible.
04:07:15 <ais523> anticipation2 was designed to exploit the inflexibility of inflexible timer clears by learning the offset and cycle length and locking them in the antivibration (or tricking them off the tape)
04:07:35 <Lymia> For what it's worth, if the problem is changing the details of cycle, you could just...
04:07:40 <ais523> but against a flexible timer clear that doesn't work
04:07:40 <Lymia> Make 3 clear cycles, then loop them.
04:07:56 <Lymia> It's more brief than a flexible timer clear but has a similar effect.
04:08:00 <ais523> yes – this sort of thing is why I wanted limited space
04:08:13 <ais523> so you'd have to choose between that, and, e.g., a full set of short-tape special cases
04:08:42 <ais523> I can even imagine different "weight categories" of bots that have different bounding box sizes for the progra
04:10:05 <Lymia> (Nyuroki uses the "open slot" for complex code flow without exponential code size to do a forcable early return rather than a flexible timer clear, basically.)
04:10:28 <Lymia> (I don't believe but could be wrong that its code structure is not amendable to being combined with a flexible timer clear.)
04:10:36 <Lymia> (I believe but could be wrong*)
04:10:56 <Lymia> I'd have to see that to know what I think of it overall, honestly.
04:11:35 <Lymia> I'd maybe just mostly advise that the "recommended" playfield size be on the order of maybe 1.5x-2.5x the code size needed to express the largest (fair) bot high on the hill.
04:11:56 <ais523> I'm inclined to agree but am not sure what you mean by "fair"?
04:12:04 <Lymia> Bot that isn't using its code size maliciously.
04:12:17 <Lymia> (for some subjective definition of "stuff that could invalidate strategies entirely")
04:12:21 <ais523> ah, so not full of special cases or the like
04:12:41 <ais523> fwiw, I feel like program size has been dropping dramatically recently
04:12:59 <Lymia> The Kolmogorov complexity faster than the program size, I'm sure.
04:13:07 <ais523> ash and impatience were both written with no code generation / editing tools other than copy-and-paste and find-and-replace
04:14:23 <ais523> out of the last 8 winners, 2 are IRC one-liners, which seems quite close to the historical proportion past the early days
04:14:37 <Lymia> Was probably mostly defense that was breaching it.
04:15:02 <Lymia> I use code generation mainly for the sake of being able to easily iterate on bots that have the same "behavior" repeated in lots of places.
04:15:11 <Lymia> Rather than to generate bots that would be impractical to write by hand one way or another.
04:15:37 <ais523> my code-generated bots generally use repetition for different poke lengths or measured timings
04:17:57 <Lymia> (I've never really seen the point to a true flexible timer clear, for what it's worth, maybe because there's enough other tactics that kill the lock-and-clear kind of bot.)
04:18:22 <Lymia> (Since using the best possible timer clear whenever possible is obviously a very good approach vs anything that isn't a lock.)
04:18:30 <Lymia> (And varying it just for the sake of varying it could just result in you being too slow.)
04:18:49 <ais523> oh, the other really big advantage to flexible is that the timer resets with every cell
04:19:13 <ais523> with inflexible, it's shared between all the cells, so you have to have a very long timer in order to ensure that you don't switch strategy while you aren't actually being locked
04:22:56 <ais523> but no, I agree – inflexible is usually good enough and it's what I use in most of my programs, unless I need a flexible timer clear for some reason (e.g. impatience doesn't work without one)
04:23:09 <Lymia> Nyuroki has a single one of the "flexible clear features" used on purpose then, namely resetting the timer.
04:23:22 <Lymia> But it doesn't do anything else because... uh. The clear loop works.
04:23:25 <Lymia> Why change it. -w-
04:23:47 <Lymia> The 2D approach (or something simliar in 1D with very limited program size?) makes sense for specifically punishing very different clear loops.
04:23:53 <Lymia> Rather than ones that are somewhat advanced in normal BF Joust.
04:23:57 <ais523> I feel like the ability to change up the clear loop is mostly important against theoretical anti-defence programs, rather than actual ones
04:24:14 <ais523> err, theoretical defence programs
04:24:38 <ais523> basically only anticipation/anticipation2 ever tried anything to exploit inflexible timers and I don't think they did it very effectively
04:30:22 <Lymia> I overall like the idea here.
04:30:43 <Lymia> Thinking through programs I've analyzed/wrote, it's specifically punishing Kolmogorov complexity rather than advanced tactics, per se.
04:31:43 <Lymia> It also has a easy story for why only certain operations "pass the turn" (per se): they affect the shared tape.
04:32:04 <Lymia> It's especially punishing for special cases, which...
04:34:36 <Lymia> I'll probably still write an auto-router that turns text-based code into warriors, but that's because personal preferences at work, rather than "needed due to flaws in the underlying system".
04:40:33 <Lymia> I get what you mean with state machine earlier too. Program size scales with number of "distinct behaviors" effectively, which... is a good property.
04:49:38 <Lymia> ais523: hmm. I think that once you get past the idea that a defense program can 100% beat any "reasonable" offense, the motive to do "theoretically sound" defenses like anticipation/anticipation2 represented goes down, and the probabilistic approaches to e.g. defense look a lot more attractive.
04:50:07 <Lymia> And once you start looking into those, the possible design space explodes.
04:51:13 <Lymia> There's stuff that died, sure, but it seems the more the meta "develops" right now, the more rock paper scissors triangles start revealing themselves.
04:52:12 <Lymia> The silver bullets don't exist. So, structurally killing off special casing seems a win.
04:54:12 <ais523> BF Joust has more of a sweeper-wall tangle than a rock-paper-scissors triangle, but that's probably to its advantage – competitive Pokémon's sweeper-wall relationship is one of the best things about that game
04:55:00 <ais523> (in Pokémon, physical walls beat physical sweepers which beat mixed walls which beat mixed sweepers; if two sweepers fight the faster wins, if two walls fight things get weird and it can take a while)
04:55:28 <ais523> but if the sweepers start fighting over speed to beat each other they become less good at fighting the walls, where speed doesn't matter
04:55:45 <ais523> this is surprisingly reminiscent of BF Joust, although the concepts don't match up exactly
04:56:51 <ais523> this is by far not the only generalised rock-paper-scissors relationship in Pokémon, which is a game completely full of them, but it's the most interesting IMO
04:56:59 <Lymia> (In Pokemon, the most defensive teams also run a single one of the nastiest wallbreaker they can find, lol. Which is also reminicent of BF Joust)
04:58:20 <ais523> yes – although back when I played, my anti-stall Pokémon was often a wall tuned to beat other walls rather than an offensive wallbreaker
04:59:21 <Lymia> would be nice if one existed right now. v.v;
04:59:56 <ais523> I like exploiting opponents using predictable teambuilding – I got a lot of wins back in generation 4 by running both Flamethrower and Ice Beam on Blissey
05:00:22 <ais523> because many of the most common Blissey switchins were 4× weak to one of those moves and would get OHKOed
05:00:55 <ais523> once you'd OHKOed them, the opponents generally assumed they could get a setup turn with the other, because no ways Blissey is running *both* of the elemental offensive moves, right?
05:01:58 <ais523> sometimes I ran this together with Psych Up, which is not theoretically correct but was hilarious and came up surprisingly often (Calm Mind is a better alternative for the same slot, though, being almost as good in most of those cases and better in general)
05:03:49 <Lymia> Tbh, the most exploitable thing right now is the near-total lack of mixed attackers.
05:04:37 <ais523> I went and had a look at the early SV meta, which was amazingly broken in a lot of different ways, but haven't had a look at it now that it's settled down
05:05:03 <Lymia> Iron Valiant is the only mixed attacker in OU.
05:05:18 <ais523> but that's a good point, I can't think of good Pokémon that are able to run mixed sets (there are some that can run either physical or special but generally have reasons why you can't mix them)
05:06:17 <ais523> I should at least check the banlist to see what sort of wreckage Game Freak's lack of balancing for singles left behind
05:06:42 <Lymia> If you want to go stall, Clodsire+Corviknight alone can mess up half the meta, lol.
05:17:02 <Lymia> git pull on zemhill is going to take forever isn't it
05:20:23 <ais523> it depends on how often you do it – but git does have techniques for accelerating pulls of repos that haven't been pulled for ages
05:20:37 <ais523> it doesn't have to download the commits one at a time, so cloning an old repository isn't as bad as it might seem
05:24:02 <zzo38> I would want to implement a pokemon battle simulator in C, as a library that can be called by another program; with help from others too hopefully
05:29:54 <Lymia> ais523: https://dl.rimin.moe/paste/lymia/results-with-delay_0qx9bjg2nrfrksx19shgam347w5n0hhjriqgdhafpxd9spkghygx.txt
05:30:04 <Lymia> Here's a raw dump of results on current zemhill with the delay configuration added.
05:30:12 <zzo38> I had also written about pokemon (and some other games) in a subpage in esolang wiki, hopefully you know if the brief description is good enough
05:33:27 <Lymia> Definitely feels like a continuation of the same matchup set, but more resiliant against timing weirdness.
05:34:29 <ais523> the delay seems to mostly not matter with most programs, which is what I'd expect
05:34:58 <Lymia> Seems worth it for the ones where it is, at least.
05:35:03 <ais523> finnel versus synanceia is a clear pattern of timing mattering – it changes the single-game results but doesn't significantly change the match results
05:35:49 <ais523> rowdy versus quicklock has some significant score differences based on timing details, though
05:36:12 <ais523> rowdy versus growth2, too
05:36:56 <Lymia> Yeah, some bots seem more vulnerable to it than others.
05:37:01 <ais523> oddly with that one, some delay-polarities are more drawish, and some are less drawish but who wins depends on polarity
05:37:48 <Lymia> It does look like an overall good change just eyeing it.
05:38:01 <Lymia> A good 5-10% of the matches seem impacted enough that this reduces the amount finetuning matters.
05:38:37 <Lymia> ais523.slowpoke.bfjoust vs web.ais523_ash.bfjoust
05:39:08 <ais523> lugh versus margins3 seems to be one where it has a significant impact on the match result
05:39:37 <ais523> lugh is always winning but there are significant differences in the margin
05:40:01 <Lymia> There's in fact the odd-even patterns I expected.
05:40:07 <Lymia> Which may make it worth it to extend to -3 to 3.
05:40:34 <ais523> margins3 is primarily a shudder program, it makes sense that that is timing-dependent
05:41:07 <Lymia> Good timing "poliarity" gets you 4/7 advantagous positions instead of 3/5.
05:41:13 <Lymia> Slightly more consistent.
05:41:16 <ais523> oh, lugh versus Sookie is interesting, lugh wins almost 100% of the time on one delay but more like 50% on the other 4
05:41:55 <ais523> this makes sense because the Sookie lock (which inspired ash's, which has the same property) is probabilistic and breaks 25% of the time against 2-cycle clears
05:43:15 <Lymia> https://dl.rimin.moe/paste/lymia/results-with-delay_1pw1k76cw0kwih3ckljqlya15awyjk7bdfsbzlnbfi3z23wq99rx.txt
05:43:36 <ais523> meanwhile, quicklock is very stable to this disruption because it has a timing tripwire – the only significant changes are against a passive defender, which make it leave its tripwire
05:43:36 <Lymia> Does help the Sookie matchup be more consistent.
05:43:44 <Lymia> 2/7 rather than 1/5.
05:44:33 <ais523> I think this was a worthwhile experiment – the results are not surprising, but that's usual with experiments
05:44:58 <Lymia> I'd call this on the edge of worth implementing, tbh.
05:45:08 <ais523> OK, a super-significant difference: hippo_ballerina versus synanceia
05:45:39 <ais523> synanceia always wins short tapes, and delay parity makes the difference between the longer tapes being hippo_ballerina wins or draws
05:46:13 <ais523> so it changes the match winner, and there's a difference of 34 points between the two delay parities
05:46:23 <Lymia> I wonder if it'd be worth it to do this, and *delete* the 0 polarity difference.
05:46:50 <Lymia> I wish there was a way to make this 50/50
05:46:52 <Lymia> In cases where it matters.
05:47:25 <ais523> impatience versus jackal2 is intriguing, it looks kind-of like on tape length 12, that one cycle is determining a flag race
05:47:34 <ais523> I should check that game in the breakdown
05:48:50 <ais523> ⚐2 <00 03 0A 09 02 FF FD FF FD 00 00 >00 ⚐2 (impatience, versus jackal2 delayed 1 cycle)
05:49:06 <ais523> on polarity-inverted tape length 12
05:51:16 <ais523> impatience versus xurtle looks similar, but your results for that don't match egojsout's, one of them must be parsing one of the programs differently
05:55:08 <Lymia> Running a test hill with a basic scoring.
05:55:16 <Lymia> ais523: this is a modified gearlance.
05:55:28 <ais523> monolith versus atom is weird
05:56:10 <ais523> it looks vaguely period-3-ish but doesn't repeat exactly
05:59:43 <ais523> omnipotence versus optimism is a very significant exact period-3, which makes some amount of sense because omnipotence has an unsynchronized lock
05:59:47 <Lymia> https://dl.rimin.moe/paste/lymia/results-with-delay_1z77xhrpdx4hx211njfl4cfczafzcs8gmh6cp2fisa55rcds7w6y.txt
05:59:53 <Lymia> Here's a complete dump with a score chart at the very bottom.
06:00:33 <Lymia> (first number is score with delays, second number is score without delays)
06:01:34 <Lymia> Some significant winners and losers: space_hotel gains a lot. slag loses a bit. omnipotence and margins 3 wins a bit. preparation gets a massive buff.
06:02:20 <ais523> omnipotence versus MV has some "a program falls off the tape on the second cycle of its opponent's flag being zero" cases, which both egojsout and gearlance treat as draws
06:03:02 <Lymia> (So, I do use gearlance here, but I can't guarentee identical behavior)
06:03:15 <Lymia> (Since it does have some small fixes, and it's modified for reentrancy)
06:03:21 <Lymia> (And generally being hooked up to Rust code.)
06:03:53 <Lymia> If I were making a new hill, I'd consider this worth implementing as an additional "dimension" anyway.
06:04:26 <ais523> I will consider it if I implement my new version
06:05:16 <ais523> I am wondering if preparation doing much better is a consequence of people (perhaps unintentionally) constant-tweaking against it – the notable thing about that program is that it's critically dependent on a probabilistic lock
06:05:17 <Lymia> It makes timing-dependent matchups closer to a tie.
06:05:29 <ais523> so most of its matchups are somewhat timing-dependent
06:05:38 <Lymia> (or, rather, the stable point.)
06:05:43 <ais523> the extra dimension throws off the tweaking
06:05:51 -!- Sgeo has quit (Read error: Connection reset by peer).
06:06:42 <Lymia> So, here's a fun thing: You could probably score wins that aren't stable to timing as less valuable.
06:06:47 <ais523> oh, preparation versus Sookie is one of the largest differences, and I did have some suspicion that Sookie was overfitted
06:07:42 <Lymia> Eeh. I don't think that'd help. Just punishes timing dependant bots.
06:08:09 <ais523> slowpoke versus ash is very weird
06:08:30 <ais523> might need more than 7 runs of that to figure out the pattern
06:09:59 <Lymia> salpynx.nana.bfjoust vs salpynx.synanceia.bfjoust??
06:10:02 <Lymia> Are those two copies?
06:11:39 <ais523> they're significantly different, synanceia is the most timing-unstable program on the hill
06:11:47 <ais523> whereas nana is a lot more stable
06:13:15 <Lymia> (I think for a hill that uses this configuration method)
06:13:27 <Lymia> (Rather than the >>> <<< as the default display for detailed matchup information)
06:13:42 <Lymia> (Instead a heatmap of how often the program wins on each tape length, with a button to click it for more details)
06:13:49 <Lymia> (fold polarity into the W/L from delays.)
06:14:01 <ais523> space_hotel versus Sookie is pretty
06:14:35 <esolangs> [[S.B.M.F.B]] https://esolangs.org/w/index.php?diff=144638&oldid=144598 * Ractangle * (-241) /* Examples */
06:14:41 <Lymia> That matchup's a mess lol
06:14:59 <ais523> I suspected Sookie would be fairly unstable, I'm looking at its matches now
06:15:09 <ais523> (it's a little inconvenient because it comes last alphabetically)
06:17:16 <ais523> I don't think growth2 actually benefits much from the delay compensation, it does well regardless in traditional scoring
06:17:29 <Lymia> Sookie gets detroyed scorewise.
06:17:32 <Lymia> Definitely overfitted.
06:19:12 <ais523> heh, Sookie turns out to be on a bad timing against rowdy, but rowdy was submitted after it was so that makes sense
06:19:39 <Lymia> ouch, that also gets wrecked.
06:19:48 <ais523> it's on a good timing against lugh, that might be part of what causes it to lose points when compensating for timing
06:20:16 <ais523> a good timing against margins (the original), too
06:21:01 <Lymia> Tbh, this does seem to help the bots that (from what I've seen of them) deserve to be helped. And in general, bring some life to defensive bots (afaik, what the bots do)
06:21:13 <Lymia> And nuke overfitted stuff lol.
06:21:14 <ais523> slowpoke seems to be the most unstable of the Sookie matchups I've checked so far
06:21:30 <ais523> well, you're just giving them another dimension to overfit in :-)
06:21:57 <Lymia> It should make overfitting harder unless people somehow manage to detect delay though, lol.
06:22:16 <Lymia> Kinda like polarity.
06:23:16 <ais523> meanwhile, unstable_atom seems to be more stable than salpynx probably intended
06:23:43 <ais523> only a few of its matchups change significantly – one of those is against omnipotence, but it was submitted with a bad timing for that matchup, which is the opposite of overfitting
06:23:56 <esolangs> [[Esolang:Sandbox]] https://esolangs.org/w/index.php?diff=144639&oldid=144529 * Iddi01 * (+2748) T H E. C R A Z I E S T. T E S T. I N. H I S T O R Y. A N D. F O R E V E R. W I L L. B E.
06:24:02 <Lymia> This does feel like a natural extension to polarity. Tuning for timings vs bots is something people do, and this makes that tuning less important.
06:24:45 <ais523> hmm, now I am wondering what happens if, instead of delaying at the start, you delay the first time the programs are on the same cell (or cross each other)
06:25:02 <Lymia> Would be a lot harder to implement.
06:25:14 <Lymia> Since right now, the delay is just adding "..."
06:25:18 <ais523> that mathematically can't make any difference to delaying at the start, can it? :-D
06:25:36 <Lymia> Only in narrow edge cases, I think.
06:25:41 <Lymia> I did consider a "rolling" delay.
06:25:45 <esolangs> [[Esolang:Sandbox]] M https://esolangs.org/w/index.php?diff=144640&oldid=144639 * Iddi01 * (-2747) Let's see if the reverted tag shows up
06:25:55 <Lymia> Where each program pauses once each 100 (or so) cycles at different timings.
06:26:02 <ais523> neutrino versus unstable_atom appears to be a flag race where the delay cycles matter
06:26:08 <Lymia> But that might fuck up existing defense something serious.
06:26:20 <ais523> although only on high odd tape lengths and only on one polarity
06:27:40 <ais523> ooh, feature idea: distinguish between a draw (when the programs deadlock and time out) and a tie (when the programs both actively reach a victory condition simultaneously)
06:28:15 <ais523> ties are generally interesting, or at least exciting to watch, and it would be good to have an easy way to spot them on the breakdown
06:28:20 <ais523> even if you'd score them the same way
06:29:05 <ais523> (I can also see an argument for weighting points by the number of non-drawn games, i.e. only counting the games that finish on time, but if you did that tied games would still count)
06:30:00 <Lymia> Tbh, I am somewhat considering putting up an alternative hill to zemhill, with rules changes like this.
06:30:04 <ais523> cupnoodles versus unstable atom is a tie on tape length 10
06:30:19 <salpynx> yeah, the current synanceia is doing the over fitted instability i was aiming for with unstable_atom. I was happy with the -8 swing i saw on syn earlier. Sookie, and i think hippo_ballerina are others i noticed that would swing significantly up and down
06:30:30 <ais523> but random ties on, say, 26 would be much more interesting
06:30:45 <Lymia> I can set up the framework for that, tbh.
06:30:51 <Lymia> Tracing cycle count is basically free.
06:30:57 <Lymia> And getting more information out of it is also basically free.
06:31:13 <ais523> IIRC hippo_ballerina's strategy doesn't make much sense, I was just randomly combining strategies until I found something that would stick on the hill
06:31:51 <Lymia> That is also kinda what Nyuroki does, but that's clearly pretty stable on the hill.
06:32:10 <Lymia> I imagine hippo is...
06:32:13 <salpynx> that is kinda the space i have been exploring too :)
06:32:17 <Lymia> More just lots of special cases?
06:33:03 <ais523> I don't think it's special cases, but I also can't remember how it works
06:33:25 <Lymia> Hmm. Imma think about alternative scoring systems later.
06:33:31 <Lymia> I think... overall I prefer traditional over markov.
06:33:35 <Lymia> But could maybe improve on both.
06:34:49 <ais523> it looks like – stealth clear, when you find a large decoy set decoys behind you, inflexible timer clear
06:35:08 <Lymia> Is there a compelling reason to treat "total wins over bot" as distinct from "total score vs bot"?
06:35:26 <Lymia> That is, make it so that going 21-21-0 is different from going 0-0-42?
06:37:13 <Lymia> I don't feel like there's a good reason to treat tying twice as different from winning once and losing once. If it was originally meant to nerf defense, well, uh.
06:37:19 <Lymia> Defense is clearly not what needs a nerf.
06:37:23 <ais523> I can see an argument that, say, 5-0-5 should be treated as more than half as valuable as 10-0-0
06:38:00 <ais523> or, well, 8-0-8 as worth more than 12-4-0
06:38:00 <Lymia> It'd be more like 10-0-10 vs 15-5-0, right?
06:38:54 <ais523> it conceptually feels like preventing a program ever beating you, and beating it sometimes, is a fairly dominating performance
06:39:18 <Lymia> Mathemtically hard to represent, though.
06:39:28 <Lymia> Except maybe by completely omitting ties/timeouts from the calculation.
06:39:41 <Lymia> i.e. ties revert to the overall performance across the match.
06:40:29 <ais523> yes (you would need to special-case the situation where all lengths/polarities/delays were timeouts but it's clear what to do there)
06:40:43 <Lymia> Huh, that actually doesn't sound too bad.
06:40:49 <ais523> that case isn't so unlikely, either, it happens in the passive defender mirror match
06:41:47 <Lymia> Would benefit programs like margins3 for the most part.
06:41:58 <Lymia> Though, uh, it might makes its scores fairly unstable against programs that narrowly take a few games from it.
06:42:06 <ais523> yes, that's a reason not to score like that
06:42:30 <ais523> I feel like margins3's time in the sun is setting, too – it is too easy to beat nowadays
06:42:45 <Lymia> Ash has a fairly narrow win
06:45:40 <esolangs> [[User:Iddi01/Sandbox]] N https://esolangs.org/w/index.php?oldid=144641 * Iddi01 * (+21249) This is the actual version, was blocked automatically when attempted in the sandbox
06:45:56 <Lymia> Hmm. Treating ties as 50% the overall winrate seems fairly sane, though.
06:46:29 <Lymia> Combining that with a simpler scoring method like tweaked traditional could well get something like markov in terms of overall kinds of bots it encourges
06:46:36 <Lymia> Without the instability.
06:51:14 <esolangs> [[Esolang:Sandbox]] https://esolangs.org/w/index.php?diff=144642&oldid=144640 * Ais523 * (-1) clean up a left-over non-ASCII character imitating ASCII (please don't make me add a filter against these, it would have enough false positives to potentially cause problems for other wiki users)
06:52:41 <Lymia> I'm thinking a bit about the idea of reversing the "value" mechanism of traditional scoring.
06:52:56 <Lymia> Where each program has a fixed value that is divided proportionally to the programs that win against it.
06:53:57 <Lymia> Not sure this is meaningfully different.
06:54:30 <ais523> if it isn't too hard to implement, you could find out
07:01:28 <Lymia> This is pretty similar to a single step of markov evaluation.
07:07:47 <Lymia> This is in many ways the non-iter variant of markov (which.... is frankly overengineered.)
07:09:13 -!- tromp has joined.
07:17:11 -!- iddi01 has joined.
07:18:59 <ais523> iddi01: your user sandbox triggers more "this page couldn't be rendered properly due to exceeding limits of the wiki" warnings than I've ever seen on a single page before, and my browser struggles to load it
07:19:44 <ais523> as such, assuming the test is complete now, I'm planning to delete it
07:20:43 <iddi01> Blanking would be preferred, so people could view the test if they wish to get an idea of how crazy tests can get.
07:21:02 <iddi01> (from the page history)
07:21:50 <ais523> blanking could be reasonable
07:21:59 <Lymia> Alright. Have an unmodified traditional scoring working.
07:22:17 <ais523> I was having some thoughts about the semi-serious language list, and the featured article thing on the main page
07:23:11 <ais523> I was wondering whether instead of "featured article", it should be "random esolang" and link to one of the pages on the SSLL at random, restricted to only languages with an implementation (so that casual visitors get to try it out)
07:23:16 <ais523> but that would mean writing blurbs for all of them
07:24:17 <ais523> I was also wondering whether the SSLL should be made into the primary language list, with the existing language list either kept as a backup or deleted in favour of Category:Languages, although it would probably need to be renamed in that case and I'm not sure what it should be called instead
07:25:51 <iddi01> for the featured article, i'll crosspost my suggestion from Talk:Main_Page, "Add the rule that, when at least 2 people other than the language's creator (actually 3, the first being the one proposing the language) agree on that a language should be featured (which they may say at the talk page, on IRC, or anywhere else) and no one disagrees within
07:25:52 <iddi01> a month since that happened, it becomes featured. This will ensure that the featured language is still changing in 'admin scarcity times' like this. What do you think?"
07:26:33 <ais523> one big problem with the featured language is that if it's going to stay for a while, it needs a really high-quality article and we don't have many like that
07:27:05 <ais523> I also fear that it'd lead to newly designed languages which haven't really been checked by anyone else by the creator being featured too often
07:28:11 <iddi01> But there would also be few cases where 3 people agree on the same language to become featured
07:29:35 <ais523> I guess the situation is – there are some languages which have a good enough page to be featured, and there are some languages which have enough interest/programs/implementations to be featured, and there isn't a lot of overlap
07:30:59 <ais523> also, the lack of admins makes the featured language process hard to use because it is basically forcing me into a decision, but as a prolific esolang creator (and being involved with several languages that might be worthy of featuring) it is hard for me to make a decision due to potential bias issues – it is unclear whether I can fairly judge my esolangs against other people's, and even if I can, people might think I'm biased
07:31:36 <ais523> (I mostly wasn't involved in the process being created – I was there but I think it was mostly other admins' decisions)
07:32:26 <iddi01> And that's exactly why we should focus on consensus instead of admin decision
07:33:41 <Lymia> https://pastebin.com/sTuDcZy4
07:33:49 <Lymia> Some examples of traditional scoring variants.
07:35:46 <iddi01> It's really fun to watch people rediscover all those strategies: https://codegolf.stackexchange.com/questions/36645/brainfedbotsforbattling-a-brainf-tournament
07:36:14 <Lymia> !ztest original_nyuroki https://raw.githubusercontent.com/Lymia/JoustExt/refs/heads/master/examples/nyuroki.bf
07:36:15 <zemhill> Lymia.original_nyuroki: points -5.90, score 14.89, rank 42/47
07:36:55 <Lymia> !ztest original_nyuroki_but_not_really https://raw.githubusercontent.com/Lymia/JoustExt/refs/heads/master/examples/nyuroki-esoteric.bf
07:36:55 <zemhill> Lymia.original_nyuroki_but_not_really: points 15.86, score 42.24, rank 1/47
07:39:04 <Lymia> By markov score, nyuroki (the original first version that landed first on zemhill) is the best program I have across every bot ever submitted to the original esohill or the new zemhill, lol.
07:39:20 <Lymia> Less fitting to hill, probs.
07:44:52 -!- Lord_of_Life_ has joined.
07:45:09 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
07:46:13 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
07:46:16 -!- craigo has joined.
07:48:50 <Lymia> Hmm... Ash definitely deserves to win I think, is a start to my tests here.
07:52:29 <Lymia> But why Ash and not Mist, Mist is also fairly drawish.
07:52:31 <Lymia> And I'd say the answer is: Ash clearly has a way better raw score than Mist.
07:54:16 <Lymia> ais523: here's an interesting question for iterative methods.
07:54:26 <Lymia> Is there a compelling reason to look for the fixed point rather than a reasonable number of iterations?
07:54:44 <Lymia> (Arbitarily chosen)
08:23:36 <Lymia> ... Hrm. Overall, I think the "ideal" scoring may be iterative tweaked traditional rather than markov. But I'd need to test how unstable it is over time. u.u;
08:25:29 <ais523> <Lymia> Is there a compelling reason to look for the fixed point rather than a reasonable number of iterations? ← if the iterations converge, they converge on the fixed point, so it's a natural stopping point; if they don't, that's a good reason to pick the fixed point rather than stopping at some arbitrary point on the attractor
08:26:36 <Lymia> I'm just wondering if for practical scoring purposes, a fixed (and small) number of iterations would be "good enough" but less vulnerable to being distorted in degenerate cases.
08:27:36 <Lymia> (Did the experiments on "reverse" scoring, it's... viable, but isn't different enough from raw score unless I screwed up the implementation.)
08:28:11 <Lymia> (Difference's probably bigger on larger hills with a lot of garbage though.)
08:47:33 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
08:56:52 -!- tromp has joined.
09:05:58 <b_jonas> one thing you could do is a combination where there's a main scoring system that determines the placing on the hill, but also a few other scoring systems such that there are a few slots reserved on the hill for jousters that perform well in an alternative, so you keep the 40 highest main scoring programs plus the 4 highest alternative scoring programs and 4 highest other alternative scoring program but
09:06:04 <b_jonas> sort the whole lot by the main score. eg. you could have an alternative that disfavors draws, so that even if defenders turn out to be too powerful, there'll still always be four attacker programs on the hill that and program will have to try to beat, etc.
09:07:15 <b_jonas> kind of like when a sports world championship takes the best athlete from each country if the reach a lower threshold than the large number of top athletes that come mostly from the US and China
09:07:30 <b_jonas> only without the politics associated
09:11:16 <esolangs> [[Stakc]] https://esolangs.org/w/index.php?diff=144643&oldid=144592 * ChuckEsoteric08 * (+28) /* Documentation */
09:11:27 <b_jonas> I mean there's still the politics of discussing what kind of hill you want, just not the non-sports politics where even though you just want to organize sports you have to decide whether Kosovo is a real country and no matter how you decide at least a quarter of the world will hate you and possibly boycott your competition and all that nonsense
09:13:17 <b_jonas> I guess they could do some multi-score hills like this in other sports too as long as the sport has pairwise matches between teams like football or duplicate bridge, rather than a ranked performance between individual competitors like weightlifting or swimming
09:15:32 <b_jonas> so you could have a basketball hill that includes 2 teams who are the best at scoring 3 point goals plus the 6 other best teams according to traditional score, score the hill according to traditional score
09:16:22 <b_jonas> or a football championship that includes 2 teams with the best cheerleading performance plus 6 other teams best in football
09:17:17 <ais523> what do you do if the alternative scoring systems choose bots that already scored well enough on the main scoring system?
09:17:18 <b_jonas> that way if some of your audience likes to watch 3 pointers or cheerleading you sell more tickets to them, especially to groups of friends where one person watches the football/basketball and the other watches for 3 pointers or cheerleading
09:18:10 <ais523> I do like the idea (for BF Joust, not football) if a good set of details can be worked out
09:18:24 <b_jonas> ais523: I assume you'd choose in advance a sequence of the multiset of scores, and for picking the hill you iterate on the sequence and add to the hill the best remaining team according to that score
09:19:11 <b_jonas> I'd probably put the alternative scores first so that they only matter if the bots scoring best on normal scores aren't good at them
09:20:03 <Lymia> None of the scoring systems are different enough (it seems) that high scoring candidates in any system are likely to die.
09:20:08 <Lymia> Unless they're extraordinarily different.
09:21:13 <ais523> right, something ilke margins3 or ash which scores very well in Markov tends to be pinned to the middle of the leaderboard in traditional, but the middle is not the bottom so they're at little risk of falling
09:24:21 <b_jonas> one thing that real sports do is when the big prestigous tournament invites competitors who perform well in any of the smaller local competitions, or perhaps by your second or third best score among those smaller competitions so you need to participate and perform well on multiple of them but don't get much advantage for traveling to a lot of them. plus sometimes they give a free pass for the champion
09:24:27 <b_jonas> in the previous iteration of the big prestigeous competition. but I don't think this applies too well in bfjoust, unless you want multiple less important hills and programs automatically submitted to each of them.
09:24:41 <Lymia> This is what I do in my evolver, but that's a bit of a special case.
09:25:00 <Lymia> The multiple less important hills is for preventing a complete collapse of diversity and not much more.
09:26:42 <b_jonas> you could even use auxiliary scoring systems for which you need to run more underlying games, such as one that cares about games with a few turns of delay like you suggested above, or a scoring system that only looks at games with shorter tapes and one that only looks at games on longer tapes
09:27:01 <b_jonas> or one that weighs medium length tapes higher
09:27:40 <b_jonas> you could even have more radical changes than those
09:32:57 <b_jonas> whoa, you're thinking of a bfjoust variant where the code space is fungeoid but the data space is traditional bfjoust except for the one extra counter register? wow
09:33:31 <b_jonas> ais523: I'd what modulus are you planning for the cells in the bfjoust arena? I feel like the current 256 is traditional and might not be the best
09:34:08 <ais523> 256 being a power of two has some interesting implications for defence programs
09:34:37 <ais523> it might be interesting to experiment with 240 (divisible by 2, 3, 5) but I am not at all sure that that is better
09:36:42 <b_jonas> “would make it possible to run an ‘infinitely long match’” => it might take too long time though because a program could iterate over all 28-digit integers or so with the digits in the tape positions against a goldfish. which is probably still better than what's theoretically possible in chess or arimaa with no 50 turn rule and draw only on repetition of board state, but bad enough that you
09:37:06 <b_jonas> I was thinking mostly of a smaller modulus like 128
09:37:29 <b_jonas> because it might speed games up in number of turns
09:38:28 <ais523> oh – one thing to bear in mind is that the modulus size compared to tape length is important for defenders, which need to be able to reach the other side of the tape, do some clearing, and get back before the cell is cleared
09:38:47 <ais523> that's the primary reason I made the tape shorter when introducing the modern rules – in the original rules it was really long
09:40:04 <ais523> the "both bots are in clear loops, clearing decoys" situation should be fairly easy to optimise if you wanted to, although I'm not sure any impls actually do that
09:40:17 <b_jonas> “making a game that people outside the esolang community might want to play” => if that's the goal then why fungeoid code space?
09:40:42 <ais523> and that would make cell size mostly irrelevant in terms of simulation speed
09:40:55 <ais523> b_jonas: because most programming languages designed for non-programmers are 2D
09:41:31 <ais523> and most games about programming find 2D more interesting – it fits onto the screen better and gives more interesting routing problems than goto statements and labels do
09:42:07 <ais523> writing a loop by drawing an actual loop into the codespace is very natural for non-programmers, while and goto are a bit harder to learn
09:43:14 <ais523> although, the way you make this work visually is to have the connections between commands drawn out like flowcharts or conveyor belts, rather than being implicit like they are in Befunge
09:43:16 <b_jonas> are they 2D in a fungeoid sense? I don't recall many such games about programming, other than shapez and openttd and factorio, and the last two only in ways where they weren't designed as programming games but people discovered accidental programmable structures in them
09:43:34 <b_jonas> to be clear factorio *has* a programmable part built in, but that part isn't 2d
09:43:51 <b_jonas> the 2d one is making boolean circuits using belts or that sort of thing
09:44:35 <b_jonas> so I wonder what programming games you mean
09:44:52 <b_jonas> "complete with cartoonish blindfolded robots desperately feeling around for flags" hehe
09:45:10 <b_jonas> I probably just don't play or watch many programming games though
09:45:20 <Lymia> <ais523> the "both bots are in clear loops, clearing decoys" situation should be fairly easy to optimise if you wanted to, although I'm not sure any impls actually do that
09:45:27 <ais523> well I haven't for a couple of decades, it's possible that the style has changed
09:45:44 <Lymia> Cost/benefit there is whether the checks to see that's happening will save more time than is saved.
09:46:06 <ais523> yes – although I expect it to
09:46:18 <ais523> that was one of the first optimisations in ratiofall, and one of the easiest to understand
09:46:30 <ais523> (ratiofall = optimising The Waterfall Model interpreter)
09:47:13 <ais523> it's a situation that frequently happens and you're skipping forwards a substantial proportion of 512 cycles
09:47:50 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
09:47:56 <ais523> you can make the optimisation better by waiting for the bots to cross positions, then simulating them individually until they win, fall, or move back behind the crossing position
09:48:32 <ais523> that increases the chance that optimisations will apply and allows bigger skips, and there's quite a large proportion of duels where after the bots cross, they never cross back
09:49:34 <Lymia> I am planning on making oxygenlance a pure rust implementation (based on chainlance), so.
09:49:46 <Lymia> There is room to implement some advanced optimizations that gearlance wouldn't have.
09:50:19 <b_jonas> hmm, what if the code is only kind of 2D, not a fungeoid but imitates an old style computer where the instructions are stored on a magnetic disk/cylinder with a separate head for each track, so control flow always goes downwards wrapping around a fixed height code space, but you have a goto instruction to jump onto any track, and conditional skip instructions
09:51:03 <b_jonas> that's not for what you're saying about helping non-esoprogrammers with 2D programming games, just a general idea
09:52:33 <ais523> b_jonas: low-control-flow esolangs feel like that sometimes, Advance The Wheel! is somewhat reminiscent of that
09:52:59 <b_jonas> though there's two variants of this, one where the drums of the two jousters are synchronized with one step of the drum each turn, and one where the drums aren't synchronized and there are instructions that don't take a turn, like you might have free nop or control flow, but also a one-turn nop and one-turn cell increase decrease zero-test
09:53:06 <ais523> although instead of being able to write the tracks arbitrarily, they're all polyglots induced by different wheel positions
09:55:37 <b_jonas> (for extra old style the drum would store information in a mechanical way rather than magnetic)
09:56:09 <ais523> hmm, that makes me realise that Advance The Wheel! might be quite suitable to implement in a mechanical computer
09:56:34 -!- baldibacak has joined.
09:58:22 <b_jonas> "blindfolded robots" => and the program makes a fixed choice of one of about thirty different characters, each of which have a small difference like an extra instruction or two that they have access to, plus a variant of that character that is cosmetic only, and you need to register and attain a top 20 place with a character to unlock its shiny variant
09:59:55 <iddi01> sorry, heavily delayed response (half an hour late, scroll up to the point in time), but regarding multiple BF joust hills, i think the first step is to resurrect the egojoust hill, also so that the loads of "Trace and animation" links in the strategies pages would work again.
10:00:58 <b_jonas> also each game is played to two won stocks, most of the values on the tape are kept throughout but the value of the two flags and two more cells next to them and the position of the jousting heads are reset, and the programs have four starting positions in the code space depending on which stock it is starting
10:01:13 <ais523> well, we can't exactly host things on GregorR's website if the owner isn't around to maintain it – the better approach would be to reconstruct the links elsewhere, but that would mean we'd need to reimplement the animation feature because zemhill doesn't have a way to link to the feature there
10:01:49 <b_jonas> sorry I'm getting a bit silly here
10:03:24 -!- salpynx has quit (Quit: Leaving).
10:12:21 <esolangs> [[Assemblyfuck]] https://esolangs.org/w/index.php?diff=144644&oldid=75073 * Baldibacak * (+177)
10:16:14 <esolangs> [[Ecliptica]] https://esolangs.org/w/index.php?diff=144645&oldid=144537 * Baldibacak * (+9)
10:17:28 -!- X-Scale has joined.
10:22:23 -!- amby has joined.
10:30:20 <fizzie> I could add an URL syntax for custom programs to https://zem.fi/bfjoust/game/ I guess. Maybe something that just encodes the code in the URL; the wiki strategy examples are short enough for that. It's the same viewer, and you can already type stuff in the textboxes, there just isn't a way to put the code in the link, and/or to make it pre-open a specific tape length/polarity.
10:35:28 -!- ais523 has quit (Quit: quit).
10:56:30 <iddi01> ^echo !zjoust clock >>>+<+<+>[(+)*29(-)*30<-[<(+++-++-+)*-1]+>(+)*30(-)*29<-[<(+++-++-+)*-1]+>]<[(+)*65(>)*8[+[--[(-)*122(-.)*11(<)*9(+++-++-+)*-1]]](<)*9(+++-++-+)*-1]<(+++-++-+)*-1 what follows is due to the design of the fungоt echo command
10:56:30 <fungot> !zjoust clock >>>+<+<+>[(+)*29(-)*30<-[<(+++-++-+)*-1]+>(+)*30(-)*29<-[<(+++-++-+)*-1]+>]<[(+)*65(>)*8[+[--[(-)*122(-.)*11(<)*9(+++-++-+)*-1]]](<)*9(+++-++-+)*-1]<(+++-++-+)*-1 what follows is due to the des ...
10:56:32 <zemhill> fungot.clock: points -2.02, score 17.33, rank 30/47
10:56:32 <fungot> zemhill: that'd be awesomely meta.) the namestring is not portable, even from some who don't like me
10:57:41 -!- X-Scale has quit (Ping timeout: 256 seconds).
11:02:35 <esolangs> [[Talk:PyFuck]] N https://esolangs.org/w/index.php?oldid=144646 * None1 * (+667) Created page with "==8 characters for interpreting any code== On the fewest character for turing completeness question on codegolf stackexchange, there's an answer that shows Python only needs 8 characters to interpret any Python code: exc('%0), there is a link in the answer to a repo na
11:19:05 -!- earend1 has joined.
11:23:22 -!- iddi01 has quit (Quit: Client closed).
11:24:27 -!- earend1 has changed nick to we11en.
11:26:34 -!- we11en has changed nick to earend1.
11:33:06 <esolangs> [[Ecliptica]] https://esolangs.org/w/index.php?diff=144647&oldid=144645 * Baldibacak * (+24)
11:46:39 <esolangs> [[Talk:PyFuck]] https://esolangs.org/w/index.php?diff=144648&oldid=144646 * ShirAko * (+323) /* 8 characters for interpreting any code */
12:14:59 -!- wib_jonas has joined.
12:31:54 <wib_jonas> re featured language, yes, bias is the problem, in particular Underload has a decent article written about it, but with you being the only active admin it can only be featured if fizzie is willing to make the decision
12:32:51 <wib_jonas> as for one of multiple languages shown randomly on the front page, I think that only works if there is only a small pool of featured language descriptions from which the front page rolls one
12:37:55 <wib_jonas> if you want to make sure that programs can't be overfitted then you'll probably have to add so many variations (rather than just the 21*2 current) that it's impossible to run all of them, and choose from them randomly or pseudorandomly when the hill is evaluated. for example, there could be a new instruction that behaves randomly each time it's
12:37:55 <wib_jonas> executed, or each jouster has a small probability to pause for a turn after each instruction executed, or something like that.
12:38:44 <wib_jonas> probably shouldn't be just a delay so that programs can be written that actively branch differently depending on the random outcome
12:42:28 -!- wWwwW has joined.
12:44:25 <esolangs> [[User:ChuckEsoteric08/Interpreters]] https://esolangs.org/w/index.php?diff=144649&oldid=121661 * ChuckEsoteric08 * (+1) /* (binary) brainfuck in CDILOI */
12:46:54 -!- amby has quit (Ping timeout: 276 seconds).
12:50:53 <esolangs> [[User:ChuckEsoteric08/Interpreters]] https://esolangs.org/w/index.php?diff=144650&oldid=144649 * ChuckEsoteric08 * (+0) /* (binary) brainfuck in CDILOI */ fixed
12:59:16 <esolangs> [[User:ChuckEsoteric08/Interpreters]] https://esolangs.org/w/index.php?diff=144651&oldid=144650 * ChuckEsoteric08 * (+1543)
13:01:34 <esolangs> [[Yayimhere-like esolang]] https://esolangs.org/w/index.php?diff=144652&oldid=140903 * Ractangle * (-114) /* Looping counter */
13:02:19 <esolangs> [[Yayimhere-like esolang]] https://esolangs.org/w/index.php?diff=144653&oldid=144652 * Ractangle * (-10) /* syntax */
13:02:24 <esolangs> [[SHITS]] https://esolangs.org/w/index.php?diff=144654&oldid=122570 * ChuckEsoteric08 * (+1463) /* Interpreter */
13:05:09 <esolangs> [[Yayimhere-like esolang]] https://esolangs.org/w/index.php?diff=144655&oldid=144653 * Ractangle * (+0) /* syntax */
13:07:53 -!- amby has joined.
13:10:13 -!- amby has quit (Client Quit).
13:19:33 <esolangs> [[EsoInterpreters]] https://esolangs.org/w/index.php?diff=144656&oldid=141374 * ChuckEsoteric08 * (+2539) /* Main table */ Added SHITS in CDILOI
13:21:57 <esolangs> [[PyFuck (kuangkzh)]] N https://esolangs.org/w/index.php?oldid=144657 * None1 * (+577) Created page with "'''PyFuck''' is an esolang invented by [https://github.com/kuangkzh GitHub user kuangkzh] in 2022 (according to the edit time of codegolf stackexchange answer and GitHub repo) that uses only 8 characters: <code>exc('%x)</code>, but it can run any Python program.
13:22:15 <esolangs> [[EsoInterpreters]] https://esolangs.org/w/index.php?diff=144658&oldid=144656 * ChuckEsoteric08 * (-1)
13:22:46 <esolangs> [[Special:Log/move]] move * None1 * moved [[PyFuck]] to [[PyFuck (ShirAko)]]
13:22:46 <esolangs> [[Special:Log/move]] move * None1 * moved [[Talk:PyFuck]] to [[Talk:PyFuck (ShirAko)]]
13:24:20 <esolangs> [[PyFuck]] https://esolangs.org/w/index.php?diff=144663&oldid=144660 * None1 * (+152) Removed redirect to [[PyFuck (ShirAko)]]
13:24:47 <esolangs> [[PyStr]] N https://esolangs.org/w/index.php?oldid=144664 * None1 * (+30) Redirected page to [[PyFuck (ShirAko)]]
13:25:28 <esolangs> [[PyFuck (kuangkzh)]] https://esolangs.org/w/index.php?diff=144665&oldid=144657 * None1 * (+38)
13:25:55 <esolangs> [[PyFuck (kuangkzh)]] https://esolangs.org/w/index.php?diff=144666&oldid=144665 * None1 * (+43)
13:26:14 <esolangs> [[PyFuck (ShirAko)]] https://esolangs.org/w/index.php?diff=144667&oldid=144659 * None1 * (+44)
13:27:50 -!- baldibacak has quit (Quit: Client closed).
13:28:34 <esolangs> [[Talk:PyFuck (ShirAko)]] https://esolangs.org/w/index.php?diff=144668&oldid=144661 * None1 * (+415) /* 8 characters for interpreting any code */
13:32:59 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=144669&oldid=144570 * None1 * (+10) /* P */
13:33:23 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=144670&oldid=144669 * None1 * (+24) /* P */
13:33:50 <esolangs> [[Hello world program in esoteric languages (N-S)]] https://esolangs.org/w/index.php?diff=144671&oldid=144612 * None1 * (+10) /* PyFuck */
13:34:05 <esolangs> [[Hello world program in esoteric languages (N-S)]] https://esolangs.org/w/index.php?diff=144672&oldid=144671 * None1 * (+10) /* PyFuck (ShirAko) */
13:34:34 <esolangs> [[PyChr]] https://esolangs.org/w/index.php?diff=144673&oldid=144616 * None1 * (+10) /* See also */
13:36:52 <esolangs> [[JSFuck]] https://esolangs.org/w/index.php?diff=144674&oldid=144564 * None1 * (+52) /* External resources */
13:43:56 <esolangs> [[Special:Log/upload]] overwrite * None1 * uploaded a new version of "[[File:Brainfuck stegfuck.png]]": the brainfuck logo taken from daniel b cristofani's brainfuck page had no license with it so it is not public domain after all. any admin who sees this please delete the original image, new image is a screenshot of the title of the brainfuck page in esolang
13:46:44 <esolangs> [[Special:Log/upload]] overwrite * None1 * uploaded a new version of "[[File:Ternlsb bf.png]]": the brainfuck logo taken from daniel b cristofani's brainfuck page had no license with it so it is not public domain after all. any admin who sees this please delete the original image, new image is a screenshot of the title of the brainfuck page in esolangs wiki
13:54:36 -!- chiselfuse has quit (Remote host closed the connection).
13:54:55 -!- chiselfuse has joined.
14:14:26 -!- Sgeo has joined.
14:38:28 -!- X-Scale has joined.
15:16:58 <esolangs> [[C-fuck]] https://esolangs.org/w/index.php?diff=144677&oldid=144600 * Baldibacak * (-864) Blanked the page
15:28:30 -!- earend1 has quit (Quit: Connection closed for inactivity).
15:33:32 <esolangs> [[PyFuck (kuangkzh)]] https://esolangs.org/w/index.php?diff=144678&oldid=144666 * ShirAko * (+366) Added Hello World as an external ressource (100MB)
15:34:26 <esolangs> [[Special:Log/move]] move * ShirAko * moved [[PyFuck (ShirAko)]] to [[PyFuck (shirAko)]]: Misspelled title
15:34:26 <esolangs> [[Special:Log/move]] move * ShirAko * moved [[Talk:PyFuck (ShirAko)]] to [[Talk:PyFuck (shirAko)]]: Misspelled title
15:34:57 <esolangs> [[PyFuck]] https://esolangs.org/w/index.php?diff=144683&oldid=144663 * ShirAko * (+0)
15:35:15 <esolangs> [[User:ShirAko]] https://esolangs.org/w/index.php?diff=144684&oldid=144621 * ShirAko * (+136)
15:37:58 <esolangs> [[Hello world program in esoteric languages (N-S)]] M https://esolangs.org/w/index.php?diff=144685&oldid=144672 * ShirAko * (+210) Added hello world for PyFuck (kuangkzh)
15:38:00 -!- baldibacak has joined.
15:50:39 -!- wWwwW has quit (Ping timeout: 256 seconds).
16:32:15 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[File:Brainfuck stegfuck.png]]": Deleted old revision 20241031134356!Brainfuck_stegfuck.png: Copyright violation: this version of the image was a derivative of a non-public-domain image (the updated version is not based on it)
16:32:39 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[File:Ternlsb bf.png]]": Deleted old revision 20241031134644!Ternlsb_bf.png: Copyright violation: this version of the image was a derivative of a non-public-domain image (the updated version is not based on it)
16:34:35 <esolangs> [[PyFuck (kuangkzh)]] https://esolangs.org/w/index.php?diff=144686&oldid=144678 * Ais523 * (+0) fix definition of the language: the original author said that that the language allows `0` (and the previously written specification had `x` twice, likely a typo)
16:37:12 -!- Lord_of_Life has quit (Excess Flood).
16:39:04 -!- Lord_of_Life has joined.
17:00:44 <esolangs> [[10 1]] https://esolangs.org/w/index.php?diff=144687&oldid=144596 * Baldibacak * (-68) fixed compiler ignoring first character on input
17:00:58 <esolangs> [[10 1]] https://esolangs.org/w/index.php?diff=144688&oldid=144687 * Baldibacak * (-1) removed accidently added dot at the start of the program
17:08:08 -!- wib_jonas has quit (Quit: Client closed).
17:17:05 <esolangs> [[ABPLWNL]] https://esolangs.org/w/index.php?diff=144689&oldid=144109 * Ractangle * (-32) /* Commands */
17:19:25 <esolangs> [[ABPLWNL]] https://esolangs.org/w/index.php?diff=144690&oldid=144689 * Ractangle * (-1) /* Hello World program */
17:33:55 <esolangs> [[ABPLWNL]] https://esolangs.org/w/index.php?diff=144691&oldid=144690 * Ractangle * (+3) /* Interpreter and Compiler */
17:49:09 -!- FireFly has quit (Ping timeout: 248 seconds).
17:51:00 -!- X-Scale has quit (Quit: Client closed).
17:51:14 -!- FireFly has joined.
18:10:58 <esolangs> [[User:ChuckEsoteric08/Interpreters]] https://esolangs.org/w/index.php?diff=144692&oldid=144651 * ChuckEsoteric08 * (+2) /* Bitwise Cyclic Tag in CDILOI */
18:13:20 -!- X-Scale has joined.
18:43:02 <esolangs> [[STRTRAN]] https://esolangs.org/w/index.php?diff=144693&oldid=144148 * Froginstarch * (+3) /* Concatenation */
18:43:17 <esolangs> [[STRTRAN]] M https://esolangs.org/w/index.php?diff=144694&oldid=144693 * Froginstarch * (+3) /* Replacing */
18:48:05 <esolangs> [[Yayimhere-like esolang]] https://esolangs.org/w/index.php?diff=144695&oldid=144655 * Ractangle * (+0)
18:48:52 <esolangs> [[Yayimhere-like esolang]] https://esolangs.org/w/index.php?diff=144696&oldid=144695 * Ractangle * (+2) /* Truth-machine */
18:49:20 -!- Franciman has quit (Remote host closed the connection).
18:51:13 <esolangs> [[Ecliptica]] https://esolangs.org/w/index.php?diff=144697&oldid=144647 * Baldibacak * (+7) in newest version of compiler and interpreter r command is changed
18:53:34 -!- tromp has joined.
18:57:09 -!- molson__ has joined.
18:57:13 -!- molson_ has quit (Ping timeout: 252 seconds).
18:58:58 <esolangs> [[Ecliptica]] https://esolangs.org/w/index.php?diff=144698&oldid=144697 * Ractangle * (-39) /* Commands */
19:06:22 -!- Artea has quit (Quit: ZNC 1.9.1 - https://znc.in).
19:08:16 -!- visilii_ has quit (Ping timeout: 244 seconds).
19:08:34 -!- visilii has joined.
19:22:48 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
19:26:55 -!- perlbot has quit (Read error: Connection reset by peer).
19:26:57 -!- simcop2387 has quit (Read error: Connection reset by peer).
19:31:43 -!- perlbot has joined.
19:33:04 -!- simcop2387 has joined.
19:52:39 <esolangs> [[SWCE]] https://esolangs.org/w/index.php?diff=144699&oldid=144449 * Ractangle * (+0)
19:53:17 <esolangs> [[ASCII]] https://esolangs.org/w/index.php?diff=144700&oldid=97993 * Ractangle * (+10) /* See also */
19:54:38 <esolangs> [[LSCEF]] https://esolangs.org/w/index.php?diff=144701&oldid=78850 * Ractangle * (+10) /* See also */
19:55:36 <esolangs> [[SWCE]] https://esolangs.org/w/index.php?diff=144702&oldid=144699 * Ractangle * (+64)
19:56:38 <esolangs> [[SWCE]] https://esolangs.org/w/index.php?diff=144703&oldid=144702 * Ractangle * (-20)
19:56:50 <esolangs> [[SWCE]] https://esolangs.org/w/index.php?diff=144704&oldid=144703 * Ractangle * (-44)
20:02:19 <esolangs> [[Yayimhere-like esolang]] https://esolangs.org/w/index.php?diff=144705&oldid=144696 * Ractangle * (-33) /* syntax */
20:02:24 -!- molson__ has quit (Ping timeout: 276 seconds).
20:03:40 <esolangs> [[Yayimhere-like esolang]] https://esolangs.org/w/index.php?diff=144706&oldid=144705 * Ractangle * (-5) /* syntax */
20:03:51 -!- molson has joined.
20:06:58 <esolangs> [[SWCE]] https://esolangs.org/w/index.php?diff=144707&oldid=144704 * Ractangle * (+33) /* Charecter table */
20:27:35 <Lymia> iddi01: Why are you crediting bots to fungot? :)
20:27:35 <fungot> Lymia: name ' math' is not defined, but never turned anything in. so you get that,
20:37:21 <esolangs> [[Talk:4]] https://esolangs.org/w/index.php?diff=144708&oldid=140992 * ChuckEsoteric08 * (+468)
20:54:25 <esolangs> [[9]] M https://esolangs.org/w/index.php?diff=144709&oldid=144636 * PythonshellDebugwindow * (+41) Categories
20:54:47 <esolangs> [[90]] M https://esolangs.org/w/index.php?diff=144710&oldid=144316 * PythonshellDebugwindow * (+22) See also
20:58:06 <esolangs> [[Suc]] M https://esolangs.org/w/index.php?diff=144711&oldid=120765 * PythonshellDebugwindow * (+27) See also
20:58:44 <esolangs> [[Suc]] M https://esolangs.org/w/index.php?diff=144712&oldid=144711 * PythonshellDebugwindow * (+23) /* See also */ Category
20:59:09 <esolangs> [[Sucks]] M https://esolangs.org/w/index.php?diff=144713&oldid=144565 * PythonshellDebugwindow * (+39) Categories
21:02:09 -!- molson has quit (Ping timeout: 248 seconds).
21:12:17 <esolangs> [[Definitely unusable]] https://esolangs.org/w/index.php?diff=144714&oldid=125116 * Ractangle * (-98) Hopefully this helps
21:25:56 <esolangs> [[Definitely unusable]] M https://esolangs.org/w/index.php?diff=144715&oldid=144714 * PythonshellDebugwindow * (+98) Undo revision [[Special:Diff/144714|144714]] by [[Special:Contributions/Ractangle|Ractangle]] ([[User talk:Ractangle|talk]]): missing the joke
21:29:27 -!- molson has joined.
21:30:19 <korvo> fungot: The most important theorem in BF Joust is
21:30:19 <fungot> korvo: nah, we don't need a mirror
21:32:43 <b_jonas> fungot: which direction of mirror? one that swaps the polarity, or one that swaps the two jousters?
21:32:43 <fungot> b_jonas: i go to bed!"
21:33:21 -!- tromp has joined.
21:42:52 -!- salpynx has joined.
22:10:04 -!- FreeFull has quit.
22:15:49 -!- FreeFull has joined.
22:38:02 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:52:38 -!- ais523 has joined.
23:24:20 <int-e> b_jonas: Hmm odd question because I've been watching somebody play Factorio. Would you be able to build belts like this? https://int-e.eu/~bf3/tmp/fq.png (the idea would be merging 8 yellow belts into 4 red ones, loading each output from both sides)
23:25:07 -!- X-Scale has quit (Ping timeout: 256 seconds).
23:28:18 -!- craigo has quit (Ping timeout: 252 seconds).
23:41:34 <b_jonas> int-e: you can marge two yellow belts into four red belts and do that four times. you can't do it with the exact geometry that you're showing because of how belts work in factorio: you always place belt pieces in just one of four cardinal orientations, and they're normally a straight belt piece, the belt piece Y only behaves as a curved belt piece only as long there's another belt piece (or underground
23:41:40 <b_jonas> belt or splitter or the ghost of any of these) X such that Y is in front of X and X is on the side of Y.
23:42:53 <b_jonas> and that too only if there's no belt piece (or underground or splitter or ghost of one) behind Y.
23:42:55 <int-e> b_jonas: okay, so no lose incoming turns. cool
23:43:15 <int-e> I guess I could try the demo. Surely it has belts...
23:43:40 <b_jonas> but be careful, it's an addictive game
23:43:51 <b_jonas> try the demo only if you have years of free time to play the game
23:44:27 <int-e> s/lose/loose/ (meh)
23:46:15 <b_jonas> also currently and in the next month or so I'm only willing to discuss factrio in very limited ways because the expansion dropped and I need time to experience it alone before I look at other players' games
23:47:28 <b_jonas> but before and after that I do discuss it a lot, mostly on several Factorio-related Discord servers
23:47:53 <b_jonas> I would do so here too but nobody else seemed to be playing the game
23:48:15 <int-e> I am kind of trying to stay away.
23:49:08 <b_jonas> you could play Mindustry, it's less addictive
23:49:46 <int-e> But I have seen some spoilers that you don't want to hear about. But this question seemed basic enough (and probably not changed from 1.x.) :)
23:50:18 <b_jonas> the belt physics of Mindustry is more frustrating in some ways -- but that's kind of cheating with words, because in Factorio the belt physics is mostly fine but the belt+inserter physics can be very frustrating
23:50:37 <b_jonas> they're frustrating in different ways though
23:51:47 <int-e> uh-oh, Mindustry is name-your-own price on itch
23:52:25 <b_jonas> in Mindustry the frustration is that there are things that should be simple but are hard to build a reliable construction for, especially if you want it to be simple, most notably a full throughput priority merge of two belts; while in Factorio the frustration is more that the actual throughput of belt+inserter constructions can be *very* unpredictable and appear to depend on the phase of the moon
23:52:46 <b_jonas> int-e: Mindustry is both that and also free in source code form
23:53:01 <b_jonas> (plus I think there's a Steam version)
23:53:09 <b_jonas> (but why would you want that instead of itch.io)
23:54:39 <int-e> Yeah I /try/ to avoid Steam but it's not always possible. Also Valve has been surprisingly non-evil *so far*. That could easily change.
23:54:59 <b_jonas> of course shapez.io also doesn't have reliable priority merges, which is annoying sometimes
23:56:08 <b_jonas> I wish the small mergers and splitters in shapez.io were priority, with the merge preferring straight input and the split preferring curved output, because you still have the balancer if you want an even merge or split so it wouldn't lose power
23:59:03 <int-e> Hmm. I guess that would give you more compact overflow protection.
23:59:58 <b_jonas> in shapez.io I mostly wanted priority merge to have belts into the hub that prioritize the freeplay shape but bring fixed shapes (glue or one of the three upgrade shapes) in between