< 1760574170 719763 :ajal!~ambylastn@host-92-17-32-126.as13285.net 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 < 1760576755 327732 :Sgeo__!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1760576935 887097 :Sgeo_!~Sgeo@user/sgeo QUIT :Ping timeout: 246 seconds > 1760579729 547134 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete10 02 5* 03Ais523 5* 10deleted "[[02User:Syzygy10]]": redirect left over after a page created in the wrong namespace was renamed to the correct namespace > 1760579765 817252 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move10 02 5* 03Ais523 5* 10moved [[02Esolang:Syzygy10]] to [[Syzygy]]: history merge to Syzygy > 1760579765 842175 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete10 02 5* 03Ais523 5* 10deleted "[[02Syzygy10]]": Deleted to make way for move from "[[Esolang:Syzygy]]" > 1760579786 451495 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 restore10 02 5* 03Ais523 5* 10undeleted "[[02Syzygy10]]": part two of history merge > 1760579812 943876 PRIVMSG #esolangs :14[[07Syzygy14]]4 10 02https://esolangs.org/w/index.php?diff=166113&oldid=166112 5* 03Ais523 5* (+9931) 10set top revision after history merge > 1760579862 814434 PRIVMSG #esolangs :14[[07User talk:Ais52314]]4 10 02https://esolangs.org/w/index.php?diff=166114&oldid=166101 5* 03Ais523 5* (+246) 10/* Esolangs forums? */ it didn't work last time we tried it < 1760580133 876121 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1760580233 439874 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I think that Basic Stack is TC by using the register and top of stack as two counters < 1760580309 618738 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the TC proof on the page is wrong I think, it's expecting "push reg" to push the reg-th stack element from the bottom (using it like a pick instruction which would be an easy way to get around the usual Turing-completeness issues for stack-based languages), but it actually pushes the register itself < 1760580413 567783 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : Oh, I don't have permissions to remove the redirect in the main namespace. I guess that I will *not* be able to fix that, sorry. ← an incorrect move always needs admin help to fix if anything happens to the resulting redirect (including being edited) < 1760580448 828788 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is possibly a design flaw of MediaWiki – I know I have historically spent a lot of time fixing broken moves both on Esolang, and on Wikipedia when I was an admin there < 1760580526 469879 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : do we still have a bot we use for @tell functionality here? I forget ← I usually try to read the entire logs, although I probably miss lines occasionally < 1760580546 593851 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :conversation in #esolangs is often asynchronous nowadays, with people conversing through the logs < 1760580653 799642 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : But I see lambdabot's still here, and if I recall correctly, it could also pass on messages. ← I wonder whether libera has memoserv? that got used on Freenode on occasion < 1760580680 160442 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :[Whois] MemoServ is MemoServ@services.libera.chat (Memo Services) < 1760580691 330849 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I imagine MemoServ messages may be easy to miss if you aren't expecting them, though < 1760580813 8903 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : You can in fact see the fnord in the code: https://github.com/fis/fungot/blob/master/fungot.b98#L157 ← that anchor annoys me, befunge really wants two-dimensional anchors, it isn't designed for one-dimensional anchors unless you program specifically to make it work < 1760580813 948315 :fungot!~fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :ais523: mr president, ladies and gentlemen, i should like to thank the rapporteur on her diligence and her persistence during the many debates that have taken place in committee; that is why i regard this particular proposal but we will not neglect the interest of food safety, must be respected in any coordination process. it is not sufficient for the president of the republic of armenia, azerbaijan and georgia. < 1760581841 966417 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: No worries. Thanks for your patience with us. > 1760582458 650405 PRIVMSG #esolangs :14[[07Interbflang14]]4 N10 02https://esolangs.org/w/index.php?oldid=166115 5* 03TheBigH 5* (+2191) 10Created article. > 1760582577 319209 PRIVMSG #esolangs :14[[07User:TheBigH14]]4 M10 02https://esolangs.org/w/index.php?diff=166116&oldid=165363 5* 03TheBigH 5* (+170) 10Added interbflang. < 1760583217 932601 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :Burroughs Algol 60 has an "IMP" relational operator (for implies). < 1760583266 80888 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Nice. It's not common; the only language that comes to mind for me is Nix. < 1760583373 129585 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :x86alikes have ANDN which is the opposite of an implies < 1760583398 5709 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although the argument order is very confusing: x ANDN y is "not x and y" which is the opposite of what you'd expect from the name < 1760583406 375740 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, (not x) and y < 1760583789 927815 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :Was looking at https://bitsavers.org/pdf/burroughs/LargeSystems/B5000_5500_5700/5000-21001-D_An_Introduction_to_Algol_60_for_the_B5000_Information_Processing_System_196112.pdf and now watching https://www.youtube.com/watch?v=T-NTEc8Ag-I before I go back to reading it. It's starting to strike me how Algol influenced C and some BASIC dialects (returning values by assigning to the function's name) < 1760585258 443941 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :Algol 60 switch statements are weird. IIUC they're targets for GO TO statements < 1760585451 55601 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think it benefits practical languages to have a return variable (i.e. something you can assign to in order to set the return value, possibly multiple times in the function/procedure/subroutine), *but* that its use should be optional and there should be return statements too as shorthand < 1760585480 143761 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I commonly end up having to create return variables, so it would be nice to have a convention for them, but you don't always need one < 1760585678 452295 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :So, which CPUs were designed with specific languages in mind? Burroughs mainframes for ALGOL, Lisp machines for Lisp, basically everything today for C < 1760586755 159523 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :Sgeo__: no, that's backwards. C was designed for the existing and near future CPUs, not the CPUs for C. < 1760586789 985041 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :I kind of have the impression that no CPU design would be made today that isn't a good fit for C < 1760586842 201476 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, but that's not because of C, it's to be able to run the programs that were designed to run on existing CPUs. I don't think C is relevant there. < 1760586906 559347 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :eg. the CPUs have to support a flat memory space addressible in bytes, because existing programs assume a flat memory and that is often baked so much into programs that it would be hard to chane < 1760587806 724306 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw I think the concept of different types of memory (rather than a flat address space) is a useful one and can help make programs more secure and easier to reason about < 1760587812 445242 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but existing segmented architectures might not fit it will < 1760587864 595627 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I realised recently that it makes sense to have indexable and non-indexable allocations (in non-indexable allocations the only pointer arithmetic allowed is field projections), with each array in its own indexable allocation < 1760587910 665905 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because if you don't do that, then most existing memory-safety retrofitters don't work properly because they don't prevent a buffer overflow that stays within the allocation and hits something that's stored in the same structure as the buffer < 1760587939 201857 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I suppose that in indexable allocations, pointer arithmetic should be limited to offsetting a multiple of the element size, plus field projections) < 1760588051 946512 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I also realised recently that a) the main technical problem in writing an efficient memory allocator nowadays is deallocating memory on a different thread it was allocated on, b) programs usually don't need to actually do that < 1760588126 565239 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so it would make sense to enforce that statically (in Rust you can do that by using a custom allocator that isn't Send) and that effectively gives you a different address space for each thread (they can read and write each other's spaces, but not allocate and deallocate) < 1760588602 933059 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :BASIC also has "IMP" relational operator and the "return variable" < 1760589156 476207 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :I feel like I've seen IMP on some BASICs, but I think only some BASICs have functions with return variables like that < 1760589170 923973 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :There's a lot of variety in BASICs < 1760589257 540958 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, and BASICs often have features or non-features that seem really weird to me < 1760589322 662872 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :QBasic has both IMP and functions that return values by setting the name < 1760589364 194489 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Yes, different versions of BASIC are different, but I specifically mean Microsoft BASIC (although I think most of the implementations at one time were from Microsoft?) < 1760589452 987935 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :Most of the implementations on microcomputers were from Microsoft. Mainframes and minicomputers had their own < 1760589487 360351 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I wrote http://esolangs.org/wiki/User:Zzo38/Programming_languages_with_unusual_features#BASIC but other things that you think are remarkable might also be mentioned (and/or the existing explanation changed) < 1760589505 389480 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :And I think "Microsoft BASIC" is itself ambiguous. There's the version on early microcomputers, then QBasic and QuickBASIC are a lot more full featured < 1760589542 882989 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Yes, I think you are correct < 1760589680 917345 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :Was going to post about ALGOL 60 but I don't fully understand its switch statement yet. < 1760589736 430976 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :There's a construct that's common to languages older than a certain point and uncommon to languages after that point, that I think counts as unusual to modern eyes: Taking an integer and doing something based on a list in that statement < 1760589786 265590 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Sgeo__: I think languages just became higher-level over time – there's an instruction that's very much like that in both JVM bytecode and LLVM IR < 1760589861 515525 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so it's still commonly used as something to compile into, it's probably important for performance that an instruction like that exists – it's just too low-level to be ergonomic to use directly < 1760590565 232150 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :There are often lower-level stuff other than assembly language that I will want to use but C does not do it. People have tried to make better programming languages than C but often make it worse in many ways. < 1760592931 417400 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :Algol 60 uses "ENTIER" for what modern languages call "floor" < 1760593138 469849 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :This book has a .. curious statement, trying to figure out if it's correct < 1760593254 106540 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :Yeah, it is. Just unusually written < 1760593296 798401 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :"it is useful to be aware of the relationship LOG_10 (X) = LOG_10(e) x LN (X) < 1760593319 838762 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :I'm more used to change of base being written as log_10(x) = ln(x) / ln(10) < 1760594276 173617 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :divisions are slow < 1760594291 387638 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think even floating-point divisions are slow < 1760594296 6419 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :even on modern hardware < 1760594321 22591 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so a performance-minded programmer of the day would have preferred a formula that used multiplication to one that used a division < 1760594368 442961 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it isn't quite correct to constant-fold ln(x) / ln(10) into ln(x) × (1 / ln(10)) – modern compilers will do that with fast-math-like optimisations but not if compiling accurately) < 1760594400 281789 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(so if you want the better performance you have to write the 1/ln(10) manually, which is log_10(e)) < 1760594912 856594 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :I wasn't previously aware that the reciprocal switches base and argument like that, although I think it makes sense with change of base < 1760594960 107548 :Sgeo__!~Sgeo@user/sgeo PRIVMSG #esolangs :log_10(e) = ln(e)/ln(10) = 1/ln(10) < 1760595197 321435 :citrons!~citrons@alt.mondecitronne.com QUIT :Quit: Reconnecting < 1760595206 513135 :citrons!~citrons@alt.mondecitronne.com JOIN #esolangs citrons :citrons < 1760595208 968209 :citrons!~citrons@alt.mondecitronne.com QUIT :Client Quit < 1760595218 633969 :citrons!~citrons@alt.mondecitronne.com JOIN #esolangs citrons :citrons < 1760596035 712240 :Sgeo__!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1760596126 996372 :ais523!~ais523@user/ais523 QUIT :Ping timeout: 246 seconds < 1760596136 894587 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1760596145 710352 :tromp!~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb JOIN #esolangs * :Textual User < 1760596593 937417 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Floating division is 40 cycles on MMIX, which is faster than integer division but slower than other operations with floating point numbers (other than square root, which is also slow). < 1760597841 492116 :ais523!~ais523@user/ais523 QUIT :Ping timeout: 246 seconds < 1760597847 913058 :callforjudgement!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1760598970 484715 :tromp!~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1760601809 684778 :callforjudgement!~ais523@user/ais523 NICK :ais523 < 1760603416 181723 :strerror!~strerror@user/strerror PRIVMSG #esolangs :TIL, MMIX has cycle counts? < 1760604273 56381 :strerror!~strerror@user/strerror PRIVMSG #esolangs :Right, there's a page for it in the MMIX document. (On a physical architecture, this would be much longer.) < 1760605411 743883 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ironically modern processors don't have cycle counts in the traditional sense, due to all the out-of-order stuff going on < 1760605435 263042 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the closest you can get is a minimum latency, but if you try to use it like a traditional cycle count you'll get completely the wrong result > 1760608100 830614 PRIVMSG #esolangs :14[[07Sigq14]]4 10 02https://esolangs.org/w/index.php?diff=166117&oldid=165586 5* 03TheSpiderNinjas 5* (+60) 10 < 1760608218 339267 :tromp!~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb JOIN #esolangs * :Textual User < 1760610750 654686 :APic!apic@apic.name PRIVMSG #esolangs :HI * > 1760610941 17525 PRIVMSG #esolangs :14[[07User:NoWhy14]]4 M10 02https://esolangs.org/w/index.php?diff=166118&oldid=165938 5* 03NoWhy 5* (+37) 10link to personal drafts < 1760611812 493115 :strerror!~strerror@user/strerror PRIVMSG #esolangs :The MMIX document already knows about pipelining: “we must remember that the actual running time might be quite sensitive to the ordering of instructions. For example, integer division might cost only one cycle if we can find 60 other things to do between the time we issue the command and the time we need the result …” < 1760611893 490300 :strerror!~strerror@user/strerror PRIVMSG #esolangs :And the meta-simulator can simulate “… such things as caches, virtual address translation, pipelining and simultaneous instruction issue, branch prediction, etc.” But not OOO execution. < 1760612143 600757 :strerror!~strerror@user/strerror PRIVMSG #esolangs :But OOO also causes problems, including security problems, and we might get rid of it eventually. I think GPU architectures still don't bother with it. < 1760612355 548774 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's unlikely to be dropped in CPUs any time soon – the last serious attempt to get rid of it almost destroyed Intel < 1760612394 808112 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and it isn't nearly as bad as speculative execution when it comes to security issues) < 1760612445 748414 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :today's compilers wouldn't work very well without OOO and yet they're pretty entrenched, so no big CPU manufacturer is likely to take a risk on trying to change their CPUs in a way that would invalidate all the existing compiler technology < 1760612586 407988 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the other big advantage of OOO is that it allows commands to take variable lengths of time to run without losing most of the optimisation opportunity from pipelining them correctly < 1760612593 121972 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"the last serious attempt to get rid of [out of order execution] almost destroyed Intel" => do you mean the I64 architecture or the low powered x86 cpus with the simpler pipeline? < 1760612614 89438 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: i64 – Pentium IV was earlier and Intel mostly survived it < 1760612680 318436 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :OOO seems unavoidable for systems that have hardware-managed caches to run at top speed – you'd have to explicitly do the cache management in software without it < 1760612704 738592 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which GPU programs do actually do, but for CPU programs you'd have to change all the existing source, not just the compilers < 1760612794 931693 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I mean Intel Atom, not pentium 4 < 1760612828 511819 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, I'm not too familiar with the intentionally low-powered Intel processors < 1760612843 461506 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I vaguely remember that later versions of the Atom added it back? < 1760612848 915259 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes < 1760612868 178783 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in which case the attempt can be said to have failed < 1760613437 916878 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I wonder, perhaps in a CPU architecture unlike x86, where you have lots of registers and so most instructions don't read or write the main memory with the cache hierarchy so there are separate memory read/write instructions, could you have something like x87 where you can split memory reads explicitly to two instructions, one that initiates the memory read and one that waits for it to complete and gives < 1760613443 927237 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :you access to the value read? then you could perhaps have no out of order execution other than that and maybe some similarly split slow multiplication/division/square root instructions < 1760613608 249986 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I discussed a CPU design like that in here a while ago (probably years ago now) < 1760613621 408270 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :where the idea is that instructions state a time by which the result is needed < 1760613652 598725 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and this is used to automatically route the result to the correct instruction, because you say "this result is the input is to the 10th-next instruction" or the like) < 1760613710 489951 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's most important for jumps because you can use it to avoid speculative execution (potentially entirely, if the delayed-goto happens early enough) < 1760613751 728274 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I see < 1760613797 949338 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :perhaps you can even have small register arrays that are larger than 64 bytes but you can only use piecewise or rotate, so that you don't have to access memory that often < 1760613828 801037 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think something like that is valuable for spills < 1760613843 962246 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :especially in recursive code < 1760613865 461331 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(non-recursive code can spill into statics, and IIRC were even commonly compiled that way a long time ago) < 1760614084 482582 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I mean it could be useful even in cases where they don't spill, just have a fixed size. Today on x86 you just rely on the well working L1 cache for that. < 1760614121 840877 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :with indexed memory access which almost all instructions can do with one operand < 1760614178 629026 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :AMD Zen 2 and Zen 4 (but not Zen 3) are able to access spill slots as though they were registers (same performance characteristics), which is interesting < 1760614202 168291 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and seems like the same sort of thing in reverse (possibly a means of repurposing syntax that compilers already generate) < 1760614393 657632 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I see < 1760614500 714076 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I'm also thinking of 6502 which has zero page memory access as sort of a replacement for registers, even though memory accesses all take the same amount of time regardless of the address, but the zero page can still save a cycle or two of fetching the instruction. < 1760614544 933526 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but I think in a modern architecture you don't want that zero page to be modifiable by normal memory access instructions < 1760614567 401424 :tromp!~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1760614617 283272 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 252 seconds < 1760614620 319603 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1760614699 510659 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life < 1760614736 888669 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, the 6502 is often used with very constrained memory < 1760614760 59550 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the zero page might be a significant proportion of the memory you have, so you might want to be able to put normal variables there in addition to registers < 1760614773 743819 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(especially as 256 registers is more than most programs will need) < 1760614835 78388 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it was very common to store data in static addresses in the range that hardware uses for the stack, and just try to keep the stack usage low enough that the data wouldn't be overwritten < 1760615234 105956 :int-e!~noone@int-e.eu PRIVMSG #esolangs :`' thursday < 1760615236 737159 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :352) as always in sweden everything goes to a fixed pattern: thursday is queueing at systembolaget to get beer and schnaps, friday is pickled herring, schnaps and dancing the frog dance around the phallos, saturday is dedicated to being hung over \ 821) no christmas without christ, no thursday without thor > 1760615785 626298 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 upload10 02 5* 03Zapcircuit 5* 10uploaded "[[02File:Subscratch handdrawn.png10]]" < 1760616662 836685 :int-e!~noone@int-e.eu PRIVMSG #esolangs :so apparently a "tiny" model has several millions of parameters < 1760616764 194234 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(cf. https://arxiv.org/abs/2510.04871 which is retro in another fun way: They found that if they go above 2 layers (so 1 hidden layer) they suffer from overfitting.) < 1760617429 646234 :int-e!~noone@int-e.eu PRIVMSG #esolangs :But really "tiny* should be reserved for models that are way closer to https://en.wikipedia.org/wiki/Caenorhabditis_elegans in size (it features a "brain" made of 302 neurons) < 1760617794 177151 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :The model I'm using for esolangs is gemma-2.0-2b-it-sfp, which has 2 billion parameters, and I thought that too is considered "relatively small". It was the smallest Gemma 2 variant they had. < 1760617797 435881 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Though looks like since then they've released Gemma 3, which comes in 270M/1B/4B/12B/27B size variants. < 1760617852 71905 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1760617925 45470 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :It's also got a longer context window (32k for 270M/1B sizes, 128k for 4B/12B/27B sizes, compared to 8k for Gemma 2), so I could fit more wiki text in (and make it even slower). < 1760617947 988816 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :(Really, though, if I wanted it to produce actually useful wiki-derived responses, it's the retrieval part that needs more work.) > 1760618186 249773 PRIVMSG #esolangs :14[[07Subscratch14]]4 N10 02https://esolangs.org/w/index.php?oldid=166120 5* 03Zapcircuit 5* (+12709) 10Created page with "'''subscratch''' is an [[OISC]] language invented by User:Zapcircuit. its main purpose is for codegolfing games in [[scratch]]. its most interesting feature is its scratch implementation, which uses very few scratch blocks. ==implementation== to the right is an > 1760618256 840217 PRIVMSG #esolangs :14[[07Subscratch14]]4 10 02https://esolangs.org/w/index.php?diff=166121&oldid=166120 5* 03Zapcircuit 5* (+4) 10 > 1760618497 475478 PRIVMSG #esolangs :14[[07Subscratch14]]4 10 02https://esolangs.org/w/index.php?diff=166122&oldid=166121 5* 03Zapcircuit 5* (+8) 10/* execution */ > 1760618561 544657 PRIVMSG #esolangs :14[[07Subscratch14]]4 10 02https://esolangs.org/w/index.php?diff=166123&oldid=166122 5* 03Zapcircuit 5* (+1) 10/* execution */ > 1760619187 454781 PRIVMSG #esolangs :14[[07Subscratch14]]4 10 02https://esolangs.org/w/index.php?diff=166124&oldid=166123 5* 03Zapcircuit 5* (+20) 10/* i/o */ > 1760619412 532009 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Sadran 5* 10New user account > 1760619416 907895 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=166125&oldid=165996 5* 03Zapcircuit 5* (+17) 10/* S */ < 1760619708 434547 :tromp!~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb JOIN #esolangs * :Textual User > 1760619945 570968 PRIVMSG #esolangs :14[[07Subscratch14]]4 10 02https://esolangs.org/w/index.php?diff=166126&oldid=166124 5* 03Zapcircuit 5* (+228) 10 > 1760620051 510227 PRIVMSG #esolangs :14[[07Subscratch14]]4 10 02https://esolangs.org/w/index.php?diff=166127&oldid=166126 5* 03Zapcircuit 5* (+9) 10 > 1760620471 306574 PRIVMSG #esolangs :14[[07Subscratch14]]4 10 02https://esolangs.org/w/index.php?diff=166128&oldid=166127 5* 03Zapcircuit 5* (+64) 10/* i/o */ > 1760620644 410523 PRIVMSG #esolangs :14[[07Subscratch14]]4 M10 02https://esolangs.org/w/index.php?diff=166129&oldid=166128 5* 03Zapcircuit 5* (-1) 10/* i/o */ < 1760621370 597157 :Everything!~Everythin@46.96.48.125 JOIN #esolangs Everything :Everything < 1760622105 936594 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :strerror: Right. On a GPU (at least the 2000s-era ones I know well) instructions can't really be reordered because they're being executed in parallel on multiple data. Instead the GPU has a bitmask which indicates the result of the most recent comparison, and that mask is used to disable execution for some of the parallel lanes whenever a comparison fails. < 1760622217 201189 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The "speed" is wholly from parallelism; in my mind a GPU only goes at maybe 300-350 MHz of clock, maybe 1/10 of the main CPU's clock, and also there's a 30% or so slowdown just from the overhead of transferring data over PCI/AGP/etc. This means you'd better have a batch of at least 10 items *and* a non-trivial workload before the GPU is worth it. < 1760622253 668174 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(Highly likely that you know all this. But maybe some lurker does not.) < 1760623946 799127 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1760627120 27068 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Excess Flood < 1760627286 645894 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1760627539 33011 :tromp!~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1760627968 373613 :strerror!~strerror@user/strerror PRIVMSG #esolangs :Perhaps more relevantly to text, a “tiny stories” model has ~30M parameters: https://arxiv.org/abs/2305.07759v2 < 1760628087 187804 :strerror!~strerror@user/strerror PRIVMSG #esolangs :(Though a tiny model for esolangs wouldn't have a vocabulary considered suitable for bedtime stories.) > 1760628212 139156 PRIVMSG #esolangs :14[[07Syzygy14]]4 10 02https://esolangs.org/w/index.php?diff=166130&oldid=166113 5* 03Aadenboy 5* (+2) 10ordering image under infobox and moving table of contents to after the overview > 1760628282 123233 PRIVMSG #esolangs :14[[07Syzygy14]]4 10 02https://esolangs.org/w/index.php?diff=166131&oldid=166130 5* 03Aadenboy 5* (-84) 10nvm doesn't work like that. also fixing header levels < 1760628312 551398 :amby!~ambylastn@host-92-17-32-126.as13285.net JOIN #esolangs amby :realname < 1760628459 697892 :strerror!~strerror@user/strerror PRIVMSG #esolangs :korvo: I prefer to say that GPUs aren't fast, it's the von Neumann chips that are plodding along < 1760628503 768421 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :strerror: Yeah! Some days I think that the computer is actually the memory controller, and the CPU is just a peripheral ALU. < 1760628506 341709 :strerror!~strerror@user/strerror PRIVMSG #esolangs :Though even GPUs are bottlenecked by memory these days. Still hoping for CIM to become usable. They're pretty esoteric too, since everything has to be done using bitslicing. < 1760628542 859013 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :A GPU is just another peripheral on a bus. Like the CPU, it's slower than memory, and like the CPU, it will ask for lots of DMA. That's what the computer does, really: DMA all day. > 1760628568 962298 PRIVMSG #esolangs :14[[07Talk:1 Bit, a quarter byte14]]4 M10 02https://esolangs.org/w/index.php?diff=166132&oldid=165413 5* 03TheBigH 5* (+250) 10 < 1760628799 798893 :tromp!~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb JOIN #esolangs * :Textual User < 1760628801 511867 :strerror!~strerror@user/strerror PRIVMSG #esolangs :(CIM = Compute-in-memory, which adds a few extra word lines to a DRAM circuit to do elementary logic operations across a row, which typically has 64K bits or more.) < 1760629605 204672 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :CIM sounds nice, but I'm not sure how it would get rolled out to consumers. I suppose that first the memory controller would support it, then the CPUs in the next generation would use it? < 1760630018 408862 :strerror!~strerror@user/strerror PRIVMSG #esolangs :They're still working on throughput, AFAIK; DRAM is made in the DRAM factory, not the logic factory, and they're not used to making chips with fast clock rates. < 1760630057 132002 :strerror!~strerror@user/strerror PRIVMSG #esolangs :If it gets fast enough, presumably OpenAI could be counted on to buy out the first year of production. > 1760630382 836593 PRIVMSG #esolangs :14[[07User:Aadenboy/Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=166133&oldid=161119 5* 03Aadenboy 5* (-62) 10 > 1760630407 679752 PRIVMSG #esolangs :14[[07User:Aadenboy/Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=166134&oldid=166133 5* 03Aadenboy 5* (+8) 10 > 1760630420 456474 PRIVMSG #esolangs :14[[07User:Aadenboy/Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=166135&oldid=166134 5* 03Aadenboy 5* (-8) 10 > 1760630448 305722 PRIVMSG #esolangs :14[[07User:Aadenboy/Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=166136&oldid=166135 5* 03Aadenboy 5* (+27) 10 > 1760630494 859730 PRIVMSG #esolangs :14[[07User:Aadenboy/Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=166137&oldid=166136 5* 03Aadenboy 5* (+35) 10revert < 1760631917 340584 :JGardner!sid553797@user/meow/Wryl NICK :jgardner < 1760635215 838212 :joast!~joast@2603:90d8:500:31cf:5e0f:3f4b:1cfe:5060 QUIT :Quit: Leaving. < 1760636638 79337 :tromp!~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1760637455 747707 :Everything!~Everythin@46.96.48.125 QUIT :Quit: leaving < 1760638925 546121 :amby!~ambylastn@host-92-17-32-126.as13285.net QUIT :Read error: Connection reset by peer < 1760638943 557576 :amby!~ambylastn@host-92-17-32-126.as13285.net JOIN #esolangs amby :realname > 1760641990 421748 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=166138&oldid=146912 5* 03Ractangle 5* (-62) 10/* Commands */ > 1760642025 874568 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=166139&oldid=166138 5* 03Ractangle 5* (+0) 10/* Syntax */ > 1760642455 299129 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=166140&oldid=166139 5* 03Ractangle 5* (-41) 10/* Syntax */ < 1760643166 736197 :sorear_!sid184231@id-184231.uxbridge.irccloud.com JOIN #esolangs sorear :sorear < 1760643418 934855 :sorear!sid184231@id-184231.uxbridge.irccloud.com QUIT :Ping timeout: 248 seconds < 1760643420 262575 :sorear_!sid184231@id-184231.uxbridge.irccloud.com NICK :sorear > 1760644643 680845 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=166141&oldid=166140 5* 03Ractangle 5* (-56) 10/* Truth-machine */ > 1760645106 966065 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=166142&oldid=166141 5* 03Ractangle 5* (-47) 10/* Cat program */ > 1760645425 645215 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=166143&oldid=166142 5* 03Ractangle 5* (-30) 10/* Syntax */ > 1760645514 442743 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=166144&oldid=166143 5* 03Ractangle 5* (+157) 10/* Interpreter */ > 1760645665 841037 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=166145&oldid=166144 5* 03Ractangle 5* (+11) 10/* Interpreter */ > 1760645783 383175 PRIVMSG #esolangs :14[[07Talk:8ial14]]4 N10 02https://esolangs.org/w/index.php?oldid=166146 5* 03Ractangle 5* (+295) 10Created page with "ok this time Kaveh you don't need to apoligise because of the fact your interpriter as of 16th of October has outdated specifactaions~~~" > 1760645868 137372 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=166147&oldid=166145 5* 03Ractangle 5* (+73) 10 > 1760646216 23485 PRIVMSG #esolangs :14[[07User:EZ132/std1ib.h14]]4 N10 02https://esolangs.org/w/index.php?oldid=166148 5* 03EZ132 5* (+3224) 10Created page with "'''std1ib.h''' is the header file that defines [[User:EZ132/Not C++|Not C++]].
 #include  #include  #include  #include  #include  #include   // delimiters & blocks #define def #define def
