00:37:00 -!- ais523 has joined.
00:45:57 <esolangs> [[Semi-serious language list]] https://esolangs.org/w/index.php?diff=170595&oldid=170552 * Ais523 * (-4) redefine "original" a bit to prevent an obscure language + a number of trivial derivatives of it all being posted together (AFAICT, nobody is doing this maliciously, but it has occasionally happened by accident)
00:46:38 <esolangs> [[Semi-serious language list]] https://esolangs.org/w/index.php?diff=170596&oldid=170595 * Ais523 * (+1) clarify my previous edit slightly if a language and its derivatives are both on the list we should keep the original
00:57:10 <esolangs> [[Semi-serious language list]] https://esolangs.org/w/index.php?diff=170597&oldid=170596 * Ais523 * (-128) remove: Ambient Techno, Flooding Waterfall Model (derivatives of older languages on the list); efghij, High Rise, StackFlow (no implementation or external resource); Vague (not sufficiently well specified to confidently consider it Turing-complete)
01:04:38 <esolangs> [[Semi-serious language list]] https://esolangs.org/w/index.php?diff=170598&oldid=170597 * Ais523 * (+61) tone down the "derivatives" restriction slightly (and restore part of it that got deleted by mistake) this allows re-adding Flooding Waterfall Model and means that some of the existing derivatives can be kept; also reword the intro to be less boldface-instructi
01:56:51 <esolangs> [[User:Timm]] https://esolangs.org/w/index.php?diff=170599&oldid=170488 * Timm * (+4)
02:42:29 <esolangs> [[Talk:DTM]] N https://esolangs.org/w/index.php?oldid=170600 * Ytebbit * (+466) /* Request to delete user and page */
02:44:13 <esolangs> [[Esolang:Candidates for deletion]] M https://esolangs.org/w/index.php?diff=170601&oldid=170496 * Corbin * (+34) /* Articles for deletion */
03:05:02 -!- op_4 has quit (Remote host closed the connection).
03:05:34 -!- op_4 has joined.
03:17:43 -!- amby has quit (Remote host closed the connection).
03:22:58 -!- impomatic has joined.
03:56:54 -!- impomatic has quit (Quit: Client closed).
05:53:16 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=170602&oldid=170540 * RainbowDash * (+354) /* Category:Branchless paradigm */
05:56:05 <esolangs> [[Lacc]] https://esolangs.org/w/index.php?diff=170603&oldid=170582 * Yayimhere2(school) * (+3) /* Command set */
05:58:09 <esolangs> [[Mutt Machine]] https://esolangs.org/w/index.php?diff=170604&oldid=170535 * RainbowDash * (+13) Console
06:03:46 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=170605&oldid=170589 * PrySigneToFry * (+1198)
06:47:00 -!- pool has quit (Ping timeout: 256 seconds).
06:52:04 -!- pool has joined.
07:21:17 -!- chomwitt has joined.
08:00:07 -!- tromp has joined.
08:14:58 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=170606&oldid=170605 * None1 * (+153) /* Commands */
08:16:02 <esolangs> [[UserEdited]] M https://esolangs.org/w/index.php?diff=170607&oldid=170606 * None1 * (+1) /* Commands */
08:18:32 <esolangs> [[]] M https://esolangs.org/w/index.php?diff=170608&oldid=164359 * None1 * (+1) /* Type 78 */
08:21:16 <esolangs> [[]] https://esolangs.org/w/index.php?diff=170609&oldid=170608 * None1 * (+41) /* Interpreters */
08:21:40 <esolangs> [[]] M https://esolangs.org/w/index.php?diff=170610&oldid=170609 * None1 * (+0) /* Type 78 */
08:23:46 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
08:28:51 -!- tromp has joined.
09:27:53 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
10:08:01 -!- tromp has joined.
11:53:37 <esolangs> [[User:JHSHernandez-ZBH]] https://esolangs.org/w/index.php?diff=170611&oldid=154637 * JHSHernandez-ZBH * (-70)
11:56:30 <esolangs> [[Main Page]] M https://esolangs.org/w/index.php?diff=170612&oldid=170268 * JHSHernandez-ZBH * (-4) a grammar correction, and two content shortenings (also why is this not protected)
12:08:44 <esolangs> [[Contains everything]] https://esolangs.org/w/index.php?diff=170613&oldid=169078 * C++DSUCKER * (+284)
12:13:44 <esolangs> [[!INTERNET]] M https://esolangs.org/w/index.php?diff=170614&oldid=162588 * JHSHernandez-ZBH * (-41) /* Operators */
12:13:59 <esolangs> [[!INTERNET]] M https://esolangs.org/w/index.php?diff=170615&oldid=170614 * JHSHernandez-ZBH * (+4) /* Operators */
12:15:06 <esolangs> [[!INTERNET]] M https://esolangs.org/w/index.php?diff=170616&oldid=170615 * JHSHernandez-ZBH * (+22)
12:15:23 <esolangs> [[!INTERNET]] M https://esolangs.org/w/index.php?diff=170617&oldid=170616 * JHSHernandez-ZBH * (+0) /* Operators */
12:25:42 <esolangs> [[Verbose]] M https://esolangs.org/w/index.php?diff=170618&oldid=75157 * JHSHernandez-ZBH * (+399) i will make the remaining paragraphs verbose later
12:26:45 <esolangs> [[Verbose]] M https://esolangs.org/w/index.php?diff=170619&oldid=170618 * JHSHernandez-ZBH * (+73)
12:26:50 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
12:27:09 <esolangs> [[INTERCAL]] https://esolangs.org/w/index.php?diff=170620&oldid=162236 * JHSHernandez-ZBH * (+4)
12:31:13 -!- Sgeo has quit (Read error: Connection reset by peer).
13:17:38 -!- tromp has joined.
14:29:19 -!- impomatic has joined.
15:35:59 -!- jack7087 has joined.
15:45:37 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=170621&oldid=170591 * Susam * (+18) /* C */ add
16:10:10 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:15:55 <esolangs> [[INTERCAL]] https://esolangs.org/w/index.php?diff=170622&oldid=170620 * Ais523 * (-4) Undo revision [[Special:Diff/170620|170620]] by [[Special:Contributions/JHSHernandez-ZBH|JHSHernandez-ZBH]] ([[User talk:JHSHernandez-ZBH|talk]]) it is an abbreviation according to the manual
16:53:48 <esolangs> [[Langton's ant]] https://esolangs.org/w/index.php?diff=170623&oldid=168768 * Corbin * (+1946) References and theorems.
17:02:36 -!- ais523 has quit (Quit: quit).
17:03:58 -!- chomwitt has quit (Remote host closed the connection).
17:04:17 -!- chomwitt has joined.
17:09:04 -!- ais523 has joined.
17:14:26 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=170624&oldid=170602 * RainbowDash * (+96) whatever i dont want to date this correctly i forgot to add this
17:14:55 <esolangs> [[Langton's ant]] https://esolangs.org/w/index.php?diff=170625&oldid=170623 * Corbin * (+188) Many conventions for the non-technical parts. This is an FA candidate, right?
17:31:13 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=170626&oldid=170624 * Ais523 * (+1410) /* Category:Branchless paradigm */ discussion about paradigmness and predication
17:32:49 <ais523> the term "local cellular automaton" seems vaguely wrong to me
17:33:00 <ais523> in that in a 1D setting that would just be "Turing machine"
17:33:16 <ais523> you could just as easily describe Langton's Ant as a 2-dimensional Turing machine, but I don't think that's common terminology
17:34:42 <ais523> also the computational class section of that article is a mess
17:35:07 <ais523> it cites the same paper four times and has results in "upper bounds" and "lower bounds" sections which are all actually lower bounds
17:35:08 <korvo> ais523: I'm very open to better terminology. The interesting part is the contrast with globally-applied rules like in Life.
17:35:25 <ais523> korvo: the interesting part to me is that this seems to be a terminology gap
17:35:42 <ais523> it has exactly the same relationship to 2D cellular automata as Turing machines do to 1D cellular automata
17:35:54 <b_jonas> ais523: they didn't exist back when Turing-machines were invented, but we now have VCRs which use a 2-dimensional magnetic tape, so we can probably still call the two-dimensional ones Turing-machines. Now three-dimensional would be harder, at least if it has more than the two layers of a double-layer DVD.
17:35:56 <korvo> Hey, it was a productive paper. I can treat them all as lower bounds, but I'm also a Church-Turing believer.
17:36:21 <b_jonas> nah, I guess even a floppy disk has a two-dimensional magnetic tape
17:36:42 <ais523> well, regardless of whether you believe in Church-Turing or not, it should be fairly obvious that Langton's Ant isn't uncomputable unless you cheat with the initial conditions
17:36:50 <ais523> if the initial conditions are computable, so is the language as a whole
17:38:15 <ais523> b_jonas: VCR tape is really interesting because it's storing a one-dimensional sequence of data, but in order to fit a long sequence onto a relatively short tape, it uses a short but wide tape and effectively writes the data in a space-filling curve (with discontinuities but that doesn't change the essential nature of it)
17:38:52 <ais523> and this makes it non-obvious whether it counts as 1-dimensional or 2-dimensional
17:39:01 <korvo> That's a good point. GMG don't require that the initial lattice is computable.
17:39:36 <ais523> almost anything is uncomputable if you allow uncomputable initial conditions
17:39:59 <b_jonas> ais523: kind of, but I think there's some magic in there that I don't quite understand where it might synchronize the wraparound with the vertical sync of the video signal. I don't understand how that can work because there's only one VCR format and it can store both PAL and NTSC television.
17:40:34 <b_jonas> ok, admittedly there's more than one VCR formats, I think there's something like double speed, but that's not about PAL versus NTSC
17:40:37 <ais523> b_jonas: if you fast-forward a VCR that might help you understand better
17:40:57 <ais523> the basic idea is that there's a discontinuity whenever the recorded track reaches the edge of the tape
17:41:10 <ais523> the recorded track is shaped like ////// but with much steeper slashes
17:41:32 <ais523> the 50Hz versus 60Hz just changes the angle of the slashes, which can be done by changing how fast the tape head moves
17:42:11 <ais523> and if you time it correctly the discontinuity always happens during vblank, a time at which the screen is ignoring every signal sent to it
17:42:51 <ais523> but, if you're fast-forwarding, you get the first half of one frame and second half of the next (or more if running at ×3 or ×4 speed) and you can see the discontinuity on screen when you do that, lots of garbage/random data at the point of the discontinuity
17:43:27 <b_jonas> oh, so they try to save a tiny bit of tape area by not including most of the vblank interval on the usable part of the tape?
17:43:47 <ais523> right, the vblank happens while the tape head is off the edge of the tape
17:43:55 <ais523> which both saves area and covers the discontinuity
17:45:33 <b_jonas> but isn't that kind of synchronization a bad idea because it complicates the VCR a lot and makes it less forward compatible with new extensions to the television format such as teletext or that british text caption thingy?
17:46:08 <ais523> it doesn't complicate the VCR because it needs to synchronise with vblank *anyway*, if it didn't the picture would gradually move up or down the screen
17:46:19 <ais523> (something which frequently happens in practice on misconfigured old TVs)
17:47:00 <ais523> if you wanted to capture vblank metadata like teletext, you could include that poriton of vblank in the portion that's saved to the tape – I don't know how many VCRs actually bother with that in practice
17:47:09 <b_jonas> what, why? can't it just save the raw signal as is, and that raw signal contains the information that the television uses to vertically synchronize?
17:47:17 -!- tromp has joined.
17:47:18 <ais523> it is hard to tell nowadays because VCRs are mostly obsolete and analog teletext signals aren't sent any more
17:48:29 <b_jonas> “analog teletext signals” hehe… I mean they're uncompressed digital teletext signals for uncompressed analog televison, so that makes sense, we don't even have any analog television broadcasts anymore, probably to save on EM frequency space
17:48:37 <ais523> b_jonas: I think maybe if you just want playback to work? but normally people want pause/fast forward/rewind to work too
17:49:18 <ais523> pause is done by repeating the same frame over and over again, but that requires one slash on the tape to contain exactly one frame, not a fraction or multiple of one
17:50:08 <b_jonas> I see! image while paused or fast forwarded.
17:51:01 <b_jonas> though I can imagine another reason, which is that the vblanks use extreme values of the signal and that value can't be recorded onto the tape to save on the *value* space
17:52:23 <b_jonas> which I just saw was a problem when dwangoac was trying to digitize old videotapes with a cheap software-defined radio card with only 8 bits depths of value and that apparently destroyed the vsync on the digitization side
17:53:54 <b_jonas> (it's possible that I misunderstood that and the problem with vsync was something else
17:54:57 <b_jonas> I guess this makes sense because by the time they made VCRs, televisions could synchronize to vblank well enough, that was a commonplace mass-produced technology that they could reuse
17:56:59 <esolangs> [[BF instruction minimalization]] https://esolangs.org/w/index.php?diff=170627&oldid=167405 * Esolangist alt * (+662) Esolangist alt
18:00:11 -!- RainbowDash has joined.
18:00:32 <RainbowDash> hello, i am here to talk about branchlessness
18:00:49 <RainbowDash> it seems easier to chat on the IRC rather than on the wiki page
18:01:27 <RainbowDash> now AI said that there is not a good definition of branchless. but i think predicated instructions are a very good way to explain it.
18:02:01 <RainbowDash> maybe if it could be like "A branchless programming language is a programming language that does not use statements to control program flow but rather predicated instructions or operations that mimic predicated instructions."
18:02:19 <RainbowDash> i meant The branchless paradigm is a paradigm that*
18:06:01 <ais523> so the gray area happens when you start predicating entire sections of instructions
18:06:47 <RainbowDash> i mean you do need some way to predicate stuff, just because you can predicate entire sections of instructions doesn't make it any less branchless. the predicated instructions will still run just not do anything
18:06:56 <ais523> imagine a program that goes «while(true) { A if x == 1; B if x == 1; C if X == 1; D if X == 2; E if X == 2; F if X == 2; G if X == 3; … }»
18:07:23 <ais523> (assume case-insensitive because I accidentally switched case halfway through writing it, I'm tired)
18:07:41 <ais523> from one point of view, this is branchless because it is a loop full of predicated instructions
18:08:00 <ais523> but from another point of view, this is a perfectly normal state machine where x is the instruction pointer, and is potentially very branchy
18:08:26 <ais523> because it's just another syntax for a switch/case/match in a loop
18:08:49 <RainbowDash> i think branchless should follow some sort of math, like how 10+5 is 15. in cyclic tag something being 0 and 1 is it's form of math. but thats hard to define objectvily.
18:09:07 <ais523> there are some esolagns where actual programming in practice falls into that gray area, e.g. The Waterfall Model and Delta Relay
18:09:54 <RainbowDash> i mean can we agree that windmill, cyclic tag, i/d machine, and blindfolded arthmetic are branchless?
18:10:23 -!- amby has joined.
18:10:26 <RainbowDash> if the branchless paradigm does get added should it applied to only turing complete languages
18:10:36 <ais523> what's interesting about those languages is that all obvious implementations are branchless or effectively so
18:11:07 <ais523> and the gray area is formed of languages like Delta Relay which have both obvious branchless and obvious branchy implementations
18:11:28 <ais523> because their semantics are less suggestive of an implementation strategy than, say, Blindfolded Arithmetic's are
18:11:38 <RainbowDash> i think something should be counted as a branch if the logic of an instruction would not be ran in the hardware
18:12:03 <ais523> but that's a property of the implementation, not the langauge
18:12:35 <ais523> so languages are only clearly branchless if they strongly suggest a branchless implementation strategy
18:13:23 <RainbowDash> i mean the way you simulate branches in windmill is very close to what you said earlier. but the math still runs to check all the booleans and run everything
18:13:29 <RainbowDash> the while(true) { A if x == 1; B if x == 1; C if X == 1; D if X == 2; E if X == 2; F if X == 2; G if X == 3; … }
18:13:48 <ais523> incidentally, the I/D machine seems to be "more branchless" than something like cyclic tag, because there are two obvious implementations and one of them is branchless in the instruction decoding in addition to at runtime
18:14:39 <RainbowDash> variable = ((condition==1)*(value_if_true))+((condition!=1)*(value_if_false))
18:14:40 <RainbowDash> this is how an if statement is made in windmill which is equal to
18:14:40 <RainbowDash> variable = condition ? value_if_true : value_if_false;
18:14:41 <ais523> fwiw, I don't think this ambiguity is a reason to not create the category, but it is a reason to think about exactly how we want to define it
18:15:24 <RainbowDash> i mean abusing branchless to create branches is exactly what you are supposed to is it not?
18:15:27 <ais523> one sign of branchlessness is that it "naturally" goes SWAR, but that is only helpful in languages that actually have wide data types
18:15:53 <ais523> right, this is why it's a paradigm, "what you're supposed to do" is the nature of those
18:16:19 <RainbowDash> is it fine if i go into a more of a theortical aspect of this? i dont know if it will help the dissucsion but me and xylo agreed on it
18:16:30 <ais523> something like ELEMENTARY is branchless but the instructions effectively create loops
18:16:45 <ais523> RainbowDash: the theoretical aspects should be discussed somewhere, they're interesting
18:17:05 <ais523> I think there should probably be a wiki article called something like "branchless programming" that discusses the programming style and theoretical considerations / difficulties in defining it
18:17:06 <RainbowDash> me and xylo agreed that nondetirmistic turing machines are branchless because they choose EVERY branch possible
18:17:20 <RainbowDash> and they only end up picking one, which is what a branchless programming language basically does but with logic instead
18:17:34 <RainbowDash> i made https://esolangs.org/wiki/Branchless_Algorithms
18:17:40 <ais523> I think I'd also agree with that, although I think disagreeing is reasonable
18:17:52 <ais523> (re: angelic nondeterminism)
18:18:22 <int-e> this also overlaps with reversible computing
18:18:43 <RainbowDash> it overlaps with alot of stuff but i think it is most useful as a tag where something is obviously branchless
18:18:49 <ais523> int-e: are you thinking about bit buckets as the analogy for predication?
18:18:53 <int-e> (which can have branches but it's hard to enforce statically that you can undo merged control flows)
18:19:22 <RainbowDash> i don't know what angelic nondeterminism is, well atleast in terms of the arguement against that
18:19:36 <ais523> well, implementing nonreversible languages in reversible languages is normally done using a control-merge function/idiom
18:19:44 <korvo> ais523: Sorry for dropping the conversation; I got distracted by finding some fascist's code on my system. I will change [[Langton's ant]] as discussed.
18:19:51 <ais523> RainbowDash: "angelic" = the program picks whatever course of action helps it terminate correctly
18:20:11 <ais523> wihch is how nondeterministic Turing machiens are normally defined
18:20:24 <RainbowDash> well nondeterminstic turing machines are too i guess
18:20:28 <ais523> it doesn't necessarily require hypercomputation, you can just run all the possibilities in parallel until you find the one that works
18:20:47 <RainbowDash> give me a second to find what i said to xylo
18:20:55 <ais523> I like to use the full "angelic nondeterminism" phrase nowadays because if you just say "nondeterminism" many people assume you mean randomness
18:21:36 <RainbowDash> See here, A and B can be an infinite variations of numbers, but there are certain paths to printing 55. this is what i mean by "picking a single path" the two paths are 55 and 0
18:22:10 <RainbowDash> A==B is the decider of what to do out of an infinite amount of paths. if that makes sense
18:23:22 <RainbowDash> it would be technically simulating all paths but the logic shows where to go. it might make sense if you programmed branchlessly more becuase that is how i think of it sometimes when i am programming.
18:24:23 <ais523> I think there are languages where you can literally write programs like that
18:24:39 <ais523> I'm pretty sure it's possible in Prolog but I can't remember the syntax for the Boolean comparison
18:25:17 <RainbowDash> "write programs like that" like what? is what i mean to ask.
18:26:14 <RainbowDash> also are rewriting languages branchless like thue and lambada caculus?
18:26:48 <RainbowDash> one can argue that they are not because they follow paths that can branch into other paths and certain instructions won't ever be ran
18:27:14 <RainbowDash> but one can argue against that saying that the same thing happens in cyclic tag when a zero is read.
18:27:30 <korvo> RainbowDash: One issue with your logic is how CPUs work today. So, expanding on the hint from int-e, in a GPU or DSP, we "mask off" the predicated instructions when the predicate fails. This means that we still do the calculation, but we ignore the result. It's cheaper to do this because it's applied to lots of data all at once. This is what SIMD means by "multiple data".
18:27:34 <ais523> your example of a nondeterministic program
18:27:57 <ais523> OK, seems that Prolog doesn't actually have an arithmetic operation that compares two numbers and returns a boolean
18:28:24 <korvo> This is also kind of how ALUs work. The ALU computes every operation at once, but the operations which aren't used are masked off by the decoder for the ALU. Exactly how much computation is wasted is implementation-specific, but the idea is that we don't have to literally rewire the ALU for each new instruction.
18:28:46 <RainbowDash> yes branchless programming does alot of ignoring instructions being ran, that is how they achieve what they do
18:28:58 <korvo> Well, I guess I'm saying: when is digital logic *not* branchless?
18:29:50 <ais523> korvo: so circuits normally have both data inputs and control inputs, but sometimes which is which is a matter of perspective – and being branchless is about having the control inputs follow a predictable pattern
18:29:58 <ais523> (i.e. one that isn't data-dependent)
18:30:05 <korvo> Solid-state mechanisms really mess with our idea of the machine *being* in a *state* since we are definitionally trying to keep them in exactly *one solid state* at all times.
18:30:13 <ais523> but because it's subjective which inputs the control inputs are, that also makes it subjective whether the hardware is branchless
18:30:30 <RainbowDash> i mean i guess you can program branchlessly without having to ignore instructions. for example you can use purely mathamatic functions to achieve results.
18:30:53 <ais523> korvo: that's not the usual definition of solid-state, at least
18:31:07 <b_jonas> if you wanted to run blindfolded arithmetic programs in practice then you'll make an interpreter that tries to decompile them, at least to the point where it can skip sequences of conditional instructions when the condition is false. this especially helps when the program is a state machine where most of the loop does nothing in each iteration. and once you do that, blindfolded arithmetic won't be
18:31:13 <b_jonas> branchless, it's not running in a fixed amount of time per loop. (of course fixed amount of time is only if you're running on hardware with a very long but fixed word size, like the originally intended machines that multiply a hundred decimal digits.)
18:31:37 <ais523> it was originally used to distinguish circuits that are entirely made of solids (like copper and silicon) from those that contain vacuum tubes (and thus are partly based on gases)
18:31:45 <korvo> RainbowDash: For sure! I don't want to ignore how you're thinking. I'm poking at the edges because one important question for a paradigm is whether it's something we use *inside* a language as a pattern, or something *outside* which defines the language by controlling what we're allowed to express. Like, object-oriented vs object-based.
18:32:17 <RainbowDash> yeah it's just very hard to define something but i think this proccess is needed as there has not been any good defintions previously made before this discussion
18:32:19 <ais523> korvo: and "object-oriented" has caused a lot of trouble over the years
18:32:55 <ais523> partly because there's room for disagreement about how broadly or narrowly to define it, and partly because if you define it narrowly there is more than one plausible narrow definition
18:32:57 <korvo> ais523: TIL! In music it's anything that's based on digital logic as opposed to analog logic. And I think further back, to fluidics and mechanical linkages, which also moved.
18:33:30 <RainbowDash> are angelic turing machines branchless can we agree or disagree?
18:34:15 <ais523> RainbowDash: I agree with you that they're branchless, *but* branchless is a property of the implementation and the angelic Turing machines are branchless only if you have an angelic implementation to run them on
18:34:30 <korvo> I think "branch" is ill-defined.
18:34:31 <ais523> I'm happy to imagine that I have one of those, even though it isn't obviously physically possible
18:34:55 <ais523> but I don't expect everyone to agree
18:35:06 <b_jonas> "when is digital logic *not* branchless" => when the part that takes or does not take branches doesn't fit into the same nice digital model, like it powers down an entire region in the processor (or even an entire chip) to save power.
18:35:35 <RainbowDash> maybe something like "The branchless paradigm removes the use of statements controlling program flow, forcing the programmer to come up with solutions that mimic branches or completely computes differently without ignoring instructions making every instruction useful." i mean it can be written better but do you get what im getting at
18:35:49 <ais523> so one example I've been thinking about: imagine an adder but there's an AND in the carry circuit, which you can use to suppress the carries
18:35:56 <ais523> and if you do that it becomes an XOR instead
18:36:11 <esolangs> [[Text Scratch]] N https://esolangs.org/w/index.php?oldid=170628 * Esolangist alt * (+1257) Esolangist alt
18:36:12 <korvo> b_jonas: Hm. Because it's continuous?
18:36:22 <ais523> (note: this probably isn't a sensible way to build an ALU in practice, but in theory there's nothing ruling it out)
18:36:24 <RainbowDash> when we look back at while(true) { A if x == 1; B if x == 1; C if X == 1; D if X == 2; E if X == 2; F if X == 2; G if X == 3; … }
18:36:25 <RainbowDash> we can see this is branchless, but it doesn't seem branchless, we know this is branchless because we can subsiute these expressions with mathmatical logic and be branchless.
18:36:45 <korvo> RainbowDash: Out of curiosity, have you heard of constant-time algorithms? They're used in cryptography, for example.
18:36:49 <RainbowDash> and if that isn't enough, you can rewrite the entire program to still act the same and still be branchless in some sort of way.
18:37:02 <b_jonas> I thought "solid state" just means no moving parts, such as relays that aren't electromechanical but are built of semiconductor, or storage that doesn't have a rotating platter or moving tape but modern semiconductor magic
18:37:44 <ais523> korvo: so in practice those are nearly always branchless because it is hard to get a modern processor to take a constant amount of time if the program is brnaching
18:38:02 <korvo> RainbowDash: They're algorithms which execute in predictable time regardless of their inputs. Like, adding two numbers without taking different amounts of time depending on what those numbers are.
18:38:04 <RainbowDash> i think it is fine for the state of the program to be inside of memory but not be in the actual instruction pointer.
18:38:05 <RainbowDash> xylo said you can have a 1 rule 2 tape turing machine and change the state by having a single tape have the states in memory rather than it being in the hardware.
18:38:15 <ais523> b_jonas: the definition does seem to rule out relays, but no moving parts isn't sufficient
18:38:44 <korvo> ais523: Exactly. To branch could be to have observable distinctions in time/space usage. And isn't that the point, in some sense? To take a branch to potentially save time as opposed to computing *all* intermediate values?
18:39:04 <b_jonas> ais523: oh, because you're saying no vacuum tubes either, right
18:39:31 <korvo> RainbowDash: Like ais523 says, if the algorithm operates without examining the input values, then it can't possibly have branches which depend on those input values.
18:39:33 <RainbowDash> yes, branching saves time by not computing everything. while branchless might not save time because it might have to ignore values it computed.
18:39:39 <ais523> korvo: branchlessness does not survive optimisation, but I think it's OK to sometimes discuss concepts like that
18:39:52 -!- somefan has joined.
18:40:02 <RainbowDash> like when i say you don't need branches in some cases at all i mean something like
18:40:09 <ais523> for constant-time crypto, it has reached the point where some platforms are starting to create non-optimisations guarantees
18:40:46 <ais523> e.g. I think ARM recently gave a non-optimisation guarantee for a range of common arithmetic instructions, guaranteeing that they will actually be executed if they would have been executed in program order
18:40:47 <korvo> ais523: I suspect that we merely need to teach optimizers how to *not* speculate on the values of certain inputs.
18:41:07 <korvo> RainbowDash: On IRC, please use a pastebin to share more than one line of code. I like bpaste at bpa.st.
18:41:49 <ais523> that was actually an impressively fast paste, normally you get frozen for a minute or two if you try to paste that much
18:42:14 <ais523> either Libera are more lenient on that than Freenode used to be, or the IRC client knew exactly how fast a paste it could get away with
18:42:22 <korvo> RainbowDash: '&' is a Boolean operator. I understand what you're saying, though; the language has a notion of *control flow*, and you're saying that control flow isn't conditionalized.
18:42:39 <RainbowDash> i know it is a boolean operator, but yeah boolean logic to mimic control flow is what i more specfically meant.
18:42:41 <esolangs> [[99 bottles of beer, but you drank it]] N https://esolangs.org/w/index.php?oldid=170629 * Esolangist alt * (+428) Esolangist alt
18:42:41 <ais523> RainbowDash: right, there are limits to how frequently you can post messages and pastes normally end up hitting the rate limit and making it hard to hold a conversation because of all the penalty lag you get as a result
18:43:05 <korvo> RainbowDash: IRC is a serialized protocol without any sort of channels or QoS. While pasting, you literally cannot do anything else. If your client is any good, it will allow you to interrupt a paste; if your client is great, it will either auto-pastebin it or prevent the paste.
18:44:34 <korvo> RainbowDash: IF and ELSE *are* control-flow operators. There's nothing mimicked or fake about it. This is the difference between what's technically computable within the system (usually anything computable!) and how we simulate that system in physical hardware. Like, the CPU will *jump* from one section to another, interrupting the stream of instructions.
18:44:54 <b_jonas> ais523: and it's a compiler problem too, there are libraries that try to convince too smart compilers to not do optimizations that can make the compiled code data-dependent, or to make sure the compiled code overwrites some amount of memory to forget information even if the complier believes it can prove that the write can be optimized away
18:45:07 <ais523> korvo: there are conceptual problems even then
18:45:22 <ais523> suppose I have a conditional forwards jump, it gets predicted as not taken, but it's actually taken
18:45:27 <RainbowDash> korvo im not saying the if and the else are the things mimicing it i mean the second part of the code
18:45:32 <ais523> so the compiler speulatively runs a few commands after the jump
18:45:38 <ais523> err, processor, not compiler
18:45:48 <ais523> say the command it reaches when it realises the jump is actually taken happens to be the command before the jump target
18:46:03 <RainbowDash> So what do you guys suppose is wrong with the definition "The branchless paradigm removes the use of statements controlling program flow, forcing the programmer to come up with solutions that mimic branches or completely computes the same result differently without having to mimic branching."
18:46:14 <ais523> now, it's running the exact same sequence of commands on both sides of the branch, just resetting the values if the branch happens to be taken
18:46:22 <korvo> RainbowDash: Oh, yes, for sure. I did fully agree with you on-wiki that there is a branchless paradigm. Like, we could have a page [[Branchless paradigm]] right now, I think. The main questions are about whether there should be a category, what it should be called, and what the criteria for inclusion are.
18:46:37 <ais523> this conceptually doesn't seem to be any different interpreting the conditional jump as a predication
18:46:52 <korvo> ais523: Who knows what secrets lurk in the hearts of L2? The Spectre knows! *Vincent Price laugh*
18:47:04 <RainbowDash> i think it should have a category as alot of pages fall into it and its not as niche as one might think
18:47:05 <int-e> b_jonas: And ultimately a hardware problem :) What's really stopping a CPU from short-cutting a bitwise and operation (say) if one of the inputs is already known to be 0?
18:47:28 <RainbowDash> i think hardware can be ignored to a certain point as ai said
18:47:34 <b_jonas> int-e: yes, both CPU problem and compiler optimization problem.
18:47:35 <ais523> int-e: short-circuiting divisions is a real thing that happens on certain processors
18:47:35 <int-e> apart from "that would be crazy" which has, historically, never stopped anybody
18:47:39 <RainbowDash> if it theortically would not branch then it would be branchless
18:47:41 <ais523> (not divide by 0, other special cases like divide by 1)
18:48:10 <int-e> (it was fine when CPUs were thousands to millions of transistors)
18:48:16 <korvo> RainbowDash: Honestly, that's a fairly good first sentence. I would want to see it followed up by citations saying who came up with it. Also an explanation clarifying some of the issues we've raised here, to help readers understand how this differs from other paradigms.
18:48:25 <int-e> ais523: yeah, makes sense, sadly
18:48:54 <RainbowDash> i came up with it, there is not alot of discussion on it because this is not a studied field too much. unless i am missing some grand author who writes alot about this.
18:48:59 <int-e> well. divisions kind of have always been variable time
18:49:01 <ais523> most of the arithmetic instructions are too fast already for fast-path optimisations to help
18:49:05 <ais523> but division is still pretty slow
18:49:32 <ais523> branchless programming is well-known, you might have invented it independently but you weren't the first
18:49:47 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:49:49 <int-e> We can do this for multiplications too though, and then it's suddenly relevant for cryptography.
18:49:50 <korvo> RainbowDash: Offhand, it's a popular topic for GPU and DSP programmers, as well as cryptographers.
18:50:01 <RainbowDash> branchless programming is used in snippets of code often but not the whole thing if i recall correctly
18:50:23 <ais523> that said I'm generally not a fan of citations when it comes to topics which are well-known and many people are likely to have come up with on their own
18:50:30 <b_jonas> I mean, the whole point of blindfolded arithmetic is to show how we can simulate branching programming on a branchless machine
18:51:02 <RainbowDash> i mean you can't really cite it to anyone because alot of things come similar to it like blindfolded arthmetic
18:51:15 <ais523> or even for more obscure topics with a single author – some papers I worked on used the Muller C-element, I looked up the history, and it turned out that a lot of authors had just been copying citations from each other about the history of that element without checking the original source
18:51:29 <korvo> RainbowDash: I was literally hand-writing branchless GPU shaders over a decade ago for video rendering. Back then, concepts like swizzling and masking were standard for understanding both the GPU and also our programming models on top of it like GLSL.
18:51:43 <RainbowDash> oh yes, branchless does happen alot on shaders
18:52:02 <korvo> So no, it's not new. I was able to cite John Backus for [[functional paradigm]] and Alan Kay for [[object-oriented paradigm]]; I'm sure *somebody* has talked about it before.
18:52:09 <ais523> (something that I verified by borrowing a physical copy of the actual book that everyone was citing – it was fairly obscure, but librarians can be extremely good at their jobs – then chasing citations backwards from there)
18:52:13 <RainbowDash> but it can be generallized to everything, it can simulate any turing complete program. not just shaders or math.
18:52:33 <b_jonas> IOCCC 1992/buzzard.1.hint points this out: if you preprocess the program then it gets less readable, because before preprocessing it's an ordinary branching program, but after preprocessing it's branchless code
18:52:39 <korvo> I compared with SWAR; there's actually *two* separate schools of SWAR, with the other called "broadword", so if we had a page on SWAR then we'd have to cite both.
18:52:49 <RainbowDash> i mean i guess what i mean to say is i don't know who to cite because i did all this research myself essentially.
18:53:07 <RainbowDash> the halt and i/o variable are things that i had to make up and other people used it.
18:53:13 <ais523> korvo: ELEMENTARY is probably an extreme version of SWAR-style programming (although the "R" doesn't quite apply at the point where you're using double exponentials)
18:53:22 <RainbowDash> not saying it hasn't been done before im just saying that i brought it to attention for esolangers.
18:53:25 <b_jonas> today we do branchless programming because it lets us use SIMD better, or even GPUs
18:53:37 <ais523> b_jonas: or just to avoid the cost of branch mispredictions
18:54:07 <ais523> last time I checked a misprediction was around 30×-40× slower than a normal arithmetic instruction, that has probably changed since but is likely to still be in the right ballpark
18:54:07 <RainbowDash> do i have the go ahead to make it a category? and it can be edited to be more precise later
18:54:08 <b_jonas> but unlike blindfolded arithmetic those give more readable programs because they have more built-in primitive operations to support branchless conditionals
18:54:17 <RainbowDash> i mean there is always going to be some argument over a defintion as defintions are.
18:54:49 <b_jonas> ais523: yes, that too, though the "30×-40× slower" thing really only applies if there isn't anything else slowing you down, such as cache misses
18:54:54 <korvo> ais523: Yeah. One of the papers, don't remember which, has the beautiful vision of a future where we periodically recompile our 8-bit programs to be SWAR'd on ever-broader machine words. They imagined that the 32-to-64 transition would lead to a grand *doubling* of performance on tight code!
18:54:58 <ais523> when a misprediction is that expensive, compiling to branchless code is going to be good unless you can keep mispredictions down to a very small proportion
18:55:19 <RainbowDash> also, should things with the branchless paradigm also have to be turing complete to fall in the catagorzation even though alot of total programs are branchless
18:55:40 <ais523> korvo: well, that really does help for some algorithms – it's just that they aren't used often
18:55:41 <RainbowDash> i mean i can think of one total programming language that you still program in the branchless paradigm however.
18:56:02 <ais523> SIMD going from 64 bits to 128 bits to 256 bits to 512 bits does actually give a near-doubling every time for certain programs
18:56:10 <int-e> How was I not aware of SWAR, a 1996 acronym. (The concept is familiar.)
18:56:21 <ais523> although, many modern processors have to underclock themselves to do particularly wide SIMD
18:56:26 <ais523> so you don't get a true doubling
18:56:36 <korvo> RainbowDash: You have the go-ahead to make [[Branchless paradigm]], at least. That's where we would put all of the references and explanations and nuances. I don't think that we have a definite list of like five articles which would fit the category, though.
18:56:57 <ais523> korvo: I think it should be [[Category:Branchless paradigm]] but [[Branchless programming]]
18:57:01 <RainbowDash> we have a definite list of like five articles however
18:57:23 <ais523> because the mainspace article should be about *both* languages that enforce branchless programming, and branchless programming used as a technique in languages that support full-powered conditoinals
18:57:35 <korvo> ais523: Okay! Let's bless it.
18:57:50 <RainbowDash> alright ill start writing them and then you guys can edit it
18:57:53 <korvo> Or maybe we just did?
18:58:17 <RainbowDash> where do you talk about the nuances though
18:58:31 <b_jonas> RainbowDash: in the mainspace article
18:58:34 <ais523> category description pages on Esolang should normally be very short
18:58:42 <korvo> RainbowDash: Excellent! Thanks for chatting, BTW. I hope you continue to chat and contribute.
18:58:45 <b_jonas> in the category page you only talk about the definition of what the category applies to
18:58:54 <RainbowDash> that's why i say where should we put the nuances because there is alot of them
18:59:09 <ais523> and just link to an article giving more information
18:59:10 <korvo> As an example, I moved nearly everything in [[category:functional paradigm]] to [[functional paradigm]] after IRC discussion.
18:59:13 <RainbowDash> because it doesnt really fit in branchless programming but it cant go in the catagorey either
18:59:47 <ais523> this is a little nontrivial and I'm not quite sure how to handle it right now
18:59:52 <korvo> Put it in [[branchless programming]]! If I were stubbing it, I'd put a section on GPUs, on DSPs, on SIMD, on cryptography. Go for it!
18:59:59 <ais523> (and said as much on Esolang talk:Categorisation)
19:00:13 <RainbowDash> Branchless programming only focuses on the techniques and not the paradigm
19:01:02 <RainbowDash> what if i make a page called [[Catgorization:Branchless paradigm]] (typod ill fix that later) [[Branchless Paradigm]] and [[Branchless Programming]] with see more
19:01:19 <RainbowDash> where the catagorization links to the branchless paradigm page to explain more
19:01:26 <esolangs> [[Blindfolded Arithmetic]] https://esolangs.org/w/index.php?diff=170630&oldid=155064 * B jonas * (-8) hereby showing a rude gesture to the IOCCC webpage maintainers
19:01:27 <RainbowDash> and the branchless paradigm links to the programming for the techniques
19:01:36 <ais523> the capitalisation is wrong, should be [[Branchless programming]] with a lowercase p
19:01:39 <ais523> because it isn't a proper noun
19:02:21 <int-e> (it should be [[branchless programming]] but Wikimedia has Ideas about Page titles)
19:02:31 <int-e> Or Mediawiki, rather.
19:02:41 <korvo> I think it can fit in one article. [[ZISC]] and [[OISC]] have a similar burden, because it's ultimately something of a *perspective* whether a machine is one- or zero-instructioned, and it turns out that there's a natural way to move from one perspective to another.
19:03:02 <RainbowDash> what about an articled called like [[Branchless]]
19:03:04 <int-e> RainbowDash: I'd prefer starting with a Branchless programming page
19:03:09 <korvo> Defunctionalization (which we don't have a page on yet?) is another good example.
19:03:14 <ais523> I think maybe the paradigm article should be a section on the programming page rather than an article of its own
19:03:35 <RainbowDash> ill start with the programming page then as we all agree it should exist
19:03:36 <int-e> We can split it later if there's enough for two separate pages.
19:04:09 <RainbowDash> so [[Branchless programming]] or [[branchless programming]]
19:04:15 <ais523> int-e: lowercase titles are rare, there's something of a split between sentencecase and titlecase but normally people wouldn't spell a title entirely in lowercase unless it starts with a word which for some reason *can't* be capitalised
19:04:19 <int-e> RainbowDash: the former
19:04:41 <ais523> RainbowDash: in MediaWiki page titles, the first character is case-insensitive but the others are case-sensitive
19:05:16 <ais523> now I'm curious about how it handles Turkish İ and ı
19:06:12 <ais523> looks like Wikipedia calls the articles "İ" and "Dotless I"
19:09:41 <esolangs> [[Obfuscated Tiny C]] https://esolangs.org/w/index.php?diff=170631&oldid=63518 * B jonas * (+195) IOCCC webpage broke all the links
19:10:55 <b_jonas> (at least that's the default; Mediawiki can be configured otherwise)
19:11:01 <ais523> I think the definition is fine (although it's worth noting that it depends on what an instruction is, which is somewhat subjective)
19:11:25 <ais523> doesn't have to be noted in the introduction, it can be mentioned later
19:11:46 <ais523> although, now I'm thinking about conditional-skip instructions
19:11:59 <ais523> having a conditional skip *and* a goto clearly makes a language branchful
19:12:17 <ais523> but having one of them without the other might not
19:14:07 <RainbowDash> i think the most stressful part of this page is the first sentence everything after that is fine
19:15:06 <ais523> hmm, what about "'''Branchless programming''' is a programming technique in which the program always runs the same commands in the same order."
19:15:44 <korvo> RainbowDash: Correct! The first sentence of the article must clearly explain what the topic is, what it's called, how we should classify it, what it's compared to, and some other stuff. You'll get the hang of it eventually.
19:16:10 <ais523> korvo: "what it's compared to" can go in the second or third sentence sometimes
19:16:16 <RainbowDash> i've created many articles but none that must meet up to the high status quota. but i do know alot about this topic
19:16:24 <RainbowDash> what it's compared to can you expand on that?
19:16:49 <ais523> I suspect korvo's expansion will be different from mine
19:18:04 <korvo> RainbowDash: Like, if there's a context. "X, also called X', is a Thing from Place. It is notable among Things for Shape and Color. X was first documented in 18xx by Somebody."
19:18:33 <korvo> Many of us have done English WP before, and after a few hundred edits you get used to the conventions.
19:18:52 <RainbowDash> you guys said like GPU programming but i want the list
19:19:24 <esolangs> [[Langton's ant]] https://esolangs.org/w/index.php?diff=170632&oldid=170625 * Corbin * (+119) /* Computational class */ Light cleanups suggested by ais523 on IRC. This section still doesn't vibe with the rest of the article.
19:19:25 <esolangs> [[Binary lambda calculus]] https://esolangs.org/w/index.php?diff=170633&oldid=153916 * B jonas * (+6) IOCCC webpage broke all the links
19:19:43 <ais523> (practical uses) code that needs to deal with unpredictable data, GPU programming, SIMD, constant-time code for cryptography; (esoteric uses) languages which are so bad at conditionals that branchless programming is easier
19:20:07 <korvo> I'd mention GPUs, DSPs (like GPUs but for e.g. audio data), cryptography, -- ^^ what they said.
19:20:34 <esolangs> [[Unlambda]] https://esolangs.org/w/index.php?diff=170634&oldid=159723 * B jonas * (+0) IOCCC webpage broke all the links
19:20:43 <ais523> korvo: I've only worked with DSPs once and I used branchy code for that
19:21:04 <ais523> I can see how branchless code might be useful for that in some cases though
19:21:51 -!- tromp has joined.
19:22:05 <korvo> I haven't done a lot of it. At university I worked on the OSWALD, which remarkably is bluelinked: https://en.wikipedia.org/wiki/Oregon_State_Wireless_Active_Learning_Device
19:23:16 <korvo> The reason Java worked on that platform is because I slept in the lab for like 3wks and babysat BitBake, fixing build errors. Good times.
19:23:44 <esolangs> [[Print("Hello, World!")]] M https://esolangs.org/w/index.php?diff=170635&oldid=168791 * Somefan * (+196) rephrasing and added c/c++ sample and see also
19:24:06 <ais523> there are some interesting cases, e.g. Fourier transforms are inherently branchless just because they're pure arithmetic, but for doing bignum multiplications you're normally doing Fourier transforms modulo a large number, and then it becomes branchful due to modulo being faster to implement with branches than branchlessly
19:24:58 <ais523> working on some code like that, there was a potential double-carry which was so unlikely (1 in 2³²) that trying to do it branchlessly would have been a waste, I can live with extremely rare mispredicts
19:25:02 <korvo> RainbowDash: There's other sections that we'll add too. Like, SWAR/broadword will be its own article which I'll stub shortly. Processors like later x86 have cmov, and modern ARM can conditionalize any(?) instruction, and those should have their own section too.
19:25:16 * korvo procrastinating on LangJam
19:25:31 <RainbowDash> alright im just working on the barebones for the page right now
19:25:48 <ais523> I'm suspicious of the whole idea of LangJam, I don't think a week is enough to make an interesting language *and* write a game in it
19:26:04 <korvo> Oh, never mind, [[wikipedia:SWAR]] is actually good now. We'll just do ''Main article:'' on it.
19:27:12 -!- Sgeo has joined.
19:28:25 <b_jonas> there's also a distinction in non-eso that we may have to think about. sometimes for cryptography or hard real time you want memory access to be perfectly predictable, i.e. not data-dependent, in addition to there being no branches, which matters on modern platforms where memory access can be non-constant time or can leak information to future memory accesses. that's a stronger requirement than
19:29:08 <korvo> RainbowDash: I need to take off for a bit, but one last note: Your proposed sentence is a run-on. It's okay to break it up by first giving a *short* version of your thesis, and then starting the *longer* version with "That is, branchless programming is ..."
19:30:07 <b_jonas> for real-time what matters is that you can make sure the code won't suddenly be too slow if it encounters lots of unusual memory addresses that aren't available from the cache; for cryptography what matters is that nothing is leaked through any side channel, even through the code running unusually *fast*
19:30:08 <ais523> b_jonas: that could also matter in esolangs, especially when programming weird machines
19:30:35 <korvo> The authors of [[formal grammar]] used this a lot, and it can be an obvious issue when repeated, but it's completely normal for a first paragraph to struggle to contain its topic. By necessity, you'll need to use the rest of the article to explain the concept anyway!
19:30:48 <ais523> speculative sidechannel attacks are effectively an esolang that practical code has to try very hard to not interpret
19:31:13 <korvo> b_jonas: I completely forgot that hard RT is a thing. Well said.
19:31:30 -!- Lord_of_Life_ has joined.
19:31:35 <b_jonas> it also comes up in homomorphic encryption code
19:32:12 <ais523> I have some interest in working out how to design a compiler that produces hard-realtime-safe output, but it seems like an exceedingly hard problem
19:32:43 <ais523> how could you possibly make sure that enough of the data that a codeblock is accessing is in cache already?
19:32:53 -!- Lord_of_Life has quit (Ping timeout: 260 seconds).
19:33:01 <b_jonas> ais523: yeah, but hard realtime can also be laxer, because it can have actual branching conditionals, as long as you can bound the time of both branches
19:33:26 <ais523> b_jonas: and of the mispredict
19:33:52 <ais523> the default hard-realtime assumptions probably have to be that every memory access misses cache and every branch is mispredicted
19:34:08 <ais523> but under those assumptions, programs run extremely slowly and it's hard to get useful time bounds
19:34:15 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
19:34:27 <ais523> actually, "every memory access misses TLB" is even worse
19:35:34 <b_jonas> usually you want as little code as possible to be hard realtime, and make it communicate with the rest of the code that is only soft realtime or not realtime for any function that doesn't need to be hard realtime
19:36:00 <esolangs> [[Branchless programming]] N https://esolangs.org/w/index.php?oldid=170636 * RainbowDash * (+2619) Created page with "'''Branchless programming''' is a programming technique in which the program always runs the same commands in the same order. Practical uses for branchless programming consists of : code that needs to deal with unpredictable data, GPU programming, SIM
19:36:07 <RainbowDash> https://esolangs.org/wiki/Branchless_programming
19:36:15 <RainbowDash> oh i guess you can see that in the irc oops heh
19:36:25 <ais523> yes, we have a bot reporting on that
19:36:26 <RainbowDash> it is a start, it is not full or polished.
19:36:38 <b_jonas> in the dayjob company that I'm resigning from, controlling chemical plants, none of the stored program code is hard realtime, though there is a lot of soft realtime; hard realtime is implemented in hardware only
19:36:42 <RainbowDash> i also dont like how the second part is organized
19:37:27 <ais523> it'll need some cleanup, but it's a wiki, creating an article means that anyone can clean it up if they want to
19:37:37 <RainbowDash> when will we make the branchless paradigm catagory?
19:37:47 <ais523> b_jonas: that seems sensible
19:38:04 <ais523> do you have a new dayjob lined up? or is the current company bad enough to make you resign anyway?
19:39:22 <ais523> RainbowDash: I'm might be better to wait until I'm more awake, in case admin help is needed, but I think there's been enough discussion for its creation to be allowed
19:39:47 <RainbowDash> alright, you may create it then i can edit it if needed
19:43:15 <APic> Nighty-Night * 😴
19:43:30 -!- impomatic has quit (Quit: Client closed).
19:44:54 -!- ais523 has quit (Quit: quit).
19:47:38 <esolangs> [[Branchless programming]] https://esolangs.org/w/index.php?diff=170637&oldid=170636 * RainbowDash * (+1031) tech
19:48:20 <RainbowDash> That is all the work i think ill do today as i need to play with friends but you guys are welcome to edit it as you see fit.
19:48:29 -!- RainbowDash has quit (Quit: Client closed).
20:26:13 <esolangs> [[Lil]] M https://esolangs.org/w/index.php?diff=170638&oldid=131434 * Orby * (-41) Changing command format a bit
21:24:20 -!- somefan has quit (Remote host closed the connection).
21:26:15 -!- chomwitt has quit (Ping timeout: 244 seconds).
22:23:46 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=170639&oldid=170621 * Buckets * (+13)
22:24:07 <esolangs> [[User:Buckets]] M https://esolangs.org/w/index.php?diff=170640&oldid=170592 * Buckets * (+12)
22:24:21 <esolangs> [[Ialist]] N https://esolangs.org/w/index.php?oldid=170641 * Buckets * (+1619) Created page with "{{lowercase}} ialist is An Esoteric programming language created By [[User:Buckets]] in 2021. {| class="wikitable" |- ! Commands !! Instructions |- | || Push the X and Inject the Y Coordinates of The Space. |- | || Swap the Bottom And The top. |- | || Turn Rightwards
23:21:04 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).