Mercurial > repo
changeset 900:e1c037345e52
<Phantom_Hoover> pastelog rapido
author | HackBot |
---|---|
date | Thu, 29 Nov 2012 21:22:45 +0000 |
parents | ee12065796be |
children | 866fbae1dffd |
files | paste/paste.20529 |
diffstat | 1 files changed, 301 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/paste/paste.20529 Thu Nov 29 21:22:45 2012 +0000 @@ -0,0 +1,301 @@ +2008-08-07.txt:15:14:55: <tusho> Introductions are a lot of fun, some crap, crapidoodle... mmm, crapidoodle. Introductions are a lot of fun, some crap, crapidoodle... mmm, crapidoodle. Introductions are a lot of fun, some crap, crapidoodle... mmm, crapidoodle. Introductions are a lot of fun, some crap, crapidoodle... mmm, crapidoodle. Introductions are a lot of fun, some crap, crapidoodle... mmm, crapidoodle. +2008-08-07.txt:15:15:36: -!- Deewiant changed the topic of #esoteric to: http://tunes.org/~nef/logs/esoteric | <bsmntbombdood> lol tornado brb | ☃ | mmm, crapidoodle. +2008-08-07.txt:15:32:26: -!- tusho changed the topic of #esoteric to: http://tunes.org/~nef/logs/esoteric | mmm, crapidoodle. | ☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☠+2008-08-08.txt:15:34:05: <tusho> "mmm...crapidoodle" +2009-04-17.txt:03:06:57: <GregorR> Can somebody translate this from psuedoSpanish to English? "ooooooooooooo que bacano lo boy aitalar para que mi pc me corra mas rapido jajaja no pero enserio esta bacano" +2010-03-27.txt:22:22:58: -!- rapido has joined #esoteric. +2010-03-27.txt:22:24:14: <rapido> is my language is esoteric?: http://www.enchiladacode.nl ... you decide +2010-03-27.txt:22:25:18: <oerjan> rapido: looks far too well-developed to be esoteric :D +2010-03-27.txt:22:26:14: <rapido> i think to most interesting esoteric languages are extremely well-developed to be different +2010-03-27.txt:22:26:49: <rapido> pikhq: you insult me! - usable? - nah +2010-03-27.txt:22:27:06: <fax> rapido -- it doesn't look esoteric but I just glanced +2010-03-27.txt:22:28:27: <rapido> the esoteric bit is that it would be very difficult to compile enchilada to efficient machine code +2010-03-27.txt:22:28:48: <rapido> but i guess most esoteric languages have that property +2010-03-27.txt:22:29:12: <rapido> may be not +2010-03-27.txt:22:29:31: <pikhq> rapido: Many languages are difficult to compile efficiently. +2010-03-27.txt:22:29:58: <oerjan> rapido: befunge has that as a design feature +2010-03-27.txt:22:30:45: <rapido> pikhq: enchilada's eval is always there - always +2010-03-27.txt:22:31:18: <alise> rapido: you're the enchilada creator? +2010-03-27.txt:22:31:26: <pikhq> rapido: BTW, what makes it difficult to compile efficiently? +2010-03-27.txt:22:31:31: <alise> great to meet you rapido +2010-03-27.txt:22:31:46: <rapido> alise: thanks! +2010-03-27.txt:22:32:10: <rapido> pikhq: every unwritten term carries a hash +2010-03-27.txt:22:32:25: <rapido> code = data = hashed +2010-03-27.txt:22:32:30: <alise> rapido: May I comment? Making the correctness of your language depend on the infallibility of SHA-1 is unwise. +2010-03-27.txt:22:32:55: <rapido> alise: SHA-1 is just one choice of hash +2010-03-27.txt:22:33:05: <alise> rapido: But it is true of every hash. +2010-03-27.txt:22:33:15: <rapido> alise: is it? +2010-03-27.txt:22:33:20: <pikhq> rapido: Hashes, by definition, cannot satisfy what you ask of it. +2010-03-27.txt:22:33:36: <rapido> what is the chance of your memory to fail or have a hash collision? +2010-03-27.txt:22:33:46: <rapido> not your memory of course ;) +2010-03-27.txt:22:34:28: <pikhq> rapido: Hashes are not unique. +2010-03-27.txt:22:34:50: <alise> rapido: Well there's all sorts of "chance"; many hash functions have been broken. +2010-03-27.txt:22:35:10: <alise> rapido: Correctness doesn't care about the practical reality, though, because it is about mathematical properties. +2010-03-27.txt:22:36:46: <alise> rapido: I think Enchilada is certainly one of the most unique extant languages. +2010-03-27.txt:22:36:49: <rapido> alise: i believe the reality is not correct - at least my computer fails me many more times than hash collisions which have probability 10 ^ -30 - depending on the hash function +2010-03-27.txt:22:37:04: <alise> rapido: Me and cpressey discussed one aspect of it recently, actually. +2010-03-27.txt:22:37:15: <alise> rapido: Go and look up how many hash functions have been broken. +2010-03-27.txt:22:37:46: <rapido> alise: forget about SHA1 - think about hashes +2010-03-27.txt:22:37:58: <alise> rapido: If we're being abstract we have to be formal too. +2010-03-27.txt:22:38:04: <pikhq> rapido: This is a problem with all hashes. +2010-03-27.txt:22:38:27: <alise> rapido: forall f:A->B, (card B < card A) -> exists x:A,y:A. f x = f y +2010-03-27.txt:22:38:30: <rapido> pikhq: i don't see it as a problem - i see it as a opportunity +2010-03-27.txt:22:38:44: <pikhq> rapido: An opportunity... For security flaws. +2010-03-27.txt:22:38:48: <rapido> if you give a little you gain a lot +2010-03-27.txt:22:39:07: <rapido> pikhq: memory failure is also a possibility +2010-03-27.txt:22:39:15: <alise> rapido: pikhq is actually right about security: consider an Enchilada program comparing for equality to some secret value. +2010-03-27.txt:22:39:25: <rapido> you need a physical platform - which is faulty +2010-03-27.txt:22:40:00: <alise> rapido: IMO that is an error similar to the one that claims that Turing-completeness of a language is impossible because no universal Turing machine can be constructed. +2010-03-27.txt:22:41:00: <alise> rapido: Actually if we are considering physical things, why do you use hashes? Comparison is not slow. +2010-03-27.txt:22:41:30: <rapido> alise: try comparing two sets which are different in only one element +2010-03-27.txt:22:41:42: <alise> rapido: How big are these sets? +2010-03-27.txt:22:41:46: <rapido> big +2010-03-27.txt:22:42:00: <rapido> let's do some O complexity +2010-03-27.txt:22:42:14: <rapido> two sets with size n and m +2010-03-27.txt:22:42:18: <pikhq> rapido: Depends heavily on the representation of the set, the location of the difference, and the comparison algorithm in use. +2010-03-27.txt:22:42:34: <alise> rapido: you are appealing to practical reasons +2010-03-27.txt:22:42:58: <rapido> sure it does - but what's the most efficient algorithm? +2010-03-27.txt:22:43:53: <rapido> alise: hey, i'm just being esoteric ;) +2010-03-27.txt:22:45:19: <rapido> fax: Heresy! +2010-03-27.txt:22:45:20: <alise> rapido: Anyway, add dependent types and termination checking and I'll love it. +2010-03-27.txt:22:46:45: <rapido> alise: no exceptions, yes baby! +2010-03-27.txt:22:46:56: <alise> rapido: But it has _|_, I presume? +2010-03-27.txt:22:47:44: <rapido> no, it doesn't have bottom - everything terminates eventually +2010-03-27.txt:22:47:50: <fax> poor rapido having to listen to this :P +2010-03-27.txt:22:48:15: <alise> rapido: Well, that is good. I do hope you realise that this means it cannot be turing-complete. +2010-03-27.txt:22:49:42: <AnMaster> try to be somewhat nicer to rapido +2010-03-27.txt:22:49:43: <rapido> alise: i have thought of this. what about doing something 10^100000 times? +2010-03-27.txt:22:50:18: <alise> rapido: So, you are an ultrafinitist, then? +2010-03-27.txt:22:50:34: <alise> rapido: If something could never be computed it is not computable. +2010-03-27.txt:22:51:19: <rapido> alise: i like brouwer - the dutch mathematician +2010-03-27.txt:22:51:53: <alise> rapido: You are at least a constructivist then. +2010-03-27.txt:22:53:38: <rapido> let me try to explain my case +2010-03-27.txt:22:53:48: <rapido> let's say you have a long winding proof +2010-03-27.txt:22:54:00: <rapido> the proof will hold references to other proofs +2010-03-27.txt:22:54:27: <rapido> and those proofs will hold references to yet other proofs +2010-03-27.txt:22:54:49: <rapido> what is the chance of any reference to be faulty? +2010-03-27.txt:22:55:06: <rapido> what can we do to lower that chance? +2010-03-27.txt:22:55:30: <rapido> can we make a reference absolutely non-faulty - always? +2010-03-27.txt:22:55:34: <rapido> i don't believe so +2010-03-27.txt:22:55:41: <rapido> we can lower it +2010-03-27.txt:22:55:44: <alise> rapido: Eh? +2010-03-27.txt:22:56:04: <Sgeo_> rapido, that's a problem of mathematicians being wrong, not a property of mathematics itself +2010-03-27.txt:22:56:15: <rapido> alise: think of the reference itself +2010-03-27.txt:22:56:27: <alise> rapido: Define what a reference to a proof IS, as an actual object. +2010-03-27.txt:22:57:10: <rapido> alise: i'm saying that you need pointers +2010-03-27.txt:22:57:20: <alise> rapido: This is false. +2010-03-27.txt:22:57:25: <rapido> alise: to scala +2010-03-27.txt:22:57:29: <rapido> scala <- scale +2010-03-27.txt:22:58:10: <rapido> doesn't abstract mathematics need pointers? +2010-03-27.txt:22:58:27: <rapido> to refer to something? a word is a pointer +2010-03-27.txt:22:59:07: <Sgeo_> rapido, a reference to a proof is just um.. kind of included, I guess? More like a #define than an import? +2010-03-27.txt:22:59:17: <alise> rapido: No, a name is just a placeholder. +2010-03-27.txt:23:00:02: <rapido> alise: but the name must be unique, not? +2010-03-27.txt:23:00:21: <rapido> otherwise the statement will be ambigious +2010-03-27.txt:23:00:31: <rapido> ambiguous +2010-03-27.txt:23:01:13: <rapido> come on - names refer to bigger things +2010-03-27.txt:23:01:23: <rapido> they compress the bigger things +2010-03-27.txt:23:01:40: <rapido> they are a poor-mans hash of the things they refer to +2010-03-27.txt:23:02:11: <rapido> the bigger things have names in them +2010-03-27.txt:23:02:21: <rapido> they refer to other objects +2010-03-27.txt:23:02:32: <alise> rapido: I think that's rubbish. +2010-03-27.txt:23:02:37: <rapido> alise: ok +2010-03-27.txt:23:02:55: <rapido> i think it's exactly that +2010-03-27.txt:23:03:03: <rapido> that's abstraction +2010-03-27.txt:23:03:07: <rapido> to compress +2010-03-27.txt:23:03:10: <oerjan> rapido: a name would only be a hash if it was derived entirely from the thing it named +2010-03-27.txt:23:03:34: <rapido> oerjan: yes, that's why i like hashes better than names +2010-03-27.txt:23:04:02: <oerjan> rapido: and it is also why hashes must have the possibility of collisions, but names need not +2010-03-27.txt:23:05:22: <rapido> oerjan: names may not - but who will make sure the names don't clash? +2010-03-27.txt:23:05:35: <oerjan> rapido: the compiler/verifier +2010-03-27.txt:23:06:11: <rapido> oerjan: don't you agree that names compress the complex objects hat they refer to? +2010-03-27.txt:23:06:21: <rapido> hat <- that +2010-03-27.txt:23:06:54: <oerjan> rapido: now you are just shifting the meaning of a term, it won't help your actual argument any +2010-03-27.txt:23:06:59: <rapido> otherwise you would end up with pure value passing semantics - which is very inefficient +2010-03-27.txt:23:07:24: <rapido> oerjan: and what's my actual argument? +2010-03-27.txt:23:08:39: <rapido> fax: 'heh you could hard code in something that ensures that every variable name you use, names some term which is larger' +2010-03-27.txt:23:09:03: <rapido> fax: this would end up with names as big as the objects themselves +2010-03-27.txt:23:09:34: <rapido> fax: just would rather have the objects - thank you very much +2010-03-27.txt:23:10:06: <oerjan> rapido: i think you are reading fax backwards +2010-03-27.txt:23:11:03: <rapido> oerjan: that's right +2010-03-27.txt:23:11:16: <rapido> fax: it is an interesting thought - thanks! +2010-03-27.txt:23:12:28: <rapido> but i do still think names/pointers/links are meant to compress information - think of exact repetitions +2010-03-27.txt:23:13:11: <rapido> you just say: hey i've got this object and a name it x +2010-03-27.txt:23:13:29: <rapido> now i have this other object y, and it holds 4 x's +2010-03-27.txt:23:13:50: <rapido> and so forth +2010-03-27.txt:23:14:27: <rapido> but how are you going to name the 10^10000 object that holds other object names? +2010-03-27.txt:23:15:09: <rapido> names are important especially in a distributed setup where you can't have a central naming service +2010-03-27.txt:23:15:24: <rapido> who is giving out the names? +2010-03-27.txt:23:19:37: <rapido> i will give myself a name, and a won't be a hash +2010-03-27.txt:23:20:31: <Sgeo_> rapido, to be clear, you're talking about computers, and not math, right? +2010-03-27.txt:23:21:30: <rapido> Sgeo_: math is riddled with references and names that refer to complex abstractions +2010-03-27.txt:23:22:26: <rapido> Sgeo_: of course, you can always create the full proof down the axioms, without references +2010-03-27.txt:23:23:40: <rapido> Sgeo_: 'math' doesn't difference from 'computers' - whatever that means +2010-03-27.txt:23:24:55: <rapido> you can never be certain +2010-03-27.txt:23:25:03: <rapido> even mathematical proofs aren't certain +2010-03-27.txt:23:25:06: <alise> rapido: sigh +2010-03-27.txt:23:25:15: <rapido> you need faulty humans to falsify mathematical proofs +2010-03-27.txt:23:25:56: * Sgeo_ wonders if rapido might be pulling a fax. +2010-03-27.txt:23:25:59: <alise> rapido, saying that proofs aren't certain because you need humans to falsify them or something +2010-03-27.txt:23:26:09: <rapido> alise: but computers are faulty - the change of computers to faulty is much higher than hash collisions +2010-03-27.txt:23:26:31: <rapido> change <-chance +2010-03-27.txt:23:26:35: <alise> rapido: except when computers go wrong - they don't say "Yes this is valid omg!" +2010-03-27.txt:23:26:54: <rapido> fax: thanks for correcting me - thank you very much +2010-03-27.txt:23:27:03: <alise> he pinged Oranjer, rapido +2010-03-27.txt:23:27:16: <fax> rapido, what? +2010-03-27.txt:23:28:02: <rapido> heisenbug! now you are talking my way! +2010-03-27.txt:23:28:22: <rapido> i like heisenbugs! +2010-03-27.txt:23:28:25: <rapido> they are great! +2010-03-27.txt:23:28:57: <rapido> we should create a esoteric language called heisenbug! +2010-03-27.txt:23:29:40: <rapido> the default would be an heisenbug statement - with the remote exception of a correct statement +2010-03-27.txt:23:30:55: <rapido> if the heisenbug language proves to be turing complete - i'm done! +2010-03-27.txt:23:33:00: <rapido> pikhq: just to make you shiver: 'corporate' storage depends on hashes (that may have collisions) +2010-03-27.txt:23:33:55: <pikhq> rapido: Yes, hash tables are common. +2010-03-27.txt:23:33:56: <alise> rapido: You are mixing the practical and the theoretical, seemingly repeatedly. +2010-03-27.txt:23:34:59: <rapido> alise: i think theoretical abstractions need reality to be expressed. +2010-03-27.txt:23:35:08: <rapido> i do see the difference +2010-03-27.txt:23:35:48: <alise> rapido: Then it is a philosophical disagreement we have, and having reached the bottom layer of where rationality works, we should abandon the discussion immediately. :) +2010-03-27.txt:23:36:25: <rapido> alise: i see that - no prob :) +2010-03-27.txt:23:36:53: <alise> fax: rapido :P +2010-03-27.txt:23:37:07: <alise> rapido: Well, I applaud your work on Enchilada and hope you'll visit here often. +2010-03-27.txt:23:37:28: <rapido> fax: lol! +2010-03-27.txt:23:37:48: <rapido> fax: hey - at least i've made something runnable! +2010-03-27.txt:23:40:00: <rapido> sound like the scientific approach - repeat and measure +2010-03-27.txt:23:40:18: <rapido> alise: again we disagree +2010-03-27.txt:23:41:15: <alise> rapido: Well, I think I have the evidence on my side. There are many mechanical proof checkers upon which a large part of mathematics has been formulated. +2010-03-27.txt:23:42:21: <rapido> alise: your romance with math is before 1935 +2010-03-27.txt:23:43:13: <rapido> alise: that math is much to great and complex and interesting to be certain +2010-03-27.txt:23:43:56: <alise> rapido: I really do invite you to go up to any of the many people who have worked on proof checkers, proof assistants, and laboriously defined and proved things in these systems - and say that to them. +2010-03-27.txt:23:44:01: <rapido> alise: and that axioms are not enough - godel has proved that +2010-03-27.txt:23:44:34: <fax> rapido: btw I think most people here are post-godel +2010-03-27.txt:23:45:03: <fax> rapido: of course it is a big factor +2010-03-27.txt:23:45:03: <rapido> sure - i'm more into popper <- an oldie also +2010-03-27.txt:23:45:38: <rapido> alise: that's one way of putting it +2010-03-27.txt:23:46:32: <rapido> alise: what i don't understand is that you allow proof checkers +2010-03-27.txt:23:46:47: <pikhq> rapido: What's to not understand? +2010-03-27.txt:23:46:49: <alise> rapido: Perhaps you do not understand what a proof checker is. +2010-03-27.txt:23:46:54: <rapido> why do you rely on faulty memory +2010-03-27.txt:23:47:05: <rapido> alise: i perfectly understand. +2010-03-27.txt:23:47:11: <alise> rapido: Your appeal to errors in memory to demonstrate that mathematics is uncertain is really poor. +2010-03-27.txt:23:47:15: <rapido> do you trust the compiler +2010-03-27.txt:23:47:27: <rapido> has the compiler been proved correctly? +2010-03-27.txt:23:47:32: <rapido> what about the processor? +2010-03-27.txt:23:47:34: <rapido> etc, etc +2010-03-27.txt:23:47:47: <alise> rapido: There is an article about this. +2010-03-27.txt:23:48:38: <fax> rapido - of course the main thing people are forgetting is there's so much more to mathematics than formal proof +2010-03-27.txt:23:48:51: <rapido> fax: very true +2010-03-27.txt:23:49:18: <rapido> alise: http://r6.ca/homework.html <- this i don't like +2010-03-27.txt:23:54:43: <rapido> alise: 'For one, you can have RAM with so much error checking that it is physically impossible for it not to detect an error for the computation you are doing...' +2010-03-27.txt:23:55:27: <rapido> alise: for one, you can have hashes with so many bits that it is physically impossible not to detect an error for the computation you are doing... +2010-03-27.txt:23:55:55: <rapido> now i will stop moaning about hashes +2010-03-27.txt:23:56:04: <alise> rapido: no that's false +2010-03-27.txt:23:56:29: <Sgeo_> alise, I think rapido is trying to make an analogy? +2010-03-27.txt:23:56:40: <rapido> the checking bits of faulty ram is smaller than the ram +2010-03-27.txt:23:57:28: <rapido> you can't have absolutely perfect ram +2010-03-27.txt:23:58:20: <rapido> fax: no, the most kind of impossible there is - is god +2010-03-27.txt:23:59:11: <fax> rapido oh you're another of the atheist people I guess -_- +2010-03-27.txt:23:59:12: <rapido> dixon: a sponge bob - another hero if mine! +2010-03-27.txt:23:59:24: <rapido> if <- of +2010-03-28.txt:00:01:06: <rapido> dixon: uuuh - i need to study your reference to sponge constructions +2010-03-28.txt:00:01:41: <dixon> rapido: http://sponge.noekeon.org/ +2010-03-28.txt:00:01:50: <rapido> i could believe in god and still find the concept of god to be impossible +2010-03-28.txt:00:01:54: <rapido> such is believe +2010-03-28.txt:00:02:29: <rapido> dixan: ah, thanks! +2010-03-28.txt:00:02:41: <dixon> rapido: They're cryptographic hashes, however. +2010-03-28.txt:00:03:03: <rapido> dixon: cryptographic hashes are the only ones i'm considering +2010-03-28.txt:00:04:04: <dixon> rapido: But yes, by definition they're surjective when useful and thus have collisions. +2010-03-28.txt:00:04:26: <rapido> lament: then you would be a flying lunatic with wings +2010-03-28.txt:00:06:13: <rapido> dixon: all that i want is a naming service that is scalable +2010-03-28.txt:00:06:28: <Sgeo_> rapido, let the name of the proof be the content of the proof. +2010-03-28.txt:00:07:00: <rapido> Sgeo_: but proofs can be huge - think of computer generated proofs +2010-03-28.txt:00:10:20: <rapido> look.... the coq has giving me sign - it's hanging low - it's time to go to bed.... later ... +2010-03-28.txt:00:10:40: -!- rapido has quit (Quit: rapido). +2010-03-31.txt:20:29:19: -!- rapido has joined #esoteric. +2010-03-31.txt:21:56:37: -!- rapido has quit (Quit: rapido). +2010-04-01.txt:07:06:04: -!- rapido has joined #esoteric. +2010-04-01.txt:07:07:26: -!- rapido has parted #esoteric (?). +2010-04-07.txt:21:22:45: -!- rapido has joined #esoteric. +2010-04-07.txt:21:27:31: -!- rapido has parted #esoteric (?). +2010-04-08.txt:19:45:27: -!- rapido has joined #esoteric. +2010-04-08.txt:20:15:36: -!- rapido has quit (Quit: rapido). +2010-05-28.txt:03:58:39: <oerjan> la grande rapido universidad estatal +2011-03-21.txt:20:22:13: -!- rapido has joined #esoteric. +2011-03-21.txt:20:27:38: <rapido> are there an interesting 'collection oriented' language that is not apl/j/k? +2011-03-21.txt:20:27:46: <rapido> are <- is +2011-03-21.txt:20:29:48: <rapido> is there something like 'map theory'? I know there is something like 'array theory' +2011-03-21.txt:20:32:37: <rapido> array theory: http://www.nial.com/ArrayTheory.html +2011-03-21.txt:20:33:20: <rapido> ah found something: http://www.mangust.dk/skalberg/papers/gkli-slides1.pdf +2011-03-21.txt:20:33:25: <rapido> map theorie: v +2011-03-21.txt:20:33:30: <rapido> map theory: http://www.mangust.dk/skalberg/papers/gkli-slides1.pdf +2011-03-21.txt:20:35:14: <rapido> wouldn't it be nice to have a map oriented language? +2011-03-21.txt:20:35:32: <rapido> everything is a map - data and code +2011-03-21.txt:20:36:02: <Phantom_Hoover> rapido, map? +2011-03-21.txt:20:37:18: <rapido> concrete map: [0=0;1=1;2=4;3=9] +2011-03-21.txt:20:37:33: <Phantom_Hoover> rapido, so everything is an associative array? +2011-03-21.txt:20:38:03: <rapido> Phantom_Hoover: yes, that's one way of phrasing it +2011-03-21.txt:20:38:12: <Phantom_Hoover> rapido, finite or infinite? +2011-03-21.txt:20:38:17: <rapido> finite! +2011-03-21.txt:20:38:28: <rapido> total functions would be nice +2011-03-21.txt:20:39:46: <rapido> this would be a lazy map: [x<-[0..10000000];x*x] +2011-03-21.txt:20:40:41: <rapido> still finite because the domain is finite +2011-03-21.txt:20:42:00: <rapido> Gregor: ok, i haven't really settled for a notation +2011-03-21.txt:20:42:08: <rapido> notation <- syntax +2011-03-21.txt:20:43:39: <rapido> domain: 0..10000000 : range: x*x +2011-03-21.txt:20:44:09: <rapido> Phantom_Hoover: yes - thanks +2011-03-21.txt:20:47:09: <rapido> the domain (keys) and range (values) can be maps too. +2011-03-21.txt:20:47:48: <rapido> In fact, literals are maps in disguise +2011-03-21.txt:20:48:02: <rapido> there should be only maps! +2011-03-21.txt:20:51:23: <rapido> I've done something similar with enchilada- but i like to be more restrictive than enchilada (i.e. finitie maps only) +2011-03-21.txt:20:51:49: <Phantom_Hoover> rapido, so basically everything is a function from a finite sense? +2011-03-21.txt:20:52:43: <rapido> Phantom_Hoover: yes +2011-03-21.txt:20:56:39: <rapido> Phantom_Hoover: say that you have an recursive function that doesn't terminate +2011-03-21.txt:20:57:38: <rapido> now let's imagine an interpreter that takes this same recursive function, together with a user-defined 'number of interpreter steps' +2011-03-21.txt:20:58:09: <rapido> when the interpreter reaches the 'number of interpreter steps' it terminates +2011-03-21.txt:20:59:30: <rapido> oerjan: consing can be done - nice observation +2011-03-21.txt:21:06:03: <rapido> question: how would you give a unique name to a arbitrary block of bytes without hashing (=possible collisions) and without using a central service (thing p2p) +2011-03-21.txt:21:06:12: <rapido> thing <- think +2011-03-21.txt:21:07:06: <rapido> oh - the same block of bytes should map always return the same name +2011-03-21.txt:21:08:33: <cpressey> rapido: I don't think it's possible. +2011-03-21.txt:21:10:28: <rapido> cpressey: ok, what about a central service which just increases a counter for each new block that has been issued? +2011-03-21.txt:21:11:38: <rapido> what if we scale the central naming service to log(n) naming services - with n being the number of blocks issued? +2011-03-21.txt:21:12:04: <rapido> or square(n)? +2011-03-21.txt:21:12:23: <rapido> dns scales pretty good +2011-03-21.txt:21:18:16: <rapido> cpressey: i want to achieve (function) memoization - not only within one instance of running program - but globally +2011-03-21.txt:21:18:24: <pikhq_> rapido: No. +2011-03-21.txt:21:18:44: <pikhq_> rapido: Universal memoization is not as good an idea as you may think. +2011-03-21.txt:21:18:46: <rapido> pikhq_: no? +2011-03-21.txt:21:20:03: <rapido> pikhq_: it doesn't need to be persistent always - just the most used functions (structures) +2011-03-21.txt:21:20:29: <pikhq_> rapido: Automatic memoization is a *hard* problem. +2011-03-21.txt:21:20:54: <rapido> pikhq_: 'memoization is a *hard* problem' - i like that! +2011-03-21.txt:21:21:34: <pikhq_> rapido: At least as hard as parallel computing. +2011-03-21.txt:21:21:47: <rapido> pikhq_: i'm the author of enchilada - i have done some 'experiments' on the subject. +2011-03-21.txt:21:22:34: <oklopol> "<rapido> are there an interesting 'collection oriented' language that is not apl/j/k?" <<< toi +2011-03-21.txt:21:22:53: <rapido> i want to get rid of enchilada's cryptographic hashes - but still scale in a distributed setup +2011-03-21.txt:21:25:16: <rapido> oklopol: is there a interesting 'collection oriented' language that is also esoteric ;) +2011-03-21.txt:21:33:49: <rapido> don't surjectively inject your hilbert hotel principle into the discussion - please! +2011-03-21.txt:21:42:07: <rapido> are there any CA formalism that takes previous (N not just the current) world states as input? +2011-03-21.txt:21:42:58: <oklopol> rapido: no, but those are essentially the same thing +2011-03-21.txt:21:44:40: <rapido> oklopol: could such formalism be more powerful - not in a TC sense - but in a 'programming' sense - whatever that means +2011-03-21.txt:21:45:12: <oerjan> rapido: mcell has some "ca families" that use memory +2011-03-21.txt:21:45:35: <rapido> oerjan: thanks for the pointer +2011-03-21.txt:21:46:18: <oklopol> rapido: well i haven't seen them used, at least +2011-03-21.txt:21:48:34: <rapido> i like surreal numbers +2011-03-21.txt:21:48:51: <rapido> surreal number subsume all numbers +2011-03-21.txt:21:49:00: <rapido> number <- numbers +2011-03-21.txt:21:49:26: <rapido> hyperreal? ah yeah! +2011-03-21.txt:21:50:39: <rapido> same for quaternions +2011-03-21.txt:21:51:14: <rapido> or biquaternions +2011-03-21.txt:21:54:17: -!- rapido has quit (Remote host closed the connection). +2011-03-21.txt:21:58:07: -!- rapido has joined #esoteric. +2011-03-21.txt:22:05:53: <rapido> is there a fractal based esoteric language? +2011-03-21.txt:22:06:16: <rapido> 'living on the edge' which is infinite +2011-03-21.txt:22:08:49: <Phantom_Hoover> rapido, well, there were the Sierpiński numbers... +2011-03-21.txt:22:10:14: <rapido> Phantom_Hoover: aaah, a new number system to learn....... how many are there? +2011-03-21.txt:22:10:32: <Phantom_Hoover> rapido, it's countably infinite. +2011-03-21.txt:22:10:35: <cpressey> < rapido> is there a fractal based esoteric language? <-- I know there were a few that got to the "planning" stage, but I don't know of any complete ones +2011-03-21.txt:22:11:15: <rapido> i don't like infinite/uncountable stuff - but hey - i'' make an exception +2011-03-21.txt:22:11:16: <oerjan> <rapido> is there a fractal based esoteric language? <-- i'm pretty sure there was one but i don't remember the name +2011-03-21.txt:22:12:27: <Phantom_Hoover> rapido, well, just restrict it to finite strings. +2011-03-21.txt:22:14:36: <rapido> HP: Hilbert Problem? +2011-03-21.txt:22:15:57: <rapido> i like reversible languages: <shameless plug> enchilada is reversible (modulo hash collisions) +[too many lines; stopping]