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]