00:16:48 -!- sebbu has quit ("@+"). 02:32:41 -!- kwertii_ has joined. 02:40:26 -!- kwertii_ has changed nick to kwertii. 03:31:52 -!- kwertii has quit. 03:53:21 has anyone done an impure lazy language? 04:03:58 -!- puzzlet has joined. 05:47:11 -!- puzzlet has quit (Read error: 110 (Connection timed out)). 06:56:00 Define "lazy" and "impure". 06:58:24 lazy = call by need; impure = has imperative constructs 07:11:20 -!- GreaseMonkey has joined. 07:12:24 -!- GreaseMonkey has changed nick to N0body. 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 08:21:23 -!- ihope has quit (Read error: 54 (Connection reset by peer)). 09:40:28 -!- pikhq has quit (Read error: 110 (Connection timed out)). 10:17:31 http://www.ioccc.org/2001/herrmann1.hint 10:17:36 10:40:27 gonna go now, cya 10:40:45 -!- N0body has quit ("Hasta la Vista(R)"). 11:19:00 -!- andreou has joined. 11:44:16 -!- oerjan has joined. 12:44:11 -!- lament has quit (Read error: 110 (Connection timed out)). 12:59:59 -!- nooga has joined. 13:00:01 he 13:03:02 -!- Doomguy0505 has joined. 13:05:39 -!- Doomguy0505 has quit (Client Quit). 13:08:35 -!- ihope has joined. 13:08:44 Security proofs... interesting idea. 13:37:26 i wonder how to make yacc to report all syntactic errors in parsed text 13:45:20 i think you need to put error tokens in the productions so yacc can know how to continue after an error 13:47:30 See the section on "Error recovery" in "info bison" 13:49:10 afk 14:11:50 back 14:20:29 -!- jix has joined. 14:30:00 -!- jix__ has joined. 14:38:48 -!- jix has quit (Read error: 113 (No route to host)). 14:57:35 -!- jix has joined. 15:05:45 -!- jix__ has quit (Read error: 110 (Connection timed out)). 15:19:20 -!- oerjan has quit ("Dinner"). 16:39:46 -!- sebbu has joined. 17:41:41 -!- lament has joined. 18:25:51 -!- pikhq has joined. 18:44:59 -!- erider has quit (Read error: 110 (Connection timed out)). 18:45:38 -!- erider has joined. 18:56:56 I propose a deathmode for Malbolge. 18:58:13 the opposite of a wimpmode? 18:58:31 like making it self-encrypt like malbolge? 19:00:45 Uh. . . Making Malbolge encrypt like Malbolge makes it. . . Malbolge. :p 19:01:02 2d malbolge. :D 19:01:11 And yeah, it's the opposite of a wimpmode. 19:01:17 with a different instruction set, too 19:01:27 3d encrypting stack-based Malbolge. 19:01:37 there ya go 19:01:47 So, the push operation also calls crazy on the thing to be pushed. 19:02:25 even better- replace the stack with a queue to make common operations less convenient 19:02:40 Better than a FIFO queue. 19:02:56 LIFO. 19:03:45 Err. 19:03:48 Um. 19:03:58 * RodgerTheGreat scratches his head 19:03:59 FINO 19:04:03 If you will excuse me, I'm going to realise the implications of what I just said. 19:04:05 first in never out. 19:04:12 FIMO. 19:04:16 First in middle out. 19:04:22 pikhq: yeah, I was trying to wrap my brain around that with some difficulty 19:04:46 pikhq: wouldn't FIMO just cut the thing in half, effectively? 19:05:01 or make parts inaccessible, at least? 19:05:05 Nope. 19:05:16 Each pop would take from the exact middle. 19:05:37 ah, yeah- you just have to dump out large parts to get to elements deeper than the middle 19:05:41 (averaging two cells if the middle is in between two cells) 19:05:51 my last sentence was confusing 19:06:03 but I understand what you mean 19:06:07 LIFO is a normal stack. XD 19:07:37 i like last in first out 19:07:39 for example 19:08:03 you take an empty stack, push 1, pop 5, push 5, pop 1, then destroy the stack. 19:08:16 it needs a time machine to work, though. 19:08:39 and of course if you don't push 5 after popping 5, the universe collapses. 19:09:04 -!- oerjan has joined. 19:27:57 Malbolge? That's a hack. 19:30:40 -!- ihope has quit ("Reconnecting..."). 19:32:39 -!- ihope has joined. 19:33:20 Okay, judging by the clog logs, what I tried to say didn't get said... 19:33:29 Trying this again. 19:34:59 Malbolge? That's a hack. Go build me a universal constructor/computer in Conway's Game of Life and program it to construct anything given its layout and a description of the space it's allowed to use for construction. 19:36:11 It's allowed to fill up an infinite strip of arbitrary width, but it can't venture beyond that strip. You decide what slope the lines that bound the strip should be. 19:36:49 Go give me a proof of that being possible. 19:36:54 (there is none as of yet.) 19:37:06 Well, you can at least build a universal computer! 19:37:14 Heck, go prove it for me :-P 19:37:15 Yeah; I've got one. 19:37:21 You have one? 19:37:30 There's a Turing machine in Life. 19:37:36 I didn't design it, but I have it. ;) 19:37:40 Infinite tape and everything? 19:37:53 Eh, you can't claim to have designed everything! 19:37:56 The tape is merely finite, but that's an implementation detail. 19:38:11 "Hey, I found a pattern that moves!" 19:38:27 It's trivial to extend the tape to however large you wish it to be. . . 19:38:40 Yes, but it doesn't count unless it's infinite. 19:38:41 If I had a Turing machine here, then the tape would be infinite. 19:39:10 But, I have to settle for a machine that has finite storage. 19:39:26 You don't need infinite storage to run an infinite pattern! 19:39:45 Well, maybe. Not necessarily. 19:39:46 You do when the tape consists of a loop of gliders. 19:40:01 If the simulator's clever enough, it'll find a way. 19:40:11 ...Wait, a loop? 19:40:48 I guess you'd need cleverness to simulate an infinite loop--that is, one that loops but is still infinite. 19:41:05 An actual loop, not just a repetition. 19:41:41 But surely there are actual universal computers in the Game of Life. 19:42:23 Yes. 19:42:25 It's been proven. 19:43:01 Ones that have actually been built. 19:43:52 Except for the memory requirement, one has been built. 19:44:04 http://www.igblan.free-online.co.uk/igblan/ca/ 19:44:12 Thus proving the possibility a *second* time. 19:44:36 Ah. 19:44:43 Didn't know about that Life URM. 19:44:48 "Unlike the finite tape of Paul Rendell's marvellous Turing Machine, the values in the URM's registers are unbounded." 19:45:20 Rendell's is a literal Turing machine, not merely Turing complete. . . 19:45:27 And that URM, apparently, has infinite storage. 19:46:38 ihope: Happy now? 19:46:49 Yup. 19:47:45 And I can come up with a *third* proof of Turing completeness for Life (although it is, unfortunately, circular logic). . . 19:47:56 There's a pattern called the "unit cell". 19:48:05 Which emulates a single Life cell. 19:48:23 Placing enough of those patterns together nets you a Life simulator in Life. 19:48:46 Unit cells can be made arbitrarily big... though that's rather obvious, isn't it? 19:48:54 Yeah. 19:49:15 just iterate the construction 19:49:20 Exactly. 19:51:22 Now make a unit cell rake! :-) 19:53:52 Make a universal constructor. 19:54:35 Preferably one with a higher period than the unit cell. 19:59:43 They have periods? 20:00:38 * ihope ponders universal constructor borders 20:01:32 Well, it'd probably be a different period for whatever it's constructing. 20:01:49 (unless you magically make an O(1) universal constructor) 20:02:18 You know, orthogonal strips probably actually aren't that bad for universal constructors. 20:03:45 That would simplify the border thing. Then again, the border thing isn't complicated. 20:04:10 Hmm... 20:05:48 Oh, people are probably happier with diagonal stuff than orthogonal stuff. 20:06:13 Gliders are more agile than XWSS. 20:07:24 Borders can look like this, then: http://pastebin.ca/567050 20:08:49 # is the constructor exclusion zone. The constructor may not change these cells unless otherwise specified. 20:10:09 $ is the pattern exclusion zone. The constructor may assume that these cells are... hmm, just a minute. 20:11:12 It may assume that these cells are dead unless otherwise specified. 20:11:33 The constructor goes on the left side. 20:11:44 (And the border extends infinitely in both directions.) 20:12:04 Generally, "otherwise specified" is the same in both cases. 20:13:34 The border is only crossed when the constructor and the pattern flash to each other. 20:15:16 Protocols for flashing these could be called diagonal border flash protocols! 20:15:43 Sounds fun, doesn't it? 20:16:26 testBorder (bx,by,cut) (x,y) = bx*x+by*y >= cut 20:16:35 -!- sebbu2 has joined. 20:17:30 Testing whether something's above a line, eh? 20:17:39 (And I'm using "above" loosely here :-P) 20:17:45 (bx,by) would be orthogonal to the border, cut would be the value at the border 20:18:13 (as a vector) 20:19:23 generally, testing whether something is in a half-space 20:19:44 Yeah, that. 20:22:23 -!- nooga has quit (Remote closed the connection). 20:23:07 -!- nooga has joined. 20:24:12 -!- sebbu has quit (Read error: 60 (Operation timed out)). 20:25:08 Wow! The universal register machine is failing miserably! 20:25:12 -!- Bigcheese has joined. 20:25:19 moooooooooorniiiiiiiiing 20:25:22 not actually 20:25:25 afternoon 20:26:56 ihope: you would think it would have been tested? 20:27:13 Maybe it's not the pattern that's wrong. 20:27:30 Or do you know that it is? 20:27:31 ihope: can your life program handle that big patterns? 20:27:39 Yup. 20:27:55 I've been running "Igblan P1 URM" for about 350,000 generations now. 20:27:58 then i know nothing (although i am not from Barcelona) 20:28:14 ...what? 20:28:31 (sneak Fawlty Towers reference) 20:28:35 This speed is boring. /me speeds it up 20:29:54 Yup. This pattern doesn't seem to fail miserably after 10,000,000 generations. 20:30:11 Oh, now it's done. 20:31:12 Hey, it spit stuff out! 20:32:49 the Life turing machine (not universal) emits vast amounts of gliders 20:32:59 well, enough to make a mess 20:38:32 Really a shame that P30 URM is the only one that fails miserably. 20:40:21 hm? 20:40:38 It's the biggest and the best, except that it's not the best. 20:40:42 And maybe not the biggest. 20:41:30 interesting how this life stuff is going from magic to engineering 20:42:07 It used to be magic? 20:42:47 theory: as technology progresses, things become insufficiently advanced in comparison 20:43:37 well, the invention of the Gosper Gun was amazing at the time; there had not been a proof that a population could become unbounded even 20:44:36 Clarke said that any sufficiently advanced technology becomes magic. This is the wrong way round. Any DnD player knows that any sufficiently well-understood magic becomes technology. 20:45:09 Indeed. 20:45:16 this should be one of the corollaries to Clarke's law 20:45:40 Any sufficiently advanced technology is indistinguishable from magic. 20:45:53 Any sufficient advancement of technology distinguishes things from magic. 20:46:15 s/technology/theory/ in the latter. 20:47:35 And don't forget these two: "Any technology distinguishable from magic is insufficiently advanced" and "any technology, no matter how primitive, is magic to those who do not understand it". 20:48:15 Wait a minute, we can combine these to get what we want. "Any magic, no matter how advanced, is technology to those who do understand it." 20:48:31 ...Well, maybe not that, quite. 20:48:47 "No technology, no matter how advanced, is magic to those who do understand it." 20:49:25 See? I put Freefall to good use! 20:50:09 (For those who favor formatting rules over not being annoying, I put Freefall to good use.) 20:50:54 I think I got my one from a page that complained about how DnD magic wasn't "magical" in the supernatural sense, and offered some things to consider in the designing of an RPG magic system. 20:51:17 ihope: erm, how to you do the underlining 20:51:18 ? 20:52:22 SimonRC: depends on the client. 20:52:31 In ChatZilla, %UFreefall%O 20:53:15 _hm_ 20:53:25 nah, not the same 20:53:56 my usual method is just underscore before and after 20:54:17 but I see that irssi can actually do proper underlining 20:54:19 test 20:54:30 Doesn't seem to work. 20:55:07 Here, have a secret message: %CLI 20:55:15 :-P 20:55:35 But that's probably not actually decodable, so I'll just tell you it says BROCCOLI. 20:55:53 also, bold, colour, and reverse 20:55:58 hehehe 20:56:03 SimonRC: what keys? 20:56:46 TFM (/usr/share/doc/irssi/formats.txt) dixit: 20:56:52 -b set bold 20:56:52 -c#[,#] set foreground and optionally background color 20:56:52 -o reset all formats to plain text 20:56:52 -v set inverted color mode 20:56:52 -_ set underline 20:56:54 -7 same as -_ 20:57:06 So, ne. 20:57:09 these will appear verbatim in the editing line, BTW 20:57:09 lessee 20:57:19 w00t. 20:57:34 on some channels, you will get auto-kicked for colour usage 20:57:59 On others, colour usage is ignored. ;) 20:58:25 ZOMG PONIES!!! 20:58:37 (does that blink, BTW?) 20:58:40 test 20:58:44 finally 20:58:44 underlined 20:58:50 BAD Slashdotter. 20:58:52 SimonRC: Yes. 20:59:52 the top bit of the background colour sometimes means the same as it does for the foreground colour (bright), and sometimes means dark but with the foreground colour blinking. 21:10:19 On some channels, color usage is simply blocked. 21:11:26 Random test block here. 21:11:59 a golden opportunity 21:12:31 And an underlined one, too. 21:13:09 to boldly go where far too many have gone before 21:14:37 * bsmntbombdood sets mode #esoteric +c 21:15:53 * ihope summons lament 21:16:08 * ihope also summons andreou 21:16:26 And fizzie. And Aardappel and Taaus, whoever they are. 21:16:27 * oerjan summons the Great Cthulhu 21:16:33 someone had to do it 21:16:44 Ia Ia Cthulhu... uh, Something? 21:16:46 Fthagn? 21:16:51 Fhtagn? 21:16:59 One of those, I'm thinking. 21:17:09 Wikipede it. 21:17:27 Fhtagn, apparently. 21:24:04 Shouldn't there be an apo-strophe in there somewhere? 21:28:04 Why did you stick a hyphen in apostrophe? 21:28:37 I LIVE 21:28:53 Was there a specific reason for the summons? 21:29:56 you have angered fizzie 21:30:32 No, no, just curious. 21:32:12 Fizzie == Cthulhu? 21:32:28 (otherwise, we should've just said Ia Ia, Fizzie Fhtagn!) 21:34:24 Closest I've been to Cthulhu is when I bought an adorable Cthulhu plush doll thing for a friend. 21:35:29 Well, then. 21:35:35 Ia Ia, fizzie fhtagn! 21:37:37 I'm not quite sure what's the proper response to that, but I guess it has something to do with devouring something. 21:38:17 Here's some chips. 21:40:38 Oh yes, freenode had that +c mode which filtered out about all formatting codes, including ANSI escapes. 21:42:34 -!- ChanServ has set channel mode: -stm+nc. 21:42:49 I wonder if that was the thing I was summoned for. 21:42:55 what? 21:43:19 not all, apparently 21:43:32 fizzie: It was. 21:43:39 This ought to be underlined. 21:44:05 eep 21:44:18 you evil censor you! 21:44:32 ‭‮zomg backwards 21:44:35 C is for Censorship! 21:46:19 C is for Coredump, actually 21:46:22 lots of them 21:46:36 Segmentation fault (core dumped). 21:46:42 hmm 21:46:43 MATLAB always dumps core when I exit it. 21:47:01 better than when you start 21:47:33 The apple is delicious! --more-- Core dumped. 21:47:38 :-P 21:48:31 -!- jix has quit ("CommandQ"). 21:49:21 The "Segmentation fault (core dumped)." fortune message is evil; I once spent something like 10 minutes trying to figure out what line in my login files had dumped core, before realizing what it was. 21:49:41 :E 21:54:59 It seems fizzie has successfully been summoned. 21:55:01 As has lament. 21:55:14 lol 21:55:25 I wonder if andreou is on the way. 21:55:45 i've never seen andreou talk i don't think 21:59:03 fizzie: a worse one is the tale of a box hwhere everyone was root... 21:59:19 one guy got the fortune about the bit bucket being full 21:59:33 It is amazing how many things rely on the presence of /dev/null 21:59:51 And that is has correct permissions, user, group, etc 22:00:02 my favorite feature of lisp right now: quasiquote 22:02:23 good for macros 22:02:53 i'm doing some source to source translations right now and it's very helpful 22:04:02 SimonRC: someone deleted /dev/null? 22:07:49 yes 22:09:41 Fun. 22:10:17 Seems it'd be easier to cat /dev/null > /dev/null 22:10:26 :-) 22:10:39 Then again, I don't know just what > does. What does it do? 22:12:07 reads from /dev/null eof immediatly 22:13:41 > re-directs stdout 22:14:27 /dev/null is opened for writing and reading, separately. neither deletes it or changes its special status 22:14:35 *nor 22:15:27 Does > concatenate or replace? 22:15:35 And if it replaces, how? 22:15:43 replace, but by opening and truncating 22:15:51 >> appends 22:16:21 Opens it, deletes all its contents and starts writing, then? 22:16:27 yep 22:16:54 but since /dev/null is not an ordinary file, truncating it has no effect 22:16:56 I've always felt a bit sorry for /dev/full, because /dev/null is what everyone only talks about. 22:17:26 full - always full device -- "Writes to the /dev/full device will fail with an ENOSPC error. This can be used to test how a program handles disk-full errors." 22:19:03 There's also a strange sort of sensibility in leaving a dd if=/dev/full of=/dev/null running at a low priority. Gives you a "I'm doing my part to restore the balance!" feeling. 22:19:28 wow i thought you were joking :D 22:19:54 What's that command do? 22:20:48 'dd' moves bytes; reads from /dev/full always return zeros, so it reads zeros out of /dev/full and writes them to /dev/null, which discards them. 22:21:19 Of course it's all quite futile: full is never going to run out of zeros, and null isn't going to fill up. But it's the thought that counts. 22:21:50 But really, all you're doing is throwing away zeros. 22:21:55 You should put them into /dev/zero instead. 22:22:15 I really thing that one already has more than enough zeros in it. 22:22:27 My God, it's full of zeros! 22:22:42 I guess that's true. 22:23:07 Maybe if you write enough zeros into /dev/null, one of them will actually get through... 22:25:35 where to? 22:26:48 eventually /dev/null will collapse into a black hole, creating a new big bang on the other side 22:27:22 hm... 22:27:55 actually whatever you put into /dev/null will be released as heat. 22:28:49 Ah. 22:29:33 assuming your hardware cannot actually keep infinite information, in which case my first explanation will apply. 22:31:03 My computer can hold infinite information, but only if it's compressed. 22:31:39 I know of a pretty good compression scheme for just these purposes. 22:32:01 Namely, reverse the input. Reversing the input, naturally, is something that can be undone: just do it again. 22:32:58 Now, you can write a program that reverses its input pretty easily. If you pipe /dev/random into it, nothing ever comes out, so you can conclude that /dev/random compresses to the empty file. 22:33:10 well in principle that compression scheme is as good as it gets 22:33:22 I haven't tried reversing the empty file, but I'm sure that if I did, I'd get /dev/random. 22:33:47 Oh, only if you count random infinities of information as actually being infinite. Computable ones can easily be compressed. 22:35:00 hm... i guess a compression scheme that actually treated random information has being zero could be useful, since it is only the order in information that is usually interesting 22:35:06 *as 22:37:12 relevant link: http://en.wikipedia.org/wiki/Reversible_computing 22:37:42 Would you call "There's useful information in here. e=SzHr/!]LQ:vMw2jXe/*j38v5Q"TO [bp[n]~c41j#!O3RgCt%&_!6%YrH4pNI..." something that should be treated as zero? 22:38:28 of course not. There's "There's useful information in here." in there. 22:39:35 i suppose such a scheme would work really bad on already compressed data. 23:04:24 oerjan: However, "There's useful information in here." could be generated by /dev/random. 23:04:51 not _terribly_ likely. 23:05:15 True. 23:05:16 "e=SzHr/!]LQ:vMw2jXe/*j38v5Q"TO [bp[n]~c41j#!O3RgCt%&_!6%YrH4pNI" is terribly unlikely also 23:05:22 But, then, nor is anything else. 23:07:33 basically, random in this case would mean completely incompressible 23:07:51 for some approximation of compressible 23:08:11 a bunch of printable characters is hardly random, and very easy to compress :) 23:08:27 hm... right 23:08:52 you need to keep only the compressible part of the information. interesting paradox 23:11:55 the most information would be in text that was chaotic, on the edge of order and disorder. 23:12:37 Encrypted text. 23:13:34 nothing is random. 23:14:18 No, everything is. 23:14:18 'random' simply refers to the method of generation of data 23:14:25 good encryption is practically indistinguishable from random 23:14:34 once you have the data, the term 'random' can no longer be applied to it 23:14:56 good encryption is practically indistinguishable from data produced by a random process 23:15:31 but of course a random process can produce any string whatsoever, just as a non-random process can produce any string whatsoever. 23:15:31 random has many meanings 23:16:34 "random" describes the process; "incompressible" describes the usual result 23:16:59 (but randomness is not the only way to generate incompressible results) 23:17:12 err, wait, it is 23:17:14 :) 23:17:23 Nope. 23:17:54 "incompressible" only describes a certain string when compressed with a *certain algorithm*. . . 23:18:09 I can create crapola-compression, which makes most results incompressible. 23:18:53 -!- kwertii has joined. 23:19:59 pikhq: incompressible by _any_ algorithm :) 23:20:25 no such thing 23:20:41 oerjan: no? 23:20:59 because for any string, you can take an algorithm that produces that string from the empty one 23:21:25 oerjan: if the string was generated by a random process 23:21:54 One can still produce an algorithm which does if(input == "") output("Random string here."); 23:21:56 oerjan: then that algorithm will be as long as the string, and consist of an 'output' statement... 23:22:28 i suppose i'm talking about kolmogorov complexity, not compressibility. 23:22:33 the length of the algorithm is not included 23:22:48 i definitely am talking about kolmogorov complexity :) 23:22:54 -!- kwertii_ has joined. 23:23:28 randomness is a superturing thing 23:23:47 -!- kwertii has quit (Connection reset by peer). 23:24:26 still, there isn't any meaningful way to describe data as "random" unless you simply refer to the way it was generated. 23:24:32 Then perhaps you should say what you mean, not assume that we can distill it from the air. 23:24:34 -!- kwertii_ has changed nick to kwertii. 23:24:51 pikhq: if i can't assume that in #esoteric, where can i? :( 23:25:03 lament: Even here, we have to say what we mean. 23:25:12 how thoroughly boring. 23:25:22 What sets us apart is that what we mean produces "Why, god, WHY?!?" as the answer. :p 23:26:34 Grr. . . 23:26:41 Someone set -Oslow on my Emacs build. 23:27:24 despite all the bad things people say about emacs 23:27:35 there isn't a single problem with it that an uninstall can't solve. 23:28:04 lament: unlike WinHugs 23:28:36 what happens after you uninstall winhugs? :) 23:28:54 nothing, the uninstall crashes before removing anything :) 23:29:39 oh. 23:29:46 useful :) 23:29:48 Infinite strings can be described as being random or not. 23:29:57 ihope: how? 23:30:07 Well... I think. 23:30:11 actually 23:30:19 that doesn't contradict me at all 23:30:19 If it can be defined at all in any way, it's not random. Otherwise, it is. 23:30:29 like i said, randomness refers to the process 23:30:36 Jargon file (iirc) lists the meaning "Eight Megs And Constantly Swapping" for EMACS. That particular backronym is perhaps a bit dated; even my personal computing device has 256 times more memory than that. 23:30:38 when dealing with an infinite string, you're dealing with a process 23:30:45 since you can't have actual infinite information 23:30:50 Indeed... 23:31:45 infinite strings can have average entropy per bit or char 23:31:54 fizzie: Entirely-too Much And Constantly Swapping! 23:32:04 oerjan: which you can't determine 23:32:11 oerjan: so that's a problem 23:32:37 oerjan: either the string is generated by a known non-random process, allowing you to calculate the entropy but then of course you know it's not random 23:33:00 oerjan: or it is generated by a random process, in which case you can't ever get the entire string, so you can't calculate its entropy either. 23:33:19 no but you can calculate it with probability 1 :) 23:33:57 for suitable random processes 23:34:01 not 1 23:34:13 you can only analyze a finite portion of it :) 23:34:26 not statistically significant 23:34:26 no, you analyze the process, not the string 23:34:29 oh 23:34:42 Said backronym, IIRC, was invented by Stallman. 23:34:53 (you may know Stallman better for his Editor MACroS, written in Teco, and GNU Emacs, written in Elisp) 23:34:55 oerjan: again, if you know the process is random, then you already know the process is random :) 23:35:18 oerjan: and if you _don't_, then you can't tell anything by looking at the data produced 23:35:39 (because the data produced is not the "infinite string" we're after) 23:36:22 hm... you might be able to converge toward the correct entropy 23:37:35 -!- sebbu2 has quit ("@+"). 23:41:51 oerjan: except that, the process being random, you don't know if its behavior isn't going to suddenly change completely 23:42:16 (true of some non-random processes as well, at least in practice (digits of pi)) 23:43:36 memory usage arguments against emacs are completely irrelevant nowadays 23:46:09 right... it is easy to make a sequence that switches say between two different behaviors at large indices. in fact the entropy would not be clearly mathematically defined then 23:46:23 *switches repeatedly 23:53:12 all the problems come from the fact that true randomness is superturing and hence cannot be analyzed algorythmically :) 23:53:16 algorithmically 23:57:46 oerjan: surely the king of ununinstallability is AOL. Bits of it were floating around for years 23:58:23 ic 23:58:44 23:27:18 < oerjan> lament: unlike WinHugs