00:06:25 -!- Lord_of_Life has quit (Ping timeout: 240 seconds).
00:06:40 -!- Lord_of_Life has joined.
00:33:05 -!- m0ther has quit (Ping timeout: 240 seconds).
00:58:53 -!- m0ther has joined.
01:25:52 -!- m0ther has quit (Remote host closed the connection).
01:26:37 -!- m0ther has joined.
01:30:58 -!- m0ther has quit (Remote host closed the connection).
01:31:19 -!- m0ther has joined.
02:40:39 -!- m0ther has quit (Remote host closed the connection).
04:04:30 -!- m0ther has joined.
04:43:44 -!- example99 has joined.
04:51:49 <zzo38> Should uxn be mentioned in esolangs wiki? (There is already mention of Forth, MMIX, etc, so it might be worth, maybe?) Uxn has two stacks, and most instructions (except JCI and JSI) have a variant that operates on the other stack. Uxn also has hand signs for each instruction and for each number (I am unaware of anyone using them). There are other features too.
05:06:26 -!- bgs has joined.
05:50:03 -!- example99 has quit (Ping timeout: 260 seconds).
05:50:51 -!- m0ther has quit (Remote host closed the connection).
05:52:27 -!- m0ther has joined.
06:12:16 -!- m0ther has quit (Ping timeout: 248 seconds).
06:15:50 <esolangs> [[User:Peter]] https://esolangs.org/w/index.php?diff=108208&oldid=100680 * Peter * (-4)
06:16:17 <esolangs> [[Ricochet]] https://esolangs.org/w/index.php?diff=108209&oldid=103437 * Peter * (-18)
06:54:46 <esolangs> [[Nori.io]] M https://esolangs.org/w/index.php?diff=108210&oldid=108157 * Olus2000 * (-28) Remove 1st header
06:55:20 <esolangs> [[Nori.io]] https://esolangs.org/w/index.php?diff=108211&oldid=108210 * Olus2000 * (-15)
07:15:23 -!- m0ther has joined.
07:40:19 <esolangs> [[Nori.io]] M https://esolangs.org/w/index.php?diff=108212&oldid=108211 * Mkukiro * (+24)
08:12:37 -!- Sgeo has quit (Read error: Connection reset by peer).
09:18:17 -!- __monty__ has joined.
09:30:37 -!- kspalaiologos has joined.
09:51:11 -!- kspalaiologos has quit (Ping timeout: 264 seconds).
10:06:16 -!- m0ther has quit (Remote host closed the connection).
10:12:52 -!- kspalaiologos has joined.
10:31:29 -!- kspalaiologos has quit (Quit: Leaving).
10:32:02 <river> tromp: could a BLC program check proofs & encode godel 1st and we could get a nice small G?
10:42:00 <tromp> sure, that sounds similar to what https://arxiv.org/abs/1605.04343 did but for BLC instead of TMs
10:43:09 <tromp> certainly BLC seems much better suited for that than TMs
11:06:46 <esolangs> [[Nori.io]] M https://esolangs.org/w/index.php?diff=108213&oldid=108212 * Mkukiro * (+28)
11:07:05 <river> i wonder what is the absolute simplest proof language to use
11:07:32 <river> lc gives you nice easy asts to work with, so that's nice
11:42:26 <esolangs> [[Nori.io]] https://esolangs.org/w/index.php?diff=108214&oldid=108213 * Olus2000 * (+1912) Turing Completeness proof
11:43:18 <esolangs> [[Nori.io]] M https://esolangs.org/w/index.php?diff=108215&oldid=108214 * Olus2000 * (-1) /* Final program */ typo in expected input
11:43:36 <esolangs> [[Nori.io]] M https://esolangs.org/w/index.php?diff=108216&oldid=108215 * Olus2000 * (+1) /* Final program */
11:45:57 -!- example99 has joined.
12:08:38 -!- example99 has quit (Ping timeout: 260 seconds).
12:16:14 <esolangs> [[Nori.io]] M https://esolangs.org/w/index.php?diff=108217&oldid=108216 * Olus2000 * (+1) /* Production encoding */ gap in code block
12:58:04 -!- Noisytoot has quit (Quit: ZNC 1.8.2 - https://znc.in).
13:01:18 -!- Noisytoot has joined.
13:12:27 -!- perlbot has quit (Quit: ZNC 1.8.2+deb3+b4 - https://znc.in).
13:12:27 -!- simcop2387 has quit (Quit: ZNC 1.8.2+deb3+b4 - https://znc.in).
13:51:12 -!- Noisytoot has quit (Ping timeout: 255 seconds).
13:56:50 -!- Noisytoot has joined.
14:22:45 -!- Noisytoot has quit (Quit: ZNC 1.8.2 - https://znc.in).
14:23:03 -!- Noisytoot has joined.
14:23:45 <fowl> how about an esolang based on project management? perform calculations by opening and closing tickets? just talking about it I already want to off myself
14:25:17 <river> you could try to develop programs with high bus factor
14:25:44 <river> kinda regret joking about that now
14:28:33 -!- wpa has quit (Quit: Connection closed for inactivity).
14:42:26 <fowl> my company has an HR tool I use to track objectives with my boss that exists completely outside of jira, I'm trying to argue that I should be able to track my work with just one of these not both
14:48:32 -!- Noisytoot has quit (Quit: ZNC 1.8.2 - https://znc.in).
14:48:51 -!- Noisytoot has joined.
14:53:01 <fizzie> Gantt charts as sourcc code: discuss.
15:01:37 -!- Sgeo has joined.
15:06:58 -!- Noisytoot has quit (Quit: ZNC 1.8.2 - https://znc.in).
15:08:14 -!- Noisytoot has joined.
15:11:18 -!- Noisytoot has quit (Client Quit).
15:15:36 -!- Noisytoot has joined.
15:16:17 -!- wpa has joined.
15:37:48 -!- example99 has joined.
15:38:56 -!- example99 has left.
15:38:57 -!- example99 has joined.
16:08:20 -!- simcop2387 has joined.
16:09:31 -!- FreeFull has joined.
16:09:38 -!- simcop2387 has quit (Remote host closed the connection).
16:30:43 -!- simcop2387 has joined.
16:32:17 -!- perlbot has joined.
16:38:33 -!- example99 has quit (Quit: Client closed).
16:46:23 -!- vyv has joined.
18:37:18 <b_jonas> I have a question. Say you're given a planar map that's shown on a computer screen, and it has pointlike selectable sprites scattered on it. I'd like a UI where the user can navigate between these sprites so that they can select any one they want, using a four-way d-pad or arrow keys. But I don't want this to work like a mouse cursor that you move freely on the map, instead it should just move from a
18:37:24 <b_jonas> sprite to a nearby sprite when you press a direction. And it should be intuitive, so the selection moves roughly in the direction that you pressed and it's easy to figure out what you have to press to select any sprite you want. Is there a solution for this? You can preprocess the map, you can display extra info on the screen, and if you want you can cheat by having hidden state, or allowing the user to
18:37:30 <b_jonas> select some synthetic nodes that aren't real sprites, but not so many that it just moves a mouse cursor freely on a dense grid.
18:38:57 <b_jonas> I'm asking because there are games that are controlled by a game controller (not mouse) and conspiciously don't do this, but either allow free cursor movement, or just make you navigate through the nodes in a flat order.
18:56:32 -!- vyv has quit (Quit: Konversation terminated!).
19:00:17 <decay> are we talking new or old games.
19:00:42 <decay> old games I can see it as a design decision for lots of selectable things.
19:01:05 <decay> if you have, say, 100 things on screen, how do you know which one is the closest.
19:01:29 <decay> computationally it's probably not worth it.
19:02:14 <int-e> b_jonas: So... like DVD menu navigation? :-)
19:03:22 <int-e> The main problem I experience with that when it's not visibly a grid is that very often, you can't undo a right move by doing a left move.
19:04:01 <esolangs> [[Emanator]] N https://esolangs.org/w/index.php?oldid=108218 * Hakerh400 * (+3923) +[[Emanator]]
19:04:10 <int-e> Oh and I also imagine that a naive best-effort implementation can easily make some points unreachable.
19:04:20 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=108219&oldid=108169 * Hakerh400 * (+15) +[[Emanator]]
19:04:33 <esolangs> [[User:Hakerh400]] https://esolangs.org/w/index.php?diff=108220&oldid=107525 * Hakerh400 * (+15) +[[Emanator]]
19:04:34 <zzo38> On DVD you could also use numbers though, as well as selection by cursor. (However, the menu does not always make it clear what numbers to use, unfortunately) I think that numbered menus would be good for some kinds of things though. And, I think DVD menus can't have 100 things on screen at once; I think I read once they are limited to 64 items per page?
19:05:07 <zzo38> But, I know what you mean that they are not all arranged neatly and you have to push the direction to move the cursor; for example, the map in Pokemon Card GB2 is like that. I would hope there would be a better way to do it.
19:06:19 <esolangs> [[Emanator]] https://esolangs.org/w/index.php?diff=108221&oldid=108218 * Hakerh400 * (-53)
19:06:28 <int-e> b_jonas: So... I don't know. I think the d-pad-like-a-mouse thing is done because point-hopping is hard.
19:07:00 <int-e> especially if the targets aren't fixed.
19:07:18 <zzo38> I don't really like the "d-pad-like-a-mouse" much either though
19:07:23 <decay> if you're selecting units in a game.
19:07:27 <decay> and you have 100 units.
19:07:40 <decay> to pick the shortest distance, you need some overlay structure that you update/can query.
19:07:55 <fizzie> This vaguely reminds me of the challenges / navigation strategies of XMonad directional navigation.
19:07:57 <decay> quadtree or something to limit your reach.
19:08:01 <fizzie> https://hackage.haskell.org/package/xmonad-contrib-0.17.1/docs/XMonad-Actions-Navigation2D.html for details.
19:08:36 <int-e> decay: you probably need to provision some extra dummy target points... so overlay a kind of grid...
19:08:50 <int-e> quadtree... is probably not very intuitive
19:09:04 <int-e> or maybe I should address b_jonas for this?
19:09:11 <decay> not intuitive for the user but necessary for fast lookups.
19:09:29 <fizzie> It doesn't consider performance (generally not an issue with windows), but it does have bunch of detail -- including in https://web.cs.dal.ca/~nzeh/xmonad/Navigation2D.pdf -- about reachability and such.
19:09:33 <int-e> oh, as an internal data structure, sure.
19:10:12 <int-e> the user-facing aspects of this seem to be the harder ones
19:10:38 <esolangs> [[Emanator]] https://esolangs.org/w/index.php?diff=108222&oldid=108221 * Hakerh400 * (+36)
19:10:45 <decay> you could do with some kind of dynamic directional display.
19:10:48 <int-e> I can't really tell you what is or isn't "intuitive" here. All I really have is bad user experiences.
19:11:14 <zzo38> If you have to select between 100 units, then I might prefer prefer to make it you can type a 2-digit number, although that won't do for a game pad without numbers. For computer with mouse, you could use the mouse, but that also won't do if you don't have that. For Nintendo DS, the touch screen could be used, with the pencil (it is not as bad as touching it by hand; still I prefer keyboard than touch screen generally)
19:11:19 <decay> if you're controlling it via a D-pad, you have four possible buttons.
19:11:23 <decay> which means 4 possible jumps.
19:11:34 <fizzie> It's easy to end up in a navigation strategy that makes it impossible to reach a particular point. For example, the line navigation of Navigation2D isn't 'complete' for arbitrary set of rectangles tiling the screen.
19:11:38 <decay> so, draw a few colored lines from your selected unit to the one you'd jump to.
19:12:01 <decay> one per D-pad direction.
19:12:23 <zzo38> Yes, that would be much better and less confusing than not showing you.
19:12:49 <int-e> the d-pad-as-mouse approach does solve the "intuitive" portion of the problem convincingly
19:12:57 <int-e> it's just a PITA to actually use
19:13:10 <decay> but, d-pads in general suck.
19:16:13 -!- A_Dragon has quit (Killed (A_Dragon (She told me to do it))).
19:16:36 -!- A_Dragon has joined.
19:17:02 <fizzie> The Navigation2D paper claims its center navigation "is one of the most natural navigation strategies that can easibly be shown to be complete", though with no particular evidence for it.
19:17:10 <zzo38> I think d-pads in general can be OK in cases where it is sensible, but that is not always the case; sometimes they have to be used even though something else would be much better
19:18:00 <zzo38> Drawing lines from the cursor to the other objects that you can move adjacent to, seem like it would help a bit in the circumstance where it is necssary to fit it with these controls because you do not have any better controls
19:37:57 <Sgeo> Can the hyperreals be projectively extended with a point at infinity? So then there's omega which is infinite and a bunch of stuff, yet another infinity "greater" than it (might not make sense to compare, I don't know if ordering works when there's an unsigned infinity)
19:38:47 <Sgeo> https://u.math.biu.ac.il/~katzmik/88-132.html
19:38:59 <Sgeo> Question 1. Does infinity belong to the hyperreals?
19:38:59 <Sgeo> Answer. The infinity symbol ∞ is often added to the reals in calculus and analysis courses. The resulting number system is sometimes called the extended reals. This extended number system is of course not a field, and is not related to the hyperreals. The hyperreals form a field that contains many infinite elements, but the infinity symbol is not one of them. One can also adjoin the infinity symbol to the hyperreal line, resulting in an extended hyperrea
19:38:59 <Sgeo> l line. I am not sure we will need this in the course but if we do it will be signaled appropriately.
19:43:18 <int-e> Sgeo: projective extensions aren't ordered even if you start with an ordered field... the infinity glues the positive numbers to the negative numbers.
19:54:28 -!- Noisytoot has quit (Ping timeout: 276 seconds).
19:57:48 -!- Noisytoot has joined.
20:34:05 <b_jonas> "can't undo a right move by doing a left move" => yes, that's why you need hidden state, just like many text editors have when you keep pressing the down arrow button from a long line to a short line to a long line
20:35:03 <b_jonas> int-e: here I'm assuming that the sprite locations are fixed
20:37:11 <b_jonas> fizzie: thanks for the link
20:37:44 <int-e> b_jonas: but with hidden state it becomes less predictable
20:38:29 <int-e> (which is kind of almost synonymous to "intuitive")
20:40:44 <b_jonas> the text editor that remembers the visual column when you go through a short line (or a line that has a multi-cell character) is intuitive.
20:41:07 <b_jonas> so I don't think it is necessarily less intuitive
20:41:21 <b_jonas> but it might turn out to be not necessary
20:43:01 <int-e> b_jonas: Hmm, I guess you have a point there... I guess state that is forgotton once you change from vertical to horizontal movement is okay.
20:43:29 <b_jonas> that xmonad article is kind of a different though related task, I am asking about point-like (small) sprites
20:43:41 <b_jonas> the article is about windows that needn't be small
20:54:06 <int-e> windows also tend to be relatively low in numbers
20:57:17 <int-e> b_jonas: How would you tackle https://int-e.eu/~bf3/tmp/nav5.png :-/
20:58:00 <int-e> (so sprites in a 5 pattern from a die)
20:58:22 <int-e> That's adversarial, of course.
20:59:55 <int-e> and it /might/ just be best to add extra navigation points in that case, https://int-e.eu/~bf3/tmp/nav5h.png
21:00:44 <int-e> But maybe I'm pushing that particular idea too hard... there needs to be a visual indicator of those extra point's existence at least.
21:08:33 -!- wpa has quit (Quit: Connection closed for inactivity).
21:24:59 <b_jonas> int-e: my idea was that in general I cluster the points to a hierarchical tree structure where the depths are alternatingly horizontal and vertical (the depth isn't uniform). I'm not sure this would allow an intuitive enough navigation of course. so those five points would probably either be broken to three rows so you can only go to/from the center point with the up/down buttons, or to three columns so
21:25:05 <b_jonas> you can go to/from the center point only with left/right, but this is right on the boundary of which one of the two they're separated in.
21:25:31 <b_jonas> some navigation overlays could probably help this, showing with little arrowheads how far the left/right/up/down keys go
21:28:25 <b_jonas> also there'd be hidden state, so if this is three rows then if you press down twice from the top left point you go the bottom left, but if you press down twice from the top right point then you go to bottom right, even though they both go through the center point
21:29:10 <b_jonas> a tree structure would guarantee that every point is reachable, the question is how intuitive it is to the user how to go to a point
21:31:42 <b_jonas> the hidden state also helps in that if you press down then either the selection doesn't move or you can press up to return to your previous point
21:32:10 <b_jonas> if it's not quite intuitive how to navigate then it's important that you can undo mistakes easily, at least in the short term
21:32:22 <b_jonas> (longer sequences of keypress aren't always invertible)
21:38:27 <esolangs> [[Omicron]] https://esolangs.org/w/index.php?diff=108223&oldid=107801 * DrKilobyte * (+13) /* Instructions */
21:38:51 <esolangs> [[Omicron]] https://esolangs.org/w/index.php?diff=108224&oldid=108223 * DrKilobyte * (-5) /* Instructions */
21:39:48 <esolangs> [[Omicron]] https://esolangs.org/w/index.php?diff=108225&oldid=108224 * DrKilobyte * (+7) /* Truth machine */
21:44:26 <esolangs> [[Omicron]] https://esolangs.org/w/index.php?diff=108226&oldid=108225 * DrKilobyte * (+146) /* Examples */
21:44:42 <esolangs> [[Omicron]] https://esolangs.org/w/index.php?diff=108227&oldid=108226 * DrKilobyte * (+18) /* Fibonacci sequence */
21:50:11 <esolangs> [[Omicron]] https://esolangs.org/w/index.php?diff=108228&oldid=108227 * DrKilobyte * (+1) /* Examples */
22:33:16 -!- __monty__ has quit (Quit: leaving).
23:33:08 -!- FreeFull has quit.
23:37:12 -!- Noisytoot has quit (Quit: ZNC 1.8.2 - https://znc.in).
23:40:44 -!- Noisytoot has joined.