|
900
|
1 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.
|
|
|
2 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.
|
|
|
3 2008-08-07.txt:15:32:26: -!- tusho changed the topic of #esoteric to: http://tunes.org/~nef/logs/esoteric | mmm, crapidoodle. | ☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃â˜
|
|
|
4 2008-08-08.txt:15:34:05: <tusho> "mmm...crapidoodle"
|
|
|
5 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"
|
|
|
6 2010-03-27.txt:22:22:58: -!- rapido has joined #esoteric.
|
|
|
7 2010-03-27.txt:22:24:14: <rapido> is my language is esoteric?: http://www.enchiladacode.nl ... you decide
|
|
|
8 2010-03-27.txt:22:25:18: <oerjan> rapido: looks far too well-developed to be esoteric :D
|
|
|
9 2010-03-27.txt:22:26:14: <rapido> i think to most interesting esoteric languages are extremely well-developed to be different
|
|
|
10 2010-03-27.txt:22:26:49: <rapido> pikhq: you insult me! - usable? - nah
|
|
|
11 2010-03-27.txt:22:27:06: <fax> rapido -- it doesn't look esoteric but I just glanced
|
|
|
12 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
|
|
|
13 2010-03-27.txt:22:28:48: <rapido> but i guess most esoteric languages have that property
|
|
|
14 2010-03-27.txt:22:29:12: <rapido> may be not
|
|
|
15 2010-03-27.txt:22:29:31: <pikhq> rapido: Many languages are difficult to compile efficiently.
|
|
|
16 2010-03-27.txt:22:29:58: <oerjan> rapido: befunge has that as a design feature
|
|
|
17 2010-03-27.txt:22:30:45: <rapido> pikhq: enchilada's eval is always there - always
|
|
|
18 2010-03-27.txt:22:31:18: <alise> rapido: you're the enchilada creator?
|
|
|
19 2010-03-27.txt:22:31:26: <pikhq> rapido: BTW, what makes it difficult to compile efficiently?
|
|
|
20 2010-03-27.txt:22:31:31: <alise> great to meet you rapido
|
|
|
21 2010-03-27.txt:22:31:46: <rapido> alise: thanks!
|
|
|
22 2010-03-27.txt:22:32:10: <rapido> pikhq: every unwritten term carries a hash
|
|
|
23 2010-03-27.txt:22:32:25: <rapido> code = data = hashed
|
|
|
24 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.
|
|
|
25 2010-03-27.txt:22:32:55: <rapido> alise: SHA-1 is just one choice of hash
|
|
|
26 2010-03-27.txt:22:33:05: <alise> rapido: But it is true of every hash.
|
|
|
27 2010-03-27.txt:22:33:15: <rapido> alise: is it?
|
|
|
28 2010-03-27.txt:22:33:20: <pikhq> rapido: Hashes, by definition, cannot satisfy what you ask of it.
|
|
|
29 2010-03-27.txt:22:33:36: <rapido> what is the chance of your memory to fail or have a hash collision?
|
|
|
30 2010-03-27.txt:22:33:46: <rapido> not your memory of course ;)
|
|
|
31 2010-03-27.txt:22:34:28: <pikhq> rapido: Hashes are not unique.
|
|
|
32 2010-03-27.txt:22:34:50: <alise> rapido: Well there's all sorts of "chance"; many hash functions have been broken.
|
|
|
33 2010-03-27.txt:22:35:10: <alise> rapido: Correctness doesn't care about the practical reality, though, because it is about mathematical properties.
|
|
|
34 2010-03-27.txt:22:36:46: <alise> rapido: I think Enchilada is certainly one of the most unique extant languages.
|
|
|
35 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
|
|
|
36 2010-03-27.txt:22:37:04: <alise> rapido: Me and cpressey discussed one aspect of it recently, actually.
|
|
|
37 2010-03-27.txt:22:37:15: <alise> rapido: Go and look up how many hash functions have been broken.
|
|
|
38 2010-03-27.txt:22:37:46: <rapido> alise: forget about SHA1 - think about hashes
|
|
|
39 2010-03-27.txt:22:37:58: <alise> rapido: If we're being abstract we have to be formal too.
|
|
|
40 2010-03-27.txt:22:38:04: <pikhq> rapido: This is a problem with all hashes.
|
|
|
41 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
|
|
|
42 2010-03-27.txt:22:38:30: <rapido> pikhq: i don't see it as a problem - i see it as a opportunity
|
|
|
43 2010-03-27.txt:22:38:44: <pikhq> rapido: An opportunity... For security flaws.
|
|
|
44 2010-03-27.txt:22:38:48: <rapido> if you give a little you gain a lot
|
|
|
45 2010-03-27.txt:22:39:07: <rapido> pikhq: memory failure is also a possibility
|
|
|
46 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.
|
|
|
47 2010-03-27.txt:22:39:25: <rapido> you need a physical platform - which is faulty
|
|
|
48 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.
|
|
|
49 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.
|
|
|
50 2010-03-27.txt:22:41:30: <rapido> alise: try comparing two sets which are different in only one element
|
|
|
51 2010-03-27.txt:22:41:42: <alise> rapido: How big are these sets?
|
|
|
52 2010-03-27.txt:22:41:46: <rapido> big
|
|
|
53 2010-03-27.txt:22:42:00: <rapido> let's do some O complexity
|
|
|
54 2010-03-27.txt:22:42:14: <rapido> two sets with size n and m
|
|
|
55 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.
|
|
|
56 2010-03-27.txt:22:42:34: <alise> rapido: you are appealing to practical reasons
|
|
|
57 2010-03-27.txt:22:42:58: <rapido> sure it does - but what's the most efficient algorithm?
|
|
|
58 2010-03-27.txt:22:43:53: <rapido> alise: hey, i'm just being esoteric ;)
|
|
|
59 2010-03-27.txt:22:45:19: <rapido> fax: Heresy!
|
|
|
60 2010-03-27.txt:22:45:20: <alise> rapido: Anyway, add dependent types and termination checking and I'll love it.
|
|
|
61 2010-03-27.txt:22:46:45: <rapido> alise: no exceptions, yes baby!
|
|
|
62 2010-03-27.txt:22:46:56: <alise> rapido: But it has _|_, I presume?
|
|
|
63 2010-03-27.txt:22:47:44: <rapido> no, it doesn't have bottom - everything terminates eventually
|
|
|
64 2010-03-27.txt:22:47:50: <fax> poor rapido having to listen to this :P
|
|
|
65 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.
|
|
|
66 2010-03-27.txt:22:49:42: <AnMaster> try to be somewhat nicer to rapido
|
|
|
67 2010-03-27.txt:22:49:43: <rapido> alise: i have thought of this. what about doing something 10^100000 times?
|
|
|
68 2010-03-27.txt:22:50:18: <alise> rapido: So, you are an ultrafinitist, then?
|
|
|
69 2010-03-27.txt:22:50:34: <alise> rapido: If something could never be computed it is not computable.
|
|
|
70 2010-03-27.txt:22:51:19: <rapido> alise: i like brouwer - the dutch mathematician
|
|
|
71 2010-03-27.txt:22:51:53: <alise> rapido: You are at least a constructivist then.
|
|
|
72 2010-03-27.txt:22:53:38: <rapido> let me try to explain my case
|
|
|
73 2010-03-27.txt:22:53:48: <rapido> let's say you have a long winding proof
|
|
|
74 2010-03-27.txt:22:54:00: <rapido> the proof will hold references to other proofs
|
|
|
75 2010-03-27.txt:22:54:27: <rapido> and those proofs will hold references to yet other proofs
|
|
|
76 2010-03-27.txt:22:54:49: <rapido> what is the chance of any reference to be faulty?
|
|
|
77 2010-03-27.txt:22:55:06: <rapido> what can we do to lower that chance?
|
|
|
78 2010-03-27.txt:22:55:30: <rapido> can we make a reference absolutely non-faulty - always?
|
|
|
79 2010-03-27.txt:22:55:34: <rapido> i don't believe so
|
|
|
80 2010-03-27.txt:22:55:41: <rapido> we can lower it
|
|
|
81 2010-03-27.txt:22:55:44: <alise> rapido: Eh?
|
|
|
82 2010-03-27.txt:22:56:04: <Sgeo_> rapido, that's a problem of mathematicians being wrong, not a property of mathematics itself
|
|
|
83 2010-03-27.txt:22:56:15: <rapido> alise: think of the reference itself
|
|
|
84 2010-03-27.txt:22:56:27: <alise> rapido: Define what a reference to a proof IS, as an actual object.
|
|
|
85 2010-03-27.txt:22:57:10: <rapido> alise: i'm saying that you need pointers
|
|
|
86 2010-03-27.txt:22:57:20: <alise> rapido: This is false.
|
|
|
87 2010-03-27.txt:22:57:25: <rapido> alise: to scala
|
|
|
88 2010-03-27.txt:22:57:29: <rapido> scala <- scale
|
|
|
89 2010-03-27.txt:22:58:10: <rapido> doesn't abstract mathematics need pointers?
|
|
|
90 2010-03-27.txt:22:58:27: <rapido> to refer to something? a word is a pointer
|
|
|
91 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?
|
|
|
92 2010-03-27.txt:22:59:17: <alise> rapido: No, a name is just a placeholder.
|
|
|
93 2010-03-27.txt:23:00:02: <rapido> alise: but the name must be unique, not?
|
|
|
94 2010-03-27.txt:23:00:21: <rapido> otherwise the statement will be ambigious
|
|
|
95 2010-03-27.txt:23:00:31: <rapido> ambiguous
|
|
|
96 2010-03-27.txt:23:01:13: <rapido> come on - names refer to bigger things
|
|
|
97 2010-03-27.txt:23:01:23: <rapido> they compress the bigger things
|
|
|
98 2010-03-27.txt:23:01:40: <rapido> they are a poor-mans hash of the things they refer to
|
|
|
99 2010-03-27.txt:23:02:11: <rapido> the bigger things have names in them
|
|
|
100 2010-03-27.txt:23:02:21: <rapido> they refer to other objects
|
|
|
101 2010-03-27.txt:23:02:32: <alise> rapido: I think that's rubbish.
|
|
|
102 2010-03-27.txt:23:02:37: <rapido> alise: ok
|
|
|
103 2010-03-27.txt:23:02:55: <rapido> i think it's exactly that
|
|
|
104 2010-03-27.txt:23:03:03: <rapido> that's abstraction
|
|
|
105 2010-03-27.txt:23:03:07: <rapido> to compress
|
|
|
106 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
|
|
|
107 2010-03-27.txt:23:03:34: <rapido> oerjan: yes, that's why i like hashes better than names
|
|
|
108 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
|
|
|
109 2010-03-27.txt:23:05:22: <rapido> oerjan: names may not - but who will make sure the names don't clash?
|
|
|
110 2010-03-27.txt:23:05:35: <oerjan> rapido: the compiler/verifier
|
|
|
111 2010-03-27.txt:23:06:11: <rapido> oerjan: don't you agree that names compress the complex objects hat they refer to?
|
|
|
112 2010-03-27.txt:23:06:21: <rapido> hat <- that
|
|
|
113 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
|
|
|
114 2010-03-27.txt:23:06:59: <rapido> otherwise you would end up with pure value passing semantics - which is very inefficient
|
|
|
115 2010-03-27.txt:23:07:24: <rapido> oerjan: and what's my actual argument?
|
|
|
116 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'
|
|
|
117 2010-03-27.txt:23:09:03: <rapido> fax: this would end up with names as big as the objects themselves
|
|
|
118 2010-03-27.txt:23:09:34: <rapido> fax: just would rather have the objects - thank you very much
|
|
|
119 2010-03-27.txt:23:10:06: <oerjan> rapido: i think you are reading fax backwards
|
|
|
120 2010-03-27.txt:23:11:03: <rapido> oerjan: that's right
|
|
|
121 2010-03-27.txt:23:11:16: <rapido> fax: it is an interesting thought - thanks!
|
|
|
122 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
|
|
|
123 2010-03-27.txt:23:13:11: <rapido> you just say: hey i've got this object and a name it x
|
|
|
124 2010-03-27.txt:23:13:29: <rapido> now i have this other object y, and it holds 4 x's
|
|
|
125 2010-03-27.txt:23:13:50: <rapido> and so forth
|
|
|
126 2010-03-27.txt:23:14:27: <rapido> but how are you going to name the 10^10000 object that holds other object names?
|
|
|
127 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
|
|
|
128 2010-03-27.txt:23:15:24: <rapido> who is giving out the names?
|
|
|
129 2010-03-27.txt:23:19:37: <rapido> i will give myself a name, and a won't be a hash
|
|
|
130 2010-03-27.txt:23:20:31: <Sgeo_> rapido, to be clear, you're talking about computers, and not math, right?
|
|
|
131 2010-03-27.txt:23:21:30: <rapido> Sgeo_: math is riddled with references and names that refer to complex abstractions
|
|
|
132 2010-03-27.txt:23:22:26: <rapido> Sgeo_: of course, you can always create the full proof down the axioms, without references
|
|
|
133 2010-03-27.txt:23:23:40: <rapido> Sgeo_: 'math' doesn't difference from 'computers' - whatever that means
|
|
|
134 2010-03-27.txt:23:24:55: <rapido> you can never be certain
|
|
|
135 2010-03-27.txt:23:25:03: <rapido> even mathematical proofs aren't certain
|
|
|
136 2010-03-27.txt:23:25:06: <alise> rapido: sigh
|
|
|
137 2010-03-27.txt:23:25:15: <rapido> you need faulty humans to falsify mathematical proofs
|
|
|
138 2010-03-27.txt:23:25:56: * Sgeo_ wonders if rapido might be pulling a fax.
|
|
|
139 2010-03-27.txt:23:25:59: <alise> rapido, saying that proofs aren't certain because you need humans to falsify them or something
|
|
|
140 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
|
|
|
141 2010-03-27.txt:23:26:31: <rapido> change <-chance
|
|
|
142 2010-03-27.txt:23:26:35: <alise> rapido: except when computers go wrong - they don't say "Yes this is valid omg!"
|
|
|
143 2010-03-27.txt:23:26:54: <rapido> fax: thanks for correcting me - thank you very much
|
|
|
144 2010-03-27.txt:23:27:03: <alise> he pinged Oranjer, rapido
|
|
|
145 2010-03-27.txt:23:27:16: <fax> rapido, what?
|
|
|
146 2010-03-27.txt:23:28:02: <rapido> heisenbug! now you are talking my way!
|
|
|
147 2010-03-27.txt:23:28:22: <rapido> i like heisenbugs!
|
|
|
148 2010-03-27.txt:23:28:25: <rapido> they are great!
|
|
|
149 2010-03-27.txt:23:28:57: <rapido> we should create a esoteric language called heisenbug!
|
|
|
150 2010-03-27.txt:23:29:40: <rapido> the default would be an heisenbug statement - with the remote exception of a correct statement
|
|
|
151 2010-03-27.txt:23:30:55: <rapido> if the heisenbug language proves to be turing complete - i'm done!
|
|
|
152 2010-03-27.txt:23:33:00: <rapido> pikhq: just to make you shiver: 'corporate' storage depends on hashes (that may have collisions)
|
|
|
153 2010-03-27.txt:23:33:55: <pikhq> rapido: Yes, hash tables are common.
|
|
|
154 2010-03-27.txt:23:33:56: <alise> rapido: You are mixing the practical and the theoretical, seemingly repeatedly.
|
|
|
155 2010-03-27.txt:23:34:59: <rapido> alise: i think theoretical abstractions need reality to be expressed.
|
|
|
156 2010-03-27.txt:23:35:08: <rapido> i do see the difference
|
|
|
157 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. :)
|
|
|
158 2010-03-27.txt:23:36:25: <rapido> alise: i see that - no prob :)
|
|
|
159 2010-03-27.txt:23:36:53: <alise> fax: rapido :P
|
|
|
160 2010-03-27.txt:23:37:07: <alise> rapido: Well, I applaud your work on Enchilada and hope you'll visit here often.
|
|
|
161 2010-03-27.txt:23:37:28: <rapido> fax: lol!
|
|
|
162 2010-03-27.txt:23:37:48: <rapido> fax: hey - at least i've made something runnable!
|
|
|
163 2010-03-27.txt:23:40:00: <rapido> sound like the scientific approach - repeat and measure
|
|
|
164 2010-03-27.txt:23:40:18: <rapido> alise: again we disagree
|
|
|
165 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.
|
|
|
166 2010-03-27.txt:23:42:21: <rapido> alise: your romance with math is before 1935
|
|
|
167 2010-03-27.txt:23:43:13: <rapido> alise: that math is much to great and complex and interesting to be certain
|
|
|
168 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.
|
|
|
169 2010-03-27.txt:23:44:01: <rapido> alise: and that axioms are not enough - godel has proved that
|
|
|
170 2010-03-27.txt:23:44:34: <fax> rapido: btw I think most people here are post-godel
|
|
|
171 2010-03-27.txt:23:45:03: <fax> rapido: of course it is a big factor
|
|
|
172 2010-03-27.txt:23:45:03: <rapido> sure - i'm more into popper <- an oldie also
|
|
|
173 2010-03-27.txt:23:45:38: <rapido> alise: that's one way of putting it
|
|
|
174 2010-03-27.txt:23:46:32: <rapido> alise: what i don't understand is that you allow proof checkers
|
|
|
175 2010-03-27.txt:23:46:47: <pikhq> rapido: What's to not understand?
|
|
|
176 2010-03-27.txt:23:46:49: <alise> rapido: Perhaps you do not understand what a proof checker is.
|
|
|
177 2010-03-27.txt:23:46:54: <rapido> why do you rely on faulty memory
|
|
|
178 2010-03-27.txt:23:47:05: <rapido> alise: i perfectly understand.
|
|
|
179 2010-03-27.txt:23:47:11: <alise> rapido: Your appeal to errors in memory to demonstrate that mathematics is uncertain is really poor.
|
|
|
180 2010-03-27.txt:23:47:15: <rapido> do you trust the compiler
|
|
|
181 2010-03-27.txt:23:47:27: <rapido> has the compiler been proved correctly?
|
|
|
182 2010-03-27.txt:23:47:32: <rapido> what about the processor?
|
|
|
183 2010-03-27.txt:23:47:34: <rapido> etc, etc
|
|
|
184 2010-03-27.txt:23:47:47: <alise> rapido: There is an article about this.
|
|
|
185 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
|
|
|
186 2010-03-27.txt:23:48:51: <rapido> fax: very true
|
|
|
187 2010-03-27.txt:23:49:18: <rapido> alise: http://r6.ca/homework.html <- this i don't like
|
|
|
188 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...'
|
|
|
189 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...
|
|
|
190 2010-03-27.txt:23:55:55: <rapido> now i will stop moaning about hashes
|
|
|
191 2010-03-27.txt:23:56:04: <alise> rapido: no that's false
|
|
|
192 2010-03-27.txt:23:56:29: <Sgeo_> alise, I think rapido is trying to make an analogy?
|
|
|
193 2010-03-27.txt:23:56:40: <rapido> the checking bits of faulty ram is smaller than the ram
|
|
|
194 2010-03-27.txt:23:57:28: <rapido> you can't have absolutely perfect ram
|
|
|
195 2010-03-27.txt:23:58:20: <rapido> fax: no, the most kind of impossible there is - is god
|
|
|
196 2010-03-27.txt:23:59:11: <fax> rapido oh you're another of the atheist people I guess -_-
|
|
|
197 2010-03-27.txt:23:59:12: <rapido> dixon: a sponge bob - another hero if mine!
|
|
|
198 2010-03-27.txt:23:59:24: <rapido> if <- of
|
|
|
199 2010-03-28.txt:00:01:06: <rapido> dixon: uuuh - i need to study your reference to sponge constructions
|
|
|
200 2010-03-28.txt:00:01:41: <dixon> rapido: http://sponge.noekeon.org/
|
|
|
201 2010-03-28.txt:00:01:50: <rapido> i could believe in god and still find the concept of god to be impossible
|
|
|
202 2010-03-28.txt:00:01:54: <rapido> such is believe
|
|
|
203 2010-03-28.txt:00:02:29: <rapido> dixan: ah, thanks!
|
|
|
204 2010-03-28.txt:00:02:41: <dixon> rapido: They're cryptographic hashes, however.
|
|
|
205 2010-03-28.txt:00:03:03: <rapido> dixon: cryptographic hashes are the only ones i'm considering
|
|
|
206 2010-03-28.txt:00:04:04: <dixon> rapido: But yes, by definition they're surjective when useful and thus have collisions.
|
|
|
207 2010-03-28.txt:00:04:26: <rapido> lament: then you would be a flying lunatic with wings
|
|
|
208 2010-03-28.txt:00:06:13: <rapido> dixon: all that i want is a naming service that is scalable
|
|
|
209 2010-03-28.txt:00:06:28: <Sgeo_> rapido, let the name of the proof be the content of the proof.
|
|
|
210 2010-03-28.txt:00:07:00: <rapido> Sgeo_: but proofs can be huge - think of computer generated proofs
|
|
|
211 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 ...
|
|
|
212 2010-03-28.txt:00:10:40: -!- rapido has quit (Quit: rapido).
|
|
|
213 2010-03-31.txt:20:29:19: -!- rapido has joined #esoteric.
|
|
|
214 2010-03-31.txt:21:56:37: -!- rapido has quit (Quit: rapido).
|
|
|
215 2010-04-01.txt:07:06:04: -!- rapido has joined #esoteric.
|
|
|
216 2010-04-01.txt:07:07:26: -!- rapido has parted #esoteric (?).
|
|
|
217 2010-04-07.txt:21:22:45: -!- rapido has joined #esoteric.
|
|
|
218 2010-04-07.txt:21:27:31: -!- rapido has parted #esoteric (?).
|
|
|
219 2010-04-08.txt:19:45:27: -!- rapido has joined #esoteric.
|
|
|
220 2010-04-08.txt:20:15:36: -!- rapido has quit (Quit: rapido).
|
|
|
221 2010-05-28.txt:03:58:39: <oerjan> la grande rapido universidad estatal
|
|
|
222 2011-03-21.txt:20:22:13: -!- rapido has joined #esoteric.
|
|
|
223 2011-03-21.txt:20:27:38: <rapido> are there an interesting 'collection oriented' language that is not apl/j/k?
|
|
|
224 2011-03-21.txt:20:27:46: <rapido> are <- is
|
|
|
225 2011-03-21.txt:20:29:48: <rapido> is there something like 'map theory'? I know there is something like 'array theory'
|
|
|
226 2011-03-21.txt:20:32:37: <rapido> array theory: http://www.nial.com/ArrayTheory.html
|
|
|
227 2011-03-21.txt:20:33:20: <rapido> ah found something: http://www.mangust.dk/skalberg/papers/gkli-slides1.pdf
|
|
|
228 2011-03-21.txt:20:33:25: <rapido> map theorie: v
|
|
|
229 2011-03-21.txt:20:33:30: <rapido> map theory: http://www.mangust.dk/skalberg/papers/gkli-slides1.pdf
|
|
|
230 2011-03-21.txt:20:35:14: <rapido> wouldn't it be nice to have a map oriented language?
|
|
|
231 2011-03-21.txt:20:35:32: <rapido> everything is a map - data and code
|
|
|
232 2011-03-21.txt:20:36:02: <Phantom_Hoover> rapido, map?
|
|
|
233 2011-03-21.txt:20:37:18: <rapido> concrete map: [0=0;1=1;2=4;3=9]
|
|
|
234 2011-03-21.txt:20:37:33: <Phantom_Hoover> rapido, so everything is an associative array?
|
|
|
235 2011-03-21.txt:20:38:03: <rapido> Phantom_Hoover: yes, that's one way of phrasing it
|
|
|
236 2011-03-21.txt:20:38:12: <Phantom_Hoover> rapido, finite or infinite?
|
|
|
237 2011-03-21.txt:20:38:17: <rapido> finite!
|
|
|
238 2011-03-21.txt:20:38:28: <rapido> total functions would be nice
|
|
|
239 2011-03-21.txt:20:39:46: <rapido> this would be a lazy map: [x<-[0..10000000];x*x]
|
|
|
240 2011-03-21.txt:20:40:41: <rapido> still finite because the domain is finite
|
|
|
241 2011-03-21.txt:20:42:00: <rapido> Gregor: ok, i haven't really settled for a notation
|
|
|
242 2011-03-21.txt:20:42:08: <rapido> notation <- syntax
|
|
|
243 2011-03-21.txt:20:43:39: <rapido> domain: 0..10000000 : ran ge: x*x
|
|
|
244 2011-03-21.txt:20:44:09: <rapido> Phantom_Hoover: yes - thanks
|
|
|
245 2011-03-21.txt:20:47:09: <rapido> the domain (keys) and range (values) can be maps too.
|
|
|
246 2011-03-21.txt:20:47:48: <rapido> In fact, literals are maps in disguise
|
|
|
247 2011-03-21.txt:20:48:02: <rapido> there should be only maps!
|
|
|
248 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)
|
|
|
249 2011-03-21.txt:20:51:49: <Phantom_Hoover> rapido, so basically everything is a function from a finite sense?
|
|
|
250 2011-03-21.txt:20:52:43: <rapido> Phantom_Hoover: yes
|
|
|
251 2011-03-21.txt:20:56:39: <rapido> Phantom_Hoover: say that you have an recursive function that doesn't terminate
|
|
|
252 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'
|
|
|
253 2011-03-21.txt:20:58:09: <rapido> when the interpreter reaches the 'number of interpreter steps' it terminates
|
|
|
254 2011-03-21.txt:20:59:30: <rapido> oerjan: consing can be done - nice observation
|
|
|
255 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)
|
|
|
256 2011-03-21.txt:21:06:12: <rapido> thing <- think
|
|
|
257 2011-03-21.txt:21:07:06: <rapido> oh - the same block of bytes should map always return the same name
|
|
|
258 2011-03-21.txt:21:08:33: <cpressey> rapido: I don't think it's possible.
|
|
|
259 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?
|
|
|
260 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?
|
|
|
261 2011-03-21.txt:21:12:04: <rapido> or square(n)?
|
|
|
262 2011-03-21.txt:21:12:23: <rapido> dns scales pretty good
|
|
|
263 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
|
|
|
264 2011-03-21.txt:21:18:24: <pikhq_> rapido: No.
|
|
|
265 2011-03-21.txt:21:18:44: <pikhq_> rapido: Universal memoization is not as good an idea as you may think.
|
|
|
266 2011-03-21.txt:21:18:46: <rapido> pikhq_: no?
|
|
|
267 2011-03-21.txt:21:20:03: <rapido> pikhq_: it doesn't need to be persistent always - just the most used functions (structures)
|
|
|
268 2011-03-21.txt:21:20:29: <pikhq_> rapido: Automatic memoization is a *hard* problem.
|
|
|
269 2011-03-21.txt:21:20:54: <rapido> pikhq_: 'memoization is a *hard* problem' - i like that!
|
|
|
270 2011-03-21.txt:21:21:34: <pikhq_> rapido: At least as hard as parallel computing.
|
|
|
271 2011-03-21.txt:21:21:47: <rapido> pikhq_: i'm the author of enchilada - i have done some 'experiments' on the subject.
|
|
|
272 2011-03-21.txt:21:22:34: <oklopol> "<rapido> are there an interesting 'collection oriented' language that is not apl/j/k?" <<< toi
|
|
|
273 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
|
|
|
274 2011-03-21.txt:21:25:16: <rapido> oklopol: is there a interesting 'collection oriented' language that is also esoteric ;)
|
|
|
275 2011-03-21.txt:21:33:49: <rapido> don't surjectively inject your hilbert hotel principle into the discussion - please!
|
|
|
276 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?
|
|
|
277 2011-03-21.txt:21:42:58: <oklopol> rapido: no, but those are essentially the same thing
|
|
|
278 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
|
|
|
279 2011-03-21.txt:21:45:12: <oerjan> rapido: mcell has some "ca families" that use memory
|
|
|
280 2011-03-21.txt:21:45:35: <rapido> oerjan: thanks for the pointer
|
|
|
281 2011-03-21.txt:21:46:18: <oklopol> rapido: well i haven't seen them used, at least
|
|
|
282 2011-03-21.txt:21:48:34: <rapido> i like surreal numbers
|
|
|
283 2011-03-21.txt:21:48:51: <rapido> surreal number subsume all numbers
|
|
|
284 2011-03-21.txt:21:49:00: <rapido> number <- numbers
|
|
|
285 2011-03-21.txt:21:49:26: <rapido> hyperreal? ah yeah!
|
|
|
286 2011-03-21.txt:21:50:39: <rapido> same for quaternions
|
|
|
287 2011-03-21.txt:21:51:14: <rapido> or biquaternions
|
|
|
288 2011-03-21.txt:21:54:17: -!- rapido has quit (Remote host closed the connection).
|
|
|
289 2011-03-21.txt:21:58:07: -!- rapido has joined #esoteric.
|
|
|
290 2011-03-21.txt:22:05:53: <rapido> is there a fractal based esoteric language?
|
|
|
291 2011-03-21.txt:22:06:16: <rapido> 'living on the edge' which is infinite
|
|
|
292 2011-03-21.txt:22:08:49: <Phantom_Hoover> rapido, well, there were the Sierpiński numbers...
|
|
|
293 2011-03-21.txt:22:10:14: <rapido> Phantom_Hoover: aaah, a new number system to learn....... how many are there?
|
|
|
294 2011-03-21.txt:22:10:32: <Phantom_Hoover> rapido, it's countably infinite.
|
|
|
295 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
|
|
|
296 2011-03-21.txt:22:11:15: <rapido> i don't like infinite/uncountable stuff - but hey - i'' make an exception
|
|
|
297 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
|
|
|
298 2011-03-21.txt:22:12:27: <Phantom_Hoover> rapido, well, just restrict it to finite strings.
|
|
|
299 2011-03-21.txt:22:14:36: <rapido> HP: Hilbert Problem?
|
|
|
300 2011-03-21.txt:22:15:57: <rapido> i like reversible languages: <shameless plug> enchilada is reversible (modulo hash collisions)
|
|
|
301 [too many lines; stopping]
|
