00:00:24 hm 00:00:38 * RodgerTheGreat rummages around in his box of shit 00:01:03 a box of apples and a string. 00:01:12 heheh 00:01:13 and a jar of sour cream. 00:01:48 and a spoon of Syntactic Sugar (tm) (or any other sugar) 00:01:49 well, the only thing I think I have enough of to make gates with would be horribly ironic 00:02:12 a bunch of Sun ROM chips as fulcrums and Sun RAM as levers 00:02:22 a length of string with an apple on each end, hanging from a pivot 00:02:44 a REAL computer has to be fully edible. 00:02:51 otherwise, what's the point? 00:03:03 Second. 00:03:11 http://www.theapplecollection.com/Collection/objects/images/breadcomputer.jpg 00:03:52 I think I could develop a bread computer based around mold-logic 00:04:05 lemme do some experiments 00:08:50 -!- ehird` has quit (Read error: 104 (Connection reset by peer)). 00:40:12 I think I once asked somewhere how to build a replicator entirely out of water. 00:40:26 And salt, as long as it's done in the ocean. 00:41:32 this was one of my ideas 00:41:43 you and I had an extensive discussion on the matter 00:42:17 Hmm, indeed. 00:42:19 fluidics, temperature/pressure regulation, hydraulic actuation, harnessing power, picrete and the like 00:42:33 That does sound extensive. 00:42:38 it was 00:42:59 do you wish to perform more thought on the matter? 00:42:59 Did we settle on whether to use temperature or pressure to form ice? 00:43:13 I think pressure was determined as more controllable 00:43:24 Mm, let's think of exotic replicators and computers in general :-) 00:43:28 although we obviously maintain an internal temperature near the flux point 00:43:33 Yes, yes. 00:44:07 i want to build some sort of cooler 00:44:15 How do you build even a somewhat stable structure out of ice and water all at the same temperature, though? 00:44:16 I think we should each develop some basic components (logic gates, timers or similarly usable devices) with extremely limited and commonly available materials 00:44:37 or a heat pump, but a real cooler would be better 00:44:41 ihope: I'd presume you'd need to build stuff kinda lego-style 00:44:55 so that you could prefab simple parts and then mechanically assemble them 00:45:07 and then water+cold could be used as a sort of glue or sealant 00:45:43 or with a *lot* of tricky work you might be able to control temperature precisely enough to do some basic self-assembly 00:45:56 possibly a combination of those techniques 00:46:34 All rather complicated :-) 00:47:18 Now, naturally, energy intake has to be done somehow, and naturally, there's naturally current in the ocean. 00:47:21 yeah, I don't think there's any really simple way to do arbitrary manufacturing anyway 00:47:40 We could take in energy at river deltas! 00:47:55 my main energy source idea lied in using the temperature/pressure differential between deep water and the surface 00:48:21 That can be used? 00:48:26 and you could then form some kind of convection pump without moving parts (a big plus!) 00:48:35 I guess temperature can, indeed. 00:48:41 No moving parts is good :-) 00:49:05 it would be inefficient and low-yield, but infinitely(ish) renewable and probably quite robust 00:49:09 Remember that the water at the top has more potential energy than the water at the bottom. 00:49:18 Robustness is very good. 00:49:33 ooh, vortex tube 00:49:42 yeah 00:50:32 I also think that siphoning can be an extremely useful property in generating the 3d-layout of our fluidic circuits 00:50:48 Siphoning... 00:51:44 Gravity makes for a fairly robust power source. . . 00:51:45 siphoning allows us to solve the wire-crossing problem without needing much in terms of backpressure on the system 00:51:53 pikhq: gravity is a power source? 00:51:59 ihope: You can use it as one. 00:52:00 pikhq: yeah, but the machine would need to store kinetic energy to use that 00:52:09 RodgerTheGreat: wire-crossing? It's three-dimensional... 00:52:15 pikhq: how? 00:52:15 Yeah. . . Like, say, using siphoning. 00:52:54 Gravity is harnessed by moving high-density stuff down and low-density stuff up. 00:53:25 * pikhq looks back to see what you've been doing. . . 00:53:26 It'd be a good idea to get a list of every possible energy source. 00:54:17 The things that vary in water are velocity, temperature, pressure, salinity? 00:54:24 Yeah. 00:54:38 One could, at least in the ocean, obtain some power via waves. . . 00:54:49 Yup. That's velocity, no? 00:54:54 . . . Right. 00:55:04 with an icemachine, I'd say our biggest limitation is that many energy sources need to be carefully controlled to avoid destroying the machine and that mechanical parts need to be kept very simple 00:55:18 Oh, water also has height, of course. 00:55:35 Though that only affects pressure, I guess. 00:55:45 And, of course, fluidic circutry itself makes for a really, really large system. 00:55:48 wave action is a potential source, but it'd probably be difficult to harness the motion on more than one axis 00:55:52 And the collective height energy of the entire ocean isn't likely to change much. 00:55:56 pikhq: true 00:56:55 So the energy sources are velocity differentials, temperature differentials, salinity differentials, and whatever pressure does. 00:57:09 fluidics are primarily limited here by our ability to manufacture things, however. There's also the issue that we'll need tubes wide enough that we can keep them from freezing solid instantaneously 00:57:23 Hmm. . . One tricky way to keep the ice from melting is to make the ice from pure water, not saline. 00:57:51 Pure ice melts more slowly than saline ice? 00:57:54 Hmm... 00:58:00 Pure ice has a higher melting point. 00:58:09 pressure (as in compressed air) has been demonstrated as a highly feasible way of storing energy, at least. Take a look at Theo Jansen's work with wind-powered automata 00:58:48 The system could be in an ocean, and use the ocean water for the fluid in your ice machine. . . 00:58:55 And still have the whole thing below freezing. 00:59:12 I figured we could do a good job of protecting the machine from outside heat (and internal heat in some situations) by making use of something like picrete, which melts very slowly in comparison with ice 00:59:33 True. 01:00:31 But picrete contains sawdust, no? 01:00:41 Or at least some type of dust? 01:00:43 picrete tubing (slow melting, we can keep it "warmer") plus saline liquid running through the circuitry (low freezing point) could be a good way to keep things from fusing together or jamming 01:00:49 ihope: sawdust, yes 01:00:57 so it's a minor cheat 01:01:03 Could you make a picrete-like stuff from other materials? 01:01:08 dunno 01:01:21 You can't use sawdust in a replicator unless the replicator cuts down trees. 01:01:30 anything that can serve as an insulator and is attracted well to water, I suppose 01:01:32 hm 01:01:51 alright, so picrete is out of the question 01:02:14 is there any way we could generate a shield from solar radiation by trying to polarize ice? 01:02:47 And I don't believe putting water under pressure actually requires any energy. 01:02:58 Polarize ice? 01:03:22 manufacturing optical-quality ice would be immensely difficult, so I don't consider it viable for computation, but we might be able to use it for protection 01:03:32 Velocity, temperature, pressure, salinity, then density is a function of... some of those. 01:03:33 ihope: polarized. as in a polarizing filter. 01:03:43 Do you know that that's possible? 01:03:49 no 01:03:56 but I imagine it might be 01:05:01 it can be done to glass and plastic, primarily though heat-stressing 01:05:02 Anyway, I guess that makes our energy sources velocity differentials, temperature differentials, salinity differentials and density differentials. 01:05:13 however, a mechanical method of polarization might be possible 01:05:22 Velocity over position, temperature over position, salinity over position and density over height. 01:07:04 so, polarized ice is a purely theoretical idea, but I thought I'd throw it out there as something to consider 01:07:18 * ihope nods 01:08:25 Now, density-over-height differentials tend to turn themselves into velocity-over-position differentials, and I think temperature is proportional to density... 01:08:34 How do you utilize salinity differentials? 01:08:58 have we figured out how we'll represent signals in a fluidic system? pressure/no pressure, bubbles in liquid, possibly run the thing entirely on compressed air (thus completely avoiding the difficulty of making non-freezing circuits) 01:09:02 If you have a patch of extremely salty water next to a patch of freshwater... how do you get energy out of that? 01:09:16 osmotic pressure! 01:09:22 Oh, right! 01:09:38 ...wait, osmosis? Doesn't that require a membrane? 01:09:50 semipermiable membranes might be difficult to manufacture, true 01:10:09 but that's how you'd extract energy from a situation like that 01:10:56 is a salinity differential considered kinetic potential, chemical potential or.... entropic potential? 01:12:35 now, another thing to consider here- in addition to water and salt, the ocean offers some other potential materials to work with. Assuming we could host/control a suitable environment within or around the machine, could we use algae to do anything useful? 01:13:40 I'll bet algae + light control and pathways for the algae to propagate in could form some *really* slow logical circuitry 01:14:12 hehe 01:14:29 that's awesome 01:14:32 but after all, there's nothing that says this machine has to be fast, as long as it can reproduce before it wears out or breaks down 01:14:50 layers of algea, the top blocking light in places for the other layers 01:15:22 if you have a way to move algae between layers you have logic 01:15:27 and if the machine was interacting with it, it could strategically kill various algae colonies or patches via temperature control 01:16:07 a single microorganism is complex, but colonies of them act in extremely deterministic ways. :) 01:16:10 * pikhq contemplates doing computation via PVC and compressed air. . . 01:16:24 easy 01:16:28 pikhq: it'd actually be very feasible 01:16:34 True. 01:16:36 macro fluidic logic has been well studied 01:16:38 Just contemplating it. 01:16:41 zero moving parts would be harder, but still workable 01:17:04 I didn't figure it'd be impossible, I figured it'd just be interesting. 01:17:17 bsmntbombdood: given the difficulty of microfluidics fabrication with existing technology, we should think in terms of macro 01:17:29 RodgerTheGreat: definately 01:17:37 -!- ihope_ has joined. 01:17:38 pikhq: just commenting- I didn't think you were jumping to conclusions or anything 01:17:42 i can think of a compressed air NOR with moving parts 01:18:26 I can think of a AND/AND NOT/NOT AND gate, I think. 01:18:48 a fluidic analog transistor without moving parts: http://upload.wikimedia.org/wikipedia/en/2/2a/Fluidicamplifier.gif 01:19:03 I really should call that third not (NOT X) AND Y or something. 01:19:12 Digital? 01:19:16 X AND Y; X AND NOT Y; (NOT X) AND Y 01:19:23 hm... 01:20:16 analog logic is generally less reliable and more complex, but it *would* offer much more functionality from fewer parts than a digital equivalent 01:20:30 I think this suggests hybridization is a good idea 01:20:35 What about computing with ants? 01:20:44 analog would be terribly difficult with fluids, considering losses 01:21:08 ihope: doable, but much harder than with a simpler organism like fungus or algae 01:21:42 Computing with human interpreters of simple English instructions. :p 01:21:49 it'd be so hard to box the ants in enough to be computationally useful that I'd doubt it was worth it 01:21:57 heh 01:22:06 We could hand out "The Brainfuck Interpreter Book", and have each person in IRC be a single cell. 01:22:22 Maybe one that would hand out opcodes to the rest. 01:22:24 Compute with lichen: the combined power of fungus AND algae! 01:22:30 that's because you can layer linguistics and high-level logic on top of human instinct quite easily 01:22:42 True. 01:22:52 That'd just be remarkably amusing. . . 01:22:55 Kind of like IRP. ;) 01:23:08 -!- ihope_ has set topic: Esoteric programming language discussion | FORUM AND WIKI: esolangs.org | CHANNEL LOGS: http://ircbrowse.com/cdates.html?channel=esoteric | NO, IRP ALLOWED. 01:23:38 I guess you *could* think of the icemachine as incorporating a self-supporting ecosystem of some sort 01:23:54 but I'm not sure it's feasible 01:24:27 If we create this, we must make it open-source. 01:24:50 Now, I'm sure fungus/algae/lichen can be simulated somehow. 01:25:02 "Build an icemachine! All you need is a freezer, some ice-cube trays and an ocean!" 01:25:26 You might want to turn the freezer inside-out. 01:25:36 possibly 01:25:49 but I was considering it primarily a fabrication tool 01:26:37 I think I'm going to see if I can design an interlinking block that can function like a lego brick while being simple enough to build with tapwater in a normal refrigerator 01:26:52 the design would be for the molds, naturally 01:27:05 What happens if you put one refrigerator inside another? 01:27:30 Maybe you could do with something a bit more practical? 01:27:48 ? 01:27:49 * pikhq finds the RepRap idea both interesting and useful. . . 01:28:27 nah, an icemachine would be infinitely more interesting than a reprap even if it's orders of magnitude more difficult and inefficient 01:30:04 How easy is it to simulate one ant? 01:30:13 hard as fuck 01:30:13 Depends upon the ant. 01:30:17 Langton's is easy. :p 01:30:27 oh- haha- good call, pikhq 01:30:53 Of course, I doubt that has much to do with reality, so not all that helpful. :/ 01:31:29 SimAnt sort of simulates ants. 01:31:36 Probably not a very sophisticated system, though. 01:31:42 it occurs to me that living at MTU places me in a prime position (based on average snowfall and general temperature ranges) for basic Icemachine R&D experimentation 01:32:12 maximum transfer unit? 01:32:30 Michigan Technological University 01:32:35 but that other one, too 01:34:31 -!- ihope has quit (Connection timed out). 01:36:53 http://users.tkk.fi/~jblomqvi/langton/index.html 01:37:06 I think you may be able to build a Turing machine out of that! 01:41:21 Langton's ant *is* a Turing machine. 01:42:32 -!- ihope_ has quit ("http://tunes.org/~nef/logs/esoteric/06.08.09"). 01:42:56 I think ihope meant a UTM 01:43:03 Ah. 01:44:55 -!- ihope has joined. 01:57:43 -!- Sukoshi has joined. 02:00:37 -!- Sukoshi has left (?). 02:21:16 -!- ihope_ has joined. 02:38:12 -!- ihope has quit (Read error: 110 (Connection timed out)). 03:29:52 * pikhq randomly chants "Geocide!" 03:31:17 "NO, IRP ALLOWED" 03:33:37 :D 03:35:38 -!- ihope_ has set topic: Esoteric programming language discussion | FORUM AND WIKI: esolangs.org | CHANNEL LOGS: http://ircbrowse.com/cdates.html?channel=esoteric | GEOCIDE! | NO, IRP ALLOWED. 03:36:17 http://qntm.org/geocide You have to link to it. 03:37:42 -!- ihope_ has set topic: Esoteric programming language discussion | FORUM AND WIKI: esolangs.org | CHANNEL LOGS: http://ircbrowse.com/cdates.html?channel=esoteric | UNRELATED WEBSITE: http://qntm.org/geocide | NO, IRP ALLOWED. 03:38:31 -!- ihope_ has set topic: Esoteric programming language discussion - FORUM AND WIKI: esolangs.org - CHANNEL LOGS: http://ircbrowse.com/cdates.html?channel=esoteric - UNRELATED WEBSITE: http://qntm.org/geocide | NO, IRP ALLOWED. 03:38:57 -!- ihope_ has set topic: Esoteric programming language discussion | FORUM AND WIKI: esolangs.org | CHANNEL LOGS: http://ircbrowse.com/cdates.html?channel=esoteric | UNRELATED WEBSITE: http://qntm.org/geocide -- NO, IRP ALLOWED. 03:39:03 There! 03:42:28 Unrelated hell. It's exactly the wort of evil we discuss! :p 03:42:41 sort, even. 03:51:10 uh, you gotta love that page 03:56:12 >:D 04:09:27 i'm going to be banned from #scheme forever 04:14:30 -!- ihope_ has quit (Read error: 110 (Connection timed out)). 04:24:38 bsmntbombdood: that was fun :P 04:25:23 very 04:30:54 bot loops are the essence of irc 04:33:14 Condensed into annoying goodness. 04:33:37 everyone loves a good flood 04:33:37 a better challenge would be to do the busy beaver of bot looping 04:33:48 hehe 04:33:49 true 04:33:49 ie it has to halt, just spam a whole lot before doing so 04:34:05 too easy with scheme though 04:34:30 because a dead elephant could write one that floods for 8 billion years before stopping 04:36:32 'night, everyone 04:36:52 -!- RodgerTheGreat has quit. 05:25:37 -!- Sukoshi has joined. 05:26:11 What's the typical idiom used to read lines from unknown-length streams? 05:26:17 In Java, I mean. 05:28:47 good question 05:29:08 ... :P. 05:29:37 My Java book doesen't go through an idiom. 05:31:50 hmm 05:31:52 .read()? 05:32:01 idi om 05:32:34 -!- Sukoshi has left (?). 05:54:50 fuck, i gotta go soon 05:54:59 Is "fuck" the reason? 05:55:23 hmm... i doubt that :\ 05:55:54 but you never know 05:56:07 well, i guess i'd have to know now for it to be a reaosn 05:56:09 *reason 06:01:57 to the camping 06:03:45 yar 06:05:41 ...and there's the ban 06:07:27 haha 06:07:42 people are so sensitive about banning 06:07:45 *flooding 06:07:46 lol 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 08:16:14 -!- Sukoshi has joined. 08:17:41 So I'm reading about the factory pattern. 08:18:24 If the factory can create different classes and return them ... do you have to use runtime class checking to check what you get, or do you rely on Polymorphism all the way? 08:18:36 Because if the latter is true, the Factory method is not for me. 08:19:08 -!- sebbu has joined. 08:19:44 Because this annoying casting is becoming ... Sphagetti-like in places ... I don't know how to clean it. 08:20:06 Without doing a major refactor, which I'll probably end up doing... 08:20:18 And ... my hand hurts like the seven suns, so I'll stop now. 10:59:24 -!- clog has joined. 10:59:24 -!- clog has joined. 11:36:28 -!- sebbu2 has joined. 11:50:01 -!- sebbu3 has joined. 11:55:03 -!- sebbu has quit (Read error: 110 (Connection timed out)). 12:09:33 -!- sebbu2 has quit (Read error: 110 (Connection timed out)). 12:27:03 -!- sebbu3 has changed nick to sebbu. 12:34:47 -!- ehird` has joined. 14:03:04 -!- puzzlet has joined. 14:30:26 -!- RedDak has joined. 15:16:54 -!- jix has quit (Nick collision from services.). 15:17:08 -!- jix has joined. 15:28:53 -!- RedDak has quit (Read error: 104 (Connection reset by peer)). 16:58:53 -!- ihope_ has joined. 16:58:58 -!- ihope_ has changed nick to ihope. 17:02:18 -!- Mahjong_on has joined. 17:02:37 -!- Mahjong_on has changed nick to Mahjong. 17:04:21 -!- blahbot` has joined. 17:04:29 someone should really write a wapr program 17:38:38 Someone should really write a "Get pikhq off his lazy ass" program. 17:51:57 Someone should really write a "make ndiswrapper work" program. 17:53:33 That's called "slavery". 17:54:18 It is? 17:54:30 Oh, it is. 17:55:09 Yes, somebody should do that. 18:18:14 somebody should really write a "somebody should really write a "som 18:20:15 What's a "somebody should really write a "som? 18:21:00 a recursive request 18:21:04 is this better 18:21:05 somebody should really write a "somebody should really write a "som... 18:21:46 x where x = somebody should really write an "x" 18:22:21 How do you write one of those, exactly? 18:22:41 you'll have to see what comes after the infinite recursion to know. 18:22:48 -!- RodgerTheGreat has joined. 18:23:02 hello everyone 18:23:10 Ah. 18:23:22 hey, ihope 18:23:26 There's an after. 18:23:28 RodgerTheGreat: wllo. 18:23:32 And ello, to. 18:23:37 And too, too. 18:24:24 Hmm. This ISO download is going very slowly compared to how fast it was going with those other mirrors. 18:25:12 ...hey! No fair! 18:25:15 Oh, never mind. 20:46:56 -!- calamari has joined. 20:47:07 Calamari again! 20:47:25 hi pikhq 21:28:31 -!- RedDak has joined. 21:40:48 INTERESTING BRAINFUCK PROGRAM IDEA: A program, in a certain shape (Say a christmas tree) that, when ran, produces a program of the same shape (Only smaller or bigger - but the same shape) which does the same thing. So, you could have a theoretically endless chain of different trees. 21:41:00 Hmm. 21:41:05 so it's like a recursive ascii-art-program generator or something 21:46:15 :P 21:48:06 difficult 21:48:17 but possible, no? 21:48:36 the christmas trees will just have to range in size from very very large to larger-than-universe large 21:51:54 possible, just difficult 21:52:26 for starters, try simply writing a "quine" that produces a longer version of itself each time 21:53:23 why a longer version? the program has no restrictions on which direction the size takes 21:53:52 as long the output of x is not x, and the output of x AND x are in the shape of a christmas tree, and the output of x obeys the same rules, then it's valid 21:54:09 not sure what that has to do with what i said 21:54:11 harder to get smaller than bigger 21:54:41 bsmntbombdood, true, but a christmas-tree generator that just grew a constant amount every time wouldn't be quite as good 21:54:44 but, yes, good starting point 21:54:55 bsmntbombdood: actually smaller is much easier 21:55:04 in fact trivial 21:55:08 how? 21:55:19 lament, well you'll get it down to the minimum christmas-tree-shape size possible while still working at some point 21:55:27 so you need it to grow at least some times 21:55:33 bsmntbombdood: start with a smallest program, then simply generate a program that prints that one 21:55:40 lament, pah =p 21:55:42 continue like that for any number of steps you wish 21:55:44 oh, yes 21:55:54 lament, that doesn't work 21:55:59 because the sequence stops eventually 21:56:05 instead of continually producing trees 21:56:15 ehird`: er, well it can't get smaller forever, can it? 21:56:27 lament, exactly - so on some occasions, the tree must instead grow 21:56:42 so it sometimes shrinks, sometimes grows????? 21:56:46 then just have two trees 21:56:51 one big, one small, each one prints the other. 21:57:02 no, that produces the same tree more than once 21:57:07 i think you're on crack 21:57:33 you want a non-monotonous ininite sequence 21:57:44 it is possible - if you produce, e.g. a 5x bigger tree every 3 steps, which then decreases 0.5x 3 times, then repeats 21:58:19 perhaps it should employ a random number generator. infinite possible non-monotonous infinite sequences from one program? yes, i am insane 21:58:22 then just make one that always grows, because that's easier. 21:58:39 actually a random number generator would work well 21:58:52 the grow/shrink problem would be solved, and each iteration could produce many different paths 22:00:17 non deterministic brainfuck? 22:00:36 there are quite a few prngs in brainfuck... 22:00:41 just use one of them. 22:01:23 they're all deterministic... 22:01:45 sure, but it's good enough 22:02:03 Actually, any PRNG is deterministic. . . 22:02:12 exactly 22:02:15 good enough for what? 22:02:17 easy to add nondetermism to bf 22:02:22 lament, the purpose of the program 22:02:28 look 22:02:37 if a program can grow or shrink 22:02:43 then start with the smallest program, that can't shrink 22:03:04 add a new instruction, C, that puts a 1 or a 0 in the current cell 22:03:08 that's not the point 22:03:35 the point is to create a program X (where the output produced when running x is Y): 22:03:35 bsmntbombdood: That's still deterministic, since it's relying upon a different (higher-quality) PRNG. 22:03:41 - X is in the shape of a christmas tree 22:03:55 pikhq: no 22:04:07 - X randomly either grows or shrinks into Y, according to the output of a PRNG 22:04:12 - Y obeys all of these rules 22:04:22 the interpreter doesn't have to be deterministic 22:04:26 ehird`: sounds too baroque 22:04:38 lament, why? it would work perfectly 22:05:08 don't forget "and at each iteration, the tree can randomly change into a pink elephant" 22:05:19 heh 22:05:32 X is perfectly possible to create 22:05:37 just very difficult 22:05:44 bsmntbombdood: The issue is that your interpreter will be relying on a PRNG, which is, *by definition*, deterministic. . . 22:05:57 pikhq: who said the interpreter will be relying on a PRNG? 22:06:12 lament: One assumes that it runs on a standard computer. 22:06:14 pikhq: we can actually specify that the interpreter MUST be fully random. 22:06:28 it's up to the implementor to figure out how to achieve that. 22:06:29 pikhq: standard computers can be nondeterministic 22:06:30 If it's got a hardware RNG, then it won't actually be deterministic. 22:06:33 (it's actually very easy) 22:07:03 Otherwise, at best, you're dealing with a really hard-to-reproduce seed for your PRNG. 22:07:27 ... anyway 22:07:31 a PRNG will be good enough methinks =p 22:07:44 It's good enough for cryptography. ;) 22:08:08 pikhq: do you think truly random numbers don't exist, or do you think computers can't get access to them? 22:08:19 if anyone actually writes X, they're probably the best BF programmer in the world 22:09:01 lament: I think that computers are, without hardware that most computers don't have, fairly deterministic. 22:09:23 pikhq: int f(){ int i = 0; int tick = clock(); while(tick == clock()) i++; return i; } 22:09:27 (although they can act almost like they're not, just due to the sheer amount of input and output they have) 22:09:34 f is nondeterministic on most computers 22:09:51 of course this requires a BF ext 22:09:53 pikhq: that's why there's this thing called "internet" which allows computers without special hardware to connect to those with special hardware 22:09:56 whereas "BF" was specified in the spec =) 22:10:06 lament: . . . Granted. XD 22:10:18 pikhq: and several servers providing truly random numbers. 22:10:40 . . . Yes. . . XD 22:11:11 no such thing 22:11:15 nothing is random =) 22:11:34 quantum mechanics disagrees! 22:11:47 ehird`: I beg to differ; the universe itself seems to be nondeterministic and provides many entropy sources. 22:11:58 (roughly one per subatomic particle, in fact) 22:12:36 show me a subatomic random number entropy-source generator 22:12:38 pikhq: it just seems that way because we aren't smart enough to see that it is deterministic 22:12:51 * pikhq pulls out a geiger counter 22:12:54 ehird`: geiger counter 22:13:10 ... on the internet. 22:13:23 * pikhq hooks a geiger counter to his computer 22:13:29 okay, you win 22:13:41 but i highly doubt a geiger counter is feasable for a BF interpreter. Mm? 22:13:49 ehird`: http://www.hotbits.com/ 22:13:54 errrr 22:14:12 is that a porn site? :) 22:14:19 ehird`: You can probably have sufficient entropy just from watching fluctuations in the clock. 22:14:29 http://www.fourmilab.ch/hotbits/ 22:14:38 that's the link i was going for 22:14:43 thats an unfortunate name 22:14:45 Or by using /dev/urandom. . . Not truly random, but PRNG are 'good enough'. 22:14:53 pikhq: that's what that code does 22:15:24 * ehird` listens to the sound of radioactive decay 22:15:55 the difference between /dev/urandom and a PRNG in pure brainfuck is that the latter will produce the exact same sequence every time, which is just dumb. 22:15:59 i like this 22:16:13 lament: Not quite. 22:16:22 lament, Well sure, but the program generated will produce a different sequence than its generator which is what matters 22:16:22 You could have it pull a fairly large seed from stdin. 22:16:49 well, in that case, for ehird`''s problem, you don't even need a rng 22:16:59 it could just ask the user whether he wants to grow or shrink the tree. 22:17:06 no 22:17:08 the program must take no input 22:17:17 ah, well, there you go 22:17:23 you should for example, be able to run it in a shell script loop 22:26:35 .. it is possible, right? 22:35:09 =/ 22:52:27 -!- RedDak has quit (Read error: 104 (Connection reset by peer)). 23:04:05 -!- ehird` has quit (Read error: 104 (Connection reset by peer)). 23:04:20 -!- blahbot` has quit (Remote closed the connection). 23:18:46 Use the stock market as a random number generator! 23:19:36 easy to manipulate 23:19:36 Up a cent, 1. Down a cent, 0. Then... do something. 23:19:48 Skew transform? 23:20:26 what's a skew transform? 23:20:48 Turn 01 into 1 and 10 into 0. Discard 00 and 11. 23:21:02 Do you know what that's called? 23:21:39