00:02:07 -!- oerjan has joined.
00:04:14 <lambdabot> ENVA 112250Z 12005KT 9999 -RA FEW039 SCT074CB BKN098 14/12 Q0998 RMK WIND 670FT 23010KT
00:13:42 <lambdabot> EGLL 112250Z AUTO 25012KT 9999 FEW032 15/08 Q1015 NOSIG
00:30:10 -!- Phantom_Hoover has quit (Read error: Connection reset by peer).
00:37:21 -!- sleffy has quit (Ping timeout: 260 seconds).
00:41:29 <HackEgo> [wiki] [[Special:Log/newusers]] create * Theking42 * New user account
00:45:02 <HackEgo> [wiki] [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=52145&oldid=52135 * Theking42 * (+148) /* Introductions */
00:45:10 <HackEgo> [wiki] [[Total BF]] https://esolangs.org/w/index.php?diff=52146&oldid=28221 * Theking42 * (+43) Added some categories
00:50:39 <HackEgo> [wiki] [[Category:Total]] N https://esolangs.org/w/index.php?oldid=52147 * Theking42 * (+585) Created page with "A total programming language is one in which all programs are guaranteed to terminate. As such, such languages are not Turing complete. It is also impossible to implement a se..."
01:00:15 -!- Akaibu has joined.
01:07:28 <HackEgo> [wiki] [[Category:Total]] https://esolangs.org/w/index.php?diff=52148&oldid=52147 * Theking42 * (+203)
01:11:22 -!- sleffy has joined.
01:12:04 -!- jaboja has quit (Remote host closed the connection).
01:23:40 -!- jaboja has joined.
01:38:46 -!- jaboja has quit (Remote host closed the connection).
01:51:45 -!- doesthiswork has joined.
02:00:12 -!- LKoen has quit (Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.”).
02:10:26 -!- augur has joined.
03:15:45 <HackEgo> [wiki] [[Special:Log/newusers]] create * PedroContipelli * New user account
03:24:15 <HackEgo> [wiki] [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=52149&oldid=52145 * PedroContipelli * (+115)
03:24:54 <HackEgo> [wiki] [[Language list]] https://esolangs.org/w/index.php?diff=52150&oldid=52142 * PedroContipelli * (+11)
03:31:09 <HackEgo> [wiki] [[Language list]] https://esolangs.org/w/index.php?diff=52151&oldid=52150 * Oerjan * (-11) Undo revision 52150 by [[Special:Contributions/PedroContipelli|PedroContipelli]] ([[User talk:PedroContipelli|talk]]) (We have that in the joke language list)
04:26:25 -!- oerjan has quit (Quit: Nite).
05:48:02 <zzo38> Is this document OK? http://zzo38computer.org/fossil/farbfeld.ui/wiki?name=ffjpeg
05:58:09 -!- lifthrasiir has quit (Remote host closed the connection).
06:07:32 -!- lifthrasiir has joined.
06:52:06 <HackEgo> [wiki] [[Talk:Kangaroo]] N https://esolangs.org/w/index.php?oldid=52152 * Zzo38 * (+288) /* Matrix Kangaroo */ new section
06:58:08 -!- FreeFull has quit.
07:17:37 -!- Sgeo_ has joined.
07:21:29 -!- Sgeo has quit (Ping timeout: 268 seconds).
08:08:33 -!- sleffy has quit (Ping timeout: 240 seconds).
08:58:42 -!- augur has quit (Remote host closed the connection).
08:59:31 -!- doesthiswork has quit (Quit: Leaving.).
09:17:20 -!- augur has joined.
09:22:07 -!- augur has quit (Ping timeout: 240 seconds).
10:48:20 -!- augur has joined.
10:52:52 -!- augur has quit (Ping timeout: 246 seconds).
11:00:43 -!- boily has joined.
11:59:50 -!- LKoen has joined.
12:15:30 <HackEgo> usa//USA apparently doesn't stand for United State Automaton.
12:18:48 -!- augur has joined.
12:21:46 <HackEgo> [wiki] [[Talk:Footsteps]] N https://esolangs.org/w/index.php?oldid=52153 * Keymaker * (+407) More undefined behaviour?
12:23:11 -!- boily has quit (Quit: WORTH CHICKEN).
12:23:18 -!- augur has quit (Ping timeout: 246 seconds).
12:47:23 -!- LKoen has quit (Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.”).
12:49:50 -!- h0rsep0wer has joined.
12:52:41 <int-e> . o O ( shouldn't it be "unified" or "universal" )
13:49:19 -!- augur has joined.
13:54:13 -!- augur has quit (Ping timeout: 258 seconds).
14:00:34 -!- doesthiswork has joined.
14:09:39 -!- kerbal has joined.
14:23:37 -!- kerbal has quit (Ping timeout: 260 seconds).
14:28:28 -!- jaboja has joined.
14:38:50 -!- sebbu2 has joined.
14:42:20 -!- sebbu has quit (Ping timeout: 255 seconds).
14:44:53 -!- `^_^v has joined.
14:55:49 -!- h0rsep0wer has quit (Quit: Leaving).
15:17:54 -!- oerjan has joined.
15:19:45 -!- augur has joined.
15:25:54 -!- augur has quit (Ping timeout: 255 seconds).
15:32:21 -!- nullcone has quit (Quit: Connection closed for inactivity).
15:34:25 -!- sebbu2 has changed nick to sebbu.
15:43:10 -!- atslash has quit (Ping timeout: 260 seconds).
15:43:56 -!- atslash has joined.
15:57:31 -!- LKoen has joined.
16:00:32 -!- `^_^v has quit (Quit: Leaving).
16:00:42 -!- `^_^v has joined.
16:24:18 -!- Zarutian has joined.
16:50:14 -!- augur has joined.
16:54:48 -!- augur has quit (Ping timeout: 240 seconds).
17:09:48 -!- atslash has quit (Ping timeout: 240 seconds).
17:10:23 -!- atslash has joined.
17:25:15 <HackEgo> [wiki] [[User:MD XF]] https://esolangs.org/w/index.php?diff=52154&oldid=52115 * MD XF * (+184) Triangular
17:38:03 -!- LKoen has quit (Remote host closed the connection).
17:44:30 -!- jaboja has quit (Ping timeout: 255 seconds).
17:46:06 -!- atslash has quit (Quit: Leaving).
17:48:22 -!- DHeadshot has joined.
17:52:06 -!- augur has joined.
18:12:43 -!- FreeFull has joined.
18:22:02 -!- oerjan has quit (Quit: Later).
18:29:54 -!- erkin has joined.
18:42:14 -!- jaboja has joined.
18:48:07 -!- sleffy has joined.
19:05:32 -!- Kerbal has joined.
19:05:33 -!- jaboja has quit (Ping timeout: 240 seconds).
19:06:38 -!- LKoen has joined.
19:11:03 -!- LKoen has quit (Ping timeout: 240 seconds).
19:21:04 -!- Phantom_Hoover has joined.
19:28:23 <Kerbal> Hey, is the user who wrote Triangular online? I have a question for him or her
19:33:35 -!- nullcone has joined.
19:50:57 -!- wob_jonas has joined.
20:04:18 <zzo38> Does MMIX define a specific method of converting between single precision and double precision numbers?
20:05:36 <wob_jonas> zzo38: yes, but it only stores double precision in registers (just like how traditional 387 only stores extended precision in its registers), so it only has load and store single float instructions, and an instruction that rounds to a single but keeps the result in double format.
20:06:27 <zzo38> I know what instructions it has, I meant if there is a guaranteed result of the way the number is encoded when the conversion is done in either direction.
20:06:38 <wob_jonas> zzo38: this is also analogous to how modern x86 only stores single and double precision in XMM/YMM registers, but now has instructions to load and store half-precision floats (at least one of the half-precision formats)
20:07:27 <int-e> you seem to be talking cross purposes
20:07:46 -!- Sprocklem has quit (Quit: [).
20:08:06 <zzo38> int-e: I do not understand?
20:08:10 <wob_jonas> zzo38: I don't quite understand the question there. the single and double floating point formats are quite well specified, so there can only be flexibility when you need to represent a NaN value. I'm not sure if MMIX specifies how NaNs are represented, and it's possible you have to wait for reworked volume 4 for that.
20:08:58 <wob_jonas> zzo38: it works the same as other operations: you convert by taking the real value the source float represents, and taking the closest representable float in the destination format according to the roudning mode
20:09:39 <wob_jonas> so if the rounding mode is round to nearest, then it takes the float closest to the theoretical value, or the one with zero last bit if there's two equally close ones
20:09:55 <wob_jonas> just like how arithmetic on floats works, as explained in volume 3
20:10:14 <wob_jonas> I'm confused about volume numbers, but you know
20:10:19 <zzo38> I mean if you have one sequence of bits in one format and convert to the other format, if you are guaranteed to get the same sequence of bits as a result on all implementations or not.
20:10:20 <wob_jonas> volume 2 explains how floating point arithmetic works
20:10:35 <zzo38> (Assuming all of the modes and so on are set the same way)
20:10:58 <wob_jonas> zzo38: if the value is not NaN, and you use the same operations and same rounding mode, then you're definitely guaranteed the same sequence of bits in the result. If the value is a NaN, then I'm not sure.
20:12:19 <wob_jonas> For non-NaN, MMIX and other modern cpus work the same way, deterministically. For NaN results, I'm not sure what MMIX does, and x86 is a bit complicated and partly depends on what instructions you use and partly implementation-defined.
20:12:20 -!- erkin has quit (Read error: Connection reset by peer).
20:13:45 <int-e> zzo38: I meant that you asked about how rounding is done and wob_jonas answered with when rounding is done... but it's all okay now
20:15:23 <zzo38> I think that may be a definition should be made up for if the value is NaN, probably whatever kind would be simplest in hardware while still resulting NaN, and then define it as that way.
20:16:50 <wob_jonas> zzo38: there is probably a definition about how MMIX handles NaN, but I'm not sure if it's already in the volume 1 MMIX fascicle, or is only in MMIXware and the part of future volume 2 that talks about infinities and NaNs.
20:17:43 <zzo38> I do not actually have the book, but I can look in MMIXware and see if it says if it is supposed to be guaranteed.
20:21:28 <wob_jonas> Also, what I said above doesn't apply to the x87 transcendent instructions (F2XM1, FYL2X, FYL2XP1, FCOS, FSIN, FSINCOS, FPTAN, FPATAN), which are essentially not deterministic and partly implementation-defined; also nothing I say applies to 287 and 8087 (the chips before 387) which are not modern and has strange quirks.
20:21:49 <wob_jonas> But MMIX and SSE don't have such transcendental instructions, and these x87 ones are kept only for compatibility.
20:22:56 <zzo38> I am asking only about MMIX anyways
20:23:23 -!- erkin has joined.
20:23:54 <wob_jonas> Also the x87 extended precision (10 byte long) format has trap representations that are unsupported and behave in a mostly implementation-defined way, but you can only get those trap representations by directly loading them, not from loading singles or doubles or integers, nor from operations on non-trap representations.
20:27:32 <wob_jonas> As for NaN values on x86 architecture, the way x87 handles them is completely specified; MMX doesn't handle them at all; and the way SSE and modern extensions handles them is mostly but not completely specified (by at least one of Intel and AMD), but is different from the x87 method (and IMO worse). Let me look this up.
20:29:07 <wob_jonas> Obviously results are deterministic only if the settings in the relevant floating point control register (rounding mode and other flags) are given.
20:31:27 <wob_jonas> In the Intel 64 and IA-32 architectures software developer's manual, chapter 4.8.3 tells how NaN behaves.
20:33:26 <\oren\> there is legistlation being proposed
20:33:28 <\oren\> “Communications Over Various Feeds Electronically for Engagement” Act
20:36:15 <Kerbal> That actually makes sense
20:37:02 <wob_jonas> In the AMD manual (possibly an old version I have, I haven't checked for updates), for SSE instructions, chapter 4.3.3.3 is relevant about NaN ruels.
20:38:50 <wob_jonas> The situation is even better than I thought.
20:39:51 <wob_jonas> The representation of a NaN result used for SSE instructions (and modern extensions) is completely defined and so deterministic;
20:41:08 <wob_jonas> and for x87 instructions, Intel defines the result completely (but this is different from SSE instructions), and AMD defines them only almost completely but leaves the sign bit of the NaN implementation-defined in some cases.
20:42:09 <wob_jonas> This means that if you only use modern instructions (SSE, SSE2, AVX etc) on x86, then the floating point operation result is completely deterministic.
20:42:36 <wob_jonas> (Modern x86 does have some other implementation-defined behavior, but that has nothing to do with floating-point representations.)
20:43:51 <int-e> . o O ( it all started with CPUID *runs* )
20:43:53 <wob_jonas> zzo38: sorry for the confusion, and I'm glad I checked this
20:44:47 <wob_jonas> Oh, and by the way the AMD and the Intel definitions are compatible, so apart from that one implementation-defined sign bit on x87, and the other x87 stuff I mentioned above, the results are deterministic even across the two cpu manufacturers.
20:45:08 <wob_jonas> (This is a feature. AMD and Intel are deliberately making compatible cpus.)
20:45:49 <wob_jonas> However, the SSE rules mean that the results are deterministic only for machine code, not for C code.
20:46:39 <int-e> some x86 operations left some flags undefined, is that still the case? (stuff like aaa, aas, das, daa, aam, aad)
20:47:20 <wob_jonas> If you write x+y in C code where x and y are floats or doubles, C does not promise any particular NaN representation, and the compiler has the right to compile this as an addition with either x or y as the first input argument of the instruction, and the NaN representation of the results are different in those cases for some inputs.
20:47:41 <wob_jonas> int-e: yes, there are some flags left in an implementation-defined state
20:48:37 <int-e> (of course those particular instructions have been dropped in x86_64 mode, so sad ;))
20:49:09 <wob_jonas> int-e: no, this still applies to x86_64 slightly: the OR instruction leaves the value of the AF flag implementation-defined.
20:49:55 <wob_jonas> The flag has an unspecified value after the instruction, but using it further isn't undefined behavior or anything crazy like that, it's just unpredictably 1 or 0.
20:50:22 <int-e> (do I still remember this snipped correctly? cmp al, 10; sbb al, 0x3f; das)
20:51:38 -!- sdhand has joined.
20:51:39 <int-e> (I think I got this right: convert a value from 0 to 15 to a hex digit (upper case))
20:51:45 <HackEgo> [wiki] [[User talk:MD XF]] https://esolangs.org/w/index.php?diff=52155&oldid=52126 * MD XF * (-207)
20:51:48 -!- sdhand has quit (Changing host).
20:51:48 -!- sdhand has joined.
20:52:54 <wob_jonas> The AND, OR, XOR, TEST instructions all leave AF in an undefined state (but then people almost never use AF, there aren't even conditional jumps using it, so you only read it by explicitly saving FLAGS or with the decimal instructions).
20:58:11 <wob_jonas> A more significant case is that the shift instructions (SAR, SHR, SHL, ROL, ROR, RCL, RCR, SHLD, SHRD) sometimes leave CF and/or OF (as well as AF) in an undefined state. The exact rules for when are complicated.
21:01:38 <wob_jonas> Yes, sometimes CF is undefined, depending on the exact operation and arguments and inputs.
21:03:47 <wob_jonas> Also the 386 bit scan instructions BSF, BSR leave the destination operand with an undefined value if no bit is found.
21:05:41 <int-e> I guess I only ever cared about CF for RCL, RCR and shifts/rotations by 1 bit.
21:06:00 <wob_jonas> I think the bitwise arithmetic and shift instructions leave some of the flags in an undefined state, because older cpus handle them in different ugly ways, so to define them, intel would have to write complicated documentation about what older cpus do. The bit scan instructions have a different cause: there 386 used to leave the destination registe
21:06:00 <wob_jonas> r unchanged, but insisting on that implementation would slow down modern cpus.
21:06:33 <wob_jonas> int-e: like I said, those flags are sometimes defined, the exact rules are in the Intel and AMD manuals. for the cases most programs care about, they're defined.
21:08:54 <wob_jonas> There are also some undefined results about memory accesses and IO that are essential, that is, caused not by historical compatibility, but because it would slow down the system to make caching or paging or multi-processor memory races deterministic.
21:10:20 <wob_jonas> And there's of course a lot of undefined behavior connected to operations or arguments or field values that are (or once were) reserved for future compatibility, especially with system instructions. There has to be some of these so that the cpu can be extended with new instructions or modes in the future.
21:11:12 <wob_jonas> But generally x86 doesn't have much cases of undefined results for no good reason. It tries to be deterministic and defined except in cases when there's a good reason (history or otherwise) not to.
21:14:27 <wob_jonas> And there are cases when some cases were undefined in past versions of the docs, but are defined retroactively for older cpus too in later versions of the docs because of new extensions.
21:15:17 -!- LKoen has joined.
21:16:49 <wob_jonas> And there are a few borderline cases that used to be defined in old cpu manuals (like 286) but are now either undefined, or defined to always give an error in new cpus.
21:17:00 <wob_jonas> There's not many of these, because they like compatibility, but still.
21:17:03 -!- DHeadshot has quit (Ping timeout: 240 seconds).
21:19:01 <wob_jonas> For example, on 8086, you could use the LOCK prefix with any instruction; now you can only use them with some instructions, and it gives a fault with some instructions that existed on 8086 like shifts.
21:21:47 <wob_jonas> The manuals don't completely define how very old cpus behave, but define a significant portion of it, enough to write typical non-obfuscated programs, and more than enough to write boot loaders that check what cpu they're running on and error out on old cpus.
21:22:37 <wob_jonas> Some of that information is delegated out of the main text to special compatibility chapters, because the main text doesn't want to bother saying "this feature isn't available on cpus older than 386 or 286" too many times.
21:33:36 -!- jaboja has joined.
21:34:27 <Kerbal> Integ 1.1 is out at https://github.com/kerbin111/Integ. (Sorry, zzo38, but I haven't written the wiki article yet)
21:35:17 -!- DHeadshot has joined.
21:35:43 <Kerbal> Integ 1.1 features time, random, and deallocation operators, as well as better error messaging and a better interpreter mode
21:35:51 <Kerbal> in the Python reference implementation
21:54:18 -!- wob_jonas has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
22:16:54 -!- Sprocklem has joined.
22:19:58 -!- LKoen has quit (Remote host closed the connection).
22:25:42 -!- xkapastel has joined.
22:30:54 -!- `^_^v has quit (Quit: This computer has gone to sleep).
22:39:45 -!- esoman has joined.
22:40:00 <esoman> https://area51.stackexchange.com/proposals/110478/esoteric-programming-languages?referrer=FNgVtmBdD3clrEfV5E-5mg2
22:40:56 -!- esoman has quit (Client Quit).
22:48:51 -!- LKoen has joined.
22:55:22 -!- hakatashi has quit (Remote host closed the connection).
22:55:38 -!- hakatashi has joined.
23:07:54 -!- boily has joined.
23:10:07 <lambdabot> CYUL 122200Z 22015G20KT 30SM FEW140 SCT250 31/19 A2978 RMK AC1CI2 SLP084 DENSITY ALT 2100FT
23:15:37 <lambdabot> EGLL 122150Z AUTO 27009KT 9999 NCD 14/10 Q1020 NOSIG
23:18:31 <boily> I love my AC unit.
23:22:23 -!- erkin has quit (Quit: Ouch! Got SIGABRT, dying...).
23:29:07 -!- Phantom_Hoover has quit (Read error: Connection reset by peer).
23:39:59 -!- wob_jonas has joined.
23:40:33 <wob_jonas> In his feature article, Mark Rosewater announces that Wizards have once again found a way to print more new M:tG cards per year than before. This has happened like five times already.
23:40:54 <wob_jonas> Sure, he gives a nice explanation for why the changes are good, but still.
23:41:08 -!- jaboja has quit (Ping timeout: 240 seconds).
23:41:40 <wob_jonas> If you don't care about Standard or new set drafts, you get few of the advantages, and the amount of new cards printed gets harder and harder to follow.
23:44:11 <boily> I don't think they are good or bad changes. just... changes.
23:44:18 <wob_jonas> oh yeah, linky http://magic.wizards.com/en/articles/archive/making-magic/metamorphosis-2-0-2017-06-12
23:44:58 <wob_jonas> boily: I'm not saying they're bad alone, the bad part is that each time they change the structure, whether permanently or temporarily for just one set or block, it goes towards printing more new cards than before.
23:45:35 <wob_jonas> I've no clue what's in the last several years of sets because there are so many new cards that I didn't start to invest the time to get familiar with them.
23:47:38 -!- wob_jonas has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
23:51:45 -!- oerjan has joined.
23:56:59 -!- Warrigal has joined.
23:58:36 -!- tomcr00se has joined.