> 1760646245 461802 PRIVMSG #esolangs :14[[07User:EZ132/Not C++14]]4 N10 02https://esolangs.org/w/index.php?oldid=166149 5* 03EZ132 5* (+3241) 10Created page with "'''Not C++''' (name provisional) is a programming language that is not [[C++]]. It can be compiled trivially into C++. ==Design & History== Not C++ is essentially C++ modified with a header file currently referred to as std1ib.h. This header consis
< 1760647022 351236 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Many languages have ternary. Algol-68 has abbreviated if elif else chains:
< 1760647023 458934 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :INT p = (c="a"|1|:c="h"|2|:c="q"|3|4)
< 1760647050 682564 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Hmm I guess ternary can be used similarly anyway depending on precedence
< 1760647069 704208 :joast!~joast@2603:90d8:500:31cf:5e0f:3f4b:1cfe:5060 JOIN #esolangs joast :joast
< 1760647831 510754 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1760647896 915526 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: hi! I haven't Internet-seen you in ages
< 1760648643 396785 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : (CIM = Compute-in-memory, which adds a few extra word lines to a DRAM circuit to do elementary logic operations across a row, which typically has 64K bits or more.) ← now I'm imagining a very big embarrassingly-parallel vector calculation running across DRAM refresh cycles
< 1760648674 593219 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, the simplest version of this would be a mass zero in which you can tell the memory controller "please zero this block of memory for me" – that would probably be useful even on its own
< 1760648764 272782 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I still remember the discussions about background zeroing of non-allocated memory using, effectively, the kernel idle process (Linux doesn't do it because of cache pollution, although there have been discussions about doing it using nontemporal writes)
< 1760648780 733422 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but just having the memory do it effectively instantly would bypass all those issues
< 1760648838 292835 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : korvo: I prefer to say that GPUs aren't fast, it's the von Neumann chips that are plodding along ← it makes more sense to think of speed in terms of latency and throughput rather than as a single figure: GPUs have massive throughput but aren't very good at latency
< 1760649251 431093 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I had thought of computer design in many ways, and I  also thought that it should avoid out of order execution, in the ways that is mentioned (and also to possibly make it simpler by not implementing out of order execution; the compiler can (hopefully) set up the order properly). I did not consider CIM but it also has some uses
< 1760649390 89586 :salpynx!~salpynx@121.98.105.4 JOIN #esolangs salpynx :realname
< 1760649488 737315 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :IMO the Basic Stack TC proof is basically correct. int-e already pointed out the problems with it: 1) misses the data string setup (trivial to do with `push 1`, and obviously required for the rest to work, use `goto 2` for the loop) 2) Technically is using CT not BCT. The table is simple-translation of CT into BCT into Basic Stack, 3) the `istop;stop` is redundant on the 1x commands, but doesn't break anything. Other than that, it seems a valid idea. I 
< 1760649489 81759 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :had a play with the interpreter, and with an initial data string, it runs BCT examples with deletion replaced with a moving pointer, so functionally equivalent. It feels like it was designed for this.
< 1760649525 358034 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :int-e: The BCT subtlety is a good observation. I worry I may have this mistake in the past. At first I couldn't see why it might be useful, but it looks like the effect is running one set of productions once, then looping on the offset productions, which could be useful for some clever run-once setup code.
< 1760649526 537227 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: could you just ask the GPU to do zeroing? or maybe CPUs could add background zeroing logic at the L3 cache?
< 1760649587 152758 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :salpynx: I don't think it correctly implements a queue, the "push reg" command is intended to dequeue a queue but it pushes the address of the element it's dequeuing (with no way to dereference it), not the element itself
< 1760649629 874535 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: it increments `reg`
< 1760649639 692289 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I'm not sure what the situation with GPUs accessing CPU memory is like at the moment – it may vary a lot based on the motherboard (I know that some computers make it efficient but most don't)
< 1760649640 515001 :int-e!~noone@int-e.eu PRIVMSG #esolangs :which points to the start of the queue on the stack
< 1760649651 792880 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: yes, reg is a pointer to the start of the queue on the stack, but the language has no way to read through the pointer
< 1760649690 414901 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: condr does that
< 1760649691 251950 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :knowing where the front of a queue is is not enough to be able to dequeue and branch on the dequeued element, you need to be able to actually read the element in question
< 1760649719 538555 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :there is a `push 1` `push 0`  which works for the CT emulation 
< 1760649721 225708 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: ah, you're right – that was the bit I was missing
< 1760649736 446790 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it looks like that instruction was added specifically to make it non-bignum TC?
< 1760649835 975268 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: yeah, it makes the stack "transparent" as the top of the page puts it
< 1760649877 554814 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :ais523: I wasn't sure what bit you were missing, but sounds like int-e revealed it :) 
< 1760649911 428562 :APic!apic@apic.name PRIVMSG #esolangs :cu
< 1760649941 722364 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :int-e: your comments made me think that "Binary Encoded Cyclic Tag" _is_ a useful thing if 2 symbol encoding is the constraint. That makes something like 101001 valid BCT but a syntax error in "Binary Encoded Cyclic Tag".
< 1760649962 386761 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :Failing on e.g. 101001 might be a common gotcha for BCT interpreters (if anything about BCT interpreters can ever be called 'common'). Something to test, like Deadfish 256 handling.
< 1760650005 120601 :int-e!~noone@int-e.eu PRIVMSG #esolangs :salpynx: The thing is that the first 0 in a program synchronizes everything so the feature is of very limited use.
< 1760650030 84799 :int-e!~noone@int-e.eu PRIVMSG #esolangs :salpynx: it's more of a wart ;)
< 1760650040 184142 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :The setup / init code possibility is interesting
< 1760650058 342216 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I dislike the way that bitwise cyclic tag became the default, a much better option is "cyclic tag and invent your own syntax for it"
< 1760650067 670009 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :A simple example shows this kind of behaviour : BCT: 101001 = 10 10 0 (11 0 10 0)* , in CT:  0 0; (1; 0;)*     (apologies for ad-hoc mixed notation, hopefully it's esotericly clear enough)
< 1760650070 576718 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(for TCness proofs, at least)
< 1760650163 693461 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :I think the wiki page contributes to that problem, BCT is explained in more detail, and has clearer examples. I've used that, and am probably guilty of defaulting to BCT numerous times in the past
< 1760650173 305409 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :cyclic tag effectively having three symbols is awkward sometimes, but BCT doesn't really fix that problem
< 1760650202 832493 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(this was the major motivation behind inventing https://esolangs.org/wiki/Echo_Tag https://esolangs.org/wiki/Grill_Tag, which each genuinely can be expressed using two symbols)
< 1760650209 126423 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :*Echo Tag and Grill Tag
< 1760650242 458913 :vista_user!~vista_use@user/DOS-User:11249 JOIN #esolangs DOS_User :[https://web.libera.chat] vista_user
< 1760650349 913727 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :The ; in CT is like a newline, if you think of the code as a finite list of 2 symbol productions, and deletion occurs by default as part of the process 
< 1760650580 682256 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :Hm, Echo Tag is categorized as 'unimplemented'. That might be a fun one to do. 
< 1760650593 869258 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :when talking to people who don't know how cyclic tag works already, I usually explain it as a program formed of "pop the top element, then push this string if the popped element wasn't 0"
< 1760650624 182181 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Echo Tag's a bit weird because it's been manually compiled into a lot but I'm not sure that there's an automated compiler yet
< 1760650630 291698 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, manually compiled from a lot
< 1760650658 541424 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :Has it been used in a TC proof for something else?
< 1760650723 945674 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes
< 1760650738 980623 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :base 10 Addition Automaton, at least
< 1760650744 575277 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :https://esolangs.org/wiki/Addition_Automaton
< 1760650861 455566 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :that's a totally new one to me, I'd a least recognised the names of the other * Tags
< 1760650972 543036 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :the numeric output is visually interesting, you can see the structure in the digits. nice.
< 1760650993 646977 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :numeric tartan
< 1760650997 493257 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the way I think about it is that almost all TC languages can trivially emulate either a counter machine or a tag system, and so making TC proofs easier is mostly accomplished by making easier-to-implement counter machines and easier-to-implement tag systems
< 1760651234 647638 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :I've always felt that there is a lack of confirmation example programs in tag systems or counter-machine to concretely verify a conversion.  
< 1760651255 749050 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :part of the issue is that natively written tag is incredibly slow
< 1760651257 636455 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :The BCT wiki page example gets used a lot , I've used it and someone else did recently
< 1760651267 915144 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you need an optimising interpreter to be able to run it
< 1760651288 759375 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :Yeah
< 1760651361 552745 :tromp!~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb JOIN #esolangs * :Textual User
< 1760651365 996627 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :I'm pretty sure I've written a 'hello world' in 2 reg Minsky machine and was going to figure out how to make an optimising interpreter to let it complete
< 1760651420 817236 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :I got distracted by the various MM notations, and how they weren't quite set up for 2-reg
< 1760651512 706805 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :That's right, I convinced myself PMMN was not TC for 2 registers, then decided it was, but not in the obvious way
> 1760651533 509705 PRIVMSG #esolangs :14[[07Bitwise Cyclic Tag14]]4 10 02https://esolangs.org/w/index.php?diff=166150&oldid=101531 5* 03Ais523 5* (+146) 10/* Example (Collatz sequence) */ credit where this example comes from
< 1760651552 350449 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that example is used so much we should properly credit it to the original author
< 1760652007 97677 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :For cyclic tag examples I created this BASIC inspired fantasy console idea with an data-string output encoding: https://esolangs.org/wiki/CTBASIC and Tektronix 4010 graphical output for a retro vibe
< 1760652024 356499 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :Not sure I've written it up well enough to do it justice
< 1760652145 739960 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :There's a pre-calculated rotating cube example that runs using cyclic tag .... it's just output but it cycles over distinct animation frames 
< 1760652207 398392 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(very) recently I've been interested in the question of compilations that run quickly in naive tag interpreters
< 1760652209 457847 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :I never quite figured out how to do more complex arbitrary conditional branching in CT
< 1760652252 34724 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think running a program at a speed that's n log(n) slower than the original is possible (I have a sketch proof at https://esolangs.org/wiki/Globe but the details of both halves are missing)
< 1760652281 286797 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :do you mean finding useful algorithms that run well in tag systems, or something else?
< 1760652292 897801 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a compilation scheme, e.g. Turing machine to tag system
< 1760652300 155535 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which doesn't lose any more performance than necessary
< 1760652309 406809 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :aha
< 1760652320 125773 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :efficient translations
< 1760652320 492963 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :almost all tag system TCness proofs go via counter machines and store the counters exponentially, so you get a double-exponential slowdown
< 1760652355 762960 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although one of the exponentials is fairly to remove with an optimising interpreter)
< 1760652369 617672 :vista_user!~vista_use@user/DOS-User:11249 PRIVMSG #esolangs :nice to see another user in the wiki wjho likes basic tho
< 1760652412 643209 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :I guess that's what I was trying to figure out with CTBASIC, how to implement higher level programming concepts (mostly)directly.
< 1760652421 285074 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :BASIC was my first programming language
< 1760652632 883237 :vista_user!~vista_use@user/DOS-User:11249 PRIVMSG #esolangs :ais523: same...well technicakly it was batch but only dir and cd, as a language i actually coded in itwas basic (and a bunch of hopping on python for like 3 days then leaving it for 3 months then back then out ad nauseam))
< 1760652719 310363 :vista_user!~vista_use@user/DOS-User:11249 PRIVMSG #esolangs :blame me being too busy doing weird shit in a c64 emulator i got just for the games and ended up using for peek and poke shitfsckery to even bother with python for a while
< 1760652745 965748 :salpynx!~salpynx@121.98.105.4 PRIVMSG #esolangs :Getting more direct high level effects in tag systems tends to blow up the number of productions required, that seems to be the trade off. They can be easily generated following simple rules, but they take up space.
< 1760653351 513540 :ais523!~ais523@user/ais523 QUIT :Ping timeout: 256 seconds
< 1760653369 914926 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1760654111 357876 :vista_user!~vista_use@user/DOS-User:11249 QUIT :Remote host closed the connection
< 1760654273 557883 :ajal!~ambylastn@host-92-17-32-126.as13285.net JOIN #esolangs * :realname
< 1760654307 660152 :amby!~ambylastn@host-92-17-32-126.as13285.net QUIT :Remote host closed the connection
< 1760654307 767269 :salpynx!~salpynx@121.98.105.4 QUIT :Remote host closed the connection
> 1760655423 92703 PRIVMSG #esolangs :14[[07User:Quito056714]]4 10 02https://esolangs.org/w/index.php?diff=166151&oldid=154435 5* 03Quito0567 5* (+18) 10
> 1760655452 32279 PRIVMSG #esolangs :14[[07User:Quito056714]]4 10 02https://esolangs.org/w/index.php?diff=166152&oldid=166151 5* 03Quito0567 5* (+5) 10
> 1760655469 300244 PRIVMSG #esolangs :14[[07User:Quito056714]]4 10 02https://esolangs.org/w/index.php?diff=166153&oldid=166152 5* 03Quito0567 5* (+2) 10
> 1760655570 134143 PRIVMSG #esolangs :14[[07Boomerlang14]]4 10 02https://esolangs.org/w/index.php?diff=166154&oldid=115671 5* 03Quito0567 5* (+14) 10
< 1760655691 810634 :jgardner!sid553797@user/meow/Wryl CHGHOST sid553797 :user/meow/jgardner
< 1760655825 265299 :tromp!~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1760656720 852698 :Lymia!~lymia@lilac.servers.aura.moe QUIT :Quit: zzzz <3
> 1760656747 872386 PRIVMSG #esolangs :14[[07?brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=166155&oldid=166089 5* 03HyperbolicireworksPen 5* (+120) 10changed 5/8,1;/14,2;1/8,3 added infinite series stuff as well
< 1760656755 272811 :Lymia!~lymia@lilac.servers.aura.moe JOIN #esolangs Lymia :Lymia Aluysia
> 1760656820 960893 PRIVMSG #esolangs :14[[07?brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=166156&oldid=166155 5* 03HyperbolicireworksPen 5* (-1) 10counted stuff
> 1760656858 754017 PRIVMSG #esolangs :14[[07?brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=166157&oldid=166156 5* 03HyperbolicireworksPen 5* (-1) 10
> 1760656872 536254 PRIVMSG #esolangs :14[[07?brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=166158&oldid=166157 5* 03HyperbolicireworksPen 5* (-1) 10
> 1760657415 192346 PRIVMSG #esolangs :14[[07?brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=166159&oldid=166158 5* 03HyperbolicireworksPen 5* (+153) 10
< 1760658170 922085 :avih!~quassel@23.94.231.119 PART :#esolangs
< 1760658712 693592 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: That's another solid way to look at GPUs, yeah.
< 1760658738 409945 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :sorear: Oh hi! Sorry I haven't been on top of that Busy Beaver stuff. Feel free to ping me if I'm blocking progress.