On Sat, Apr 05, 2003 at 03:22:17PM -0700, Tom Christiansen wrote: : >When you write: : : > (1..Inf) equal (0..Inf) : : >I'd like Perl to consider that false rather than having a blank look : >on its face for a long time. : : The price of that consideration would be to give the Mathematicians : blank looks on *their* faces for a very long time instead. Certainly, : they'll be quick to tell you there are just as many whole numbers : as naturals. So they won't know what you mean by equal up there.
Eh? Why should a mathematician jump to the conclusion that I'm comparing sizes of the ordered lists rather than comparing the individual elements? : The Engineers might also be perplexed if you make that false, but : for rather different reasons. I think that you will have to define : your "equal" operator in a way contrary to their respective : expectations, because both have ways of thinking that could quite : reasonably lead them to expect the answer to the expression above : to come out to be false, not true. Er, it *is* false, not true. I guess that makes me an Engineer. :-) : Practically speaking, I'm not sure how--even whether--you *could* : define it. One is tempted to attempt something like saying that : operator "equal" is true of a *lazy*, *infinite* list if and only : if elements 0..N of both lists were each themselves "equal", and : then only blessedly finite values of N. : : But where then do you stop? If N is 1, then (1..Inf) and (1..Inf:2) : are ok. If N is 2, meaning to check both the first pair from each : list and also the second one, they aren't. However, if N is true, : (1..Inf) and (1, 2..Inf:2) are certainly ok. : : In fact, that definition seems trivial to break. Given a known N : steps of comparison, the lazy lists (1..Inf) and (1..N-1, (N..Inf:2)) : would both test equal in the first N positions and differ in position : N+1. Therefore, we can always break any operator that tests the : first N positions of both lazy lists, and thus that definition would : be wrong. You're assuming that the computer isn't smart about where the list of numbers goes from enumerated to rule-generated, and that rule generators can't be compared. And they can't, in general, but the .. operator is not general, but specific, and does know how to compare the abstractions. : The reason Mr Engineer might expect false would be if they thought you were : eventually testing against Inf. Due to his experience in numerical : programming, he sees NaN and Inf having certain behaviors that no pure : mathematician would even countenance. On a system whose system nummifier : knows things like Inf and NaN already, you see this happening even today. : Witness real Perl: : : % perl -e 'printf "%g\n", NaN' : nan : % perl -e 'printf "%g\n", 1 + NaN' : nan : % perl -e 'printf "%g\n", 42 * NaN' : nan : % perl -e 'printf "%g\n", Nan == NaN' : 0 : % perl -e 'printf "%g\n", 1+Nan == NaN' : 0 : % perl -le 'printf "%g\n", Inf' : inf : % perl -le 'printf "%g\n", 1+Inf' : inf : % perl -le 'printf "%g\n", 2+Inf' : inf : % perl -e 'printf "%g\n", Inf == Inf' : 1 : % perl -e 'printf "%g\n", Inf == -Inf' : 0 : % perl -e 'printf "%g\n", 1+Inf == Inf' : 1 : % perl -e 'printf "%g\n", Inf + Inf' : inf : % perl -e 'printf "%g\n", Inf * Inf' : inf : % perl -e 'printf "%g\n", Inf / Inf' : nan Yes, but now you're talking about Inf in the context of numeric operators rather than the .. range constructor, which knows better than to ever try to evaluate Inf. To the .. operator, "Inf" doesn't mean "infinity". It means "and so on...". In fact, as the design currently stands you can also write those as: (1...) equal (0...) There, no more infinities. :-) : In other words, if you treat Inf as any particular number (which Mr : Mathematician stridently yet somewhat ineffectually reminds you that are : *not* allowed to do!), then you may get peculiar results. Heck, you could : probably then get Mr Engineer to agree that the lazy lists (1..Inf) and : (0..Inf) are the same in the *last* N positions for all values of N, and : since you could just select N to be equal (ahem) to the length (ahem**Inf) : of your list, they must be equal. :-) Again, you seem to be thinking that C<equal> would take the size of both sides as if they were arrays. I think of (1..Inf) more as a funny kind of arbitrarily extensible string, and C<equal> as a comparison "character" by "character", only they happen to be list elements instead. One could *almost* extend C<eq> to have this semantics when applied to lists. But it breaks down when you recursively want to do polymorphic == vs eq. Whereas C<< $a equal $b >> would perhaps have a few smarts about comparing dissimilar types, though not as much as ~~ does. : Mr Mathematician, purist that he is, has of course long ago thrown up his : hands in disgust, contempt, or both, and stormed out of the room. To him, : most of those Perl examples given above were utter nonsense: how can you : say 1+Inf? It bothers him to talk about Inf+1, and 1..Inf will be : problematic, too, since to say 1..Inf is also to say there must exist some : number whose successor is Inf. And of course, there isn't. Which is why : Inf is not a valid operand for numerical questions in Mr Mathematician's : platonically purist world of ideas. But practical Mr Engineer has defined : his own Inf in which you can do limited otherwise apparently numerical : operations, because it was *practical* for him to do so. He had work to : do, and needed some new rules. Sounds good to me, but then I'm an Engineer. I like practical... : While Mr Mathematician won't put up with comparing numbers and infinities, : he's quite comfortable with comparing *infinities* themselves. He's : comfortable with infinite sets, and he's comfortable with infinite series, : too, which is what these lists seem to be. I'm not sure that his : experience with infinite series will help us much here, because you see, : those aren't finite (duh). It's all fine to talk about the limit : of some convergent infinite series like the sum of 1 / (2 ** N) as : N goes from 1 to Inf, but that doesn't really seem applicable to us here. I think if Mr Mathematician wants to compare those kinds of infinities he's more than welcome to define his own classes with their own C<equal> operator. Unless, of course, the PDL have already beat him to it... : So instead of thinking about infinite series, perhaps Mr Mathematician will : when seeing your expressions (0..Inf) and (1..Inf) think of infinite : sets. Certainly (0..Inf) corresponds to the Whole Numbers and (1..Inf) : corresponds to the Natural Numbers, so this isn't a great stretch. Sets aren't ordered, while ranges are. : Perilously, the notion of comparing infinite sets takes you down Cantor : Lane, an infinitely long road whose alleys threaten madness. There, there : exists a notion of "equal" that is defined to be true whenever elements of : both infinite-set operands can be paired up sequentially--if you can make a : one-to-one correspondence between enumerable set members. Under that : definition, these all hold true : : (0..Inf) equal (1..Inf) : : (1..Inf) equal (1..Inf:2) : : (1..Inf:2) equal (1..Inf:5) : : (1..Inf) equal (1..Inf:100) : : (1..Inf) equal (1..Inf:Googleplex) : : (The Set of Integers) equal (The Set of Rationals) : : And therefore, Mr Mathematician would not be surprised by a definition of : equals that allowed all of those to come out saying that they are true. : : However, Mr Mathematician would therefore also expect any sort of testing of : : (The Set of Integers) equal (The Set of Reals) : : to come out not true but false, due to Mr Cantor's Diagonalization Proof. : Eek. Let's please not go there. Eek. Wasn't planning to. : Thankfully, we don't even have real numbers on a computer, just : finite-sized sets of rationals masquerading as real numbers. Only on a : computer are there "more" rationals than integers, and well, even there it : seems to me that given equal bitlength of N in both int and float types, : that, well, perlifically speaking, (1..2**N) equal (1..2**N), eh? :-) : : Anyway, all fun and games with Messrs Engineer and Mathematician, : you still want to find some sensible way of comparing lazily evaluated : infinite lists so that you could get some sort of answer. But what : is that answer? Or what is *an* answer? Can there even *be* one? The Halting Problem is only a problem in the general case, and some subset of the specific cases. Fortunately, computers never get discouraged by generalities. : >So whatever equivalence and ordering operators we end up with, they : >had better be able to do lazy comparisons of characters or elements : >and give up as soon as they know the answer. In fact, they need to : >be smarter than that if we also want: : : > (0..Inf) equal (0..Inf) : : >to run in finite time. Lazy arrays need to delegate the operation : >to their underlying generators whenever possible. : : As I've outlined above, I'm not completely certain that that strategy--or : in fact *any* possibly strategy--is necessarily guaranteed to provide a : sensible answer to what may or may not be a sensible question after all. Hmm, all I want is a polymorphic C<equal> operator that can compare apples to apples and oranges to oranges, with the occasional apple-to-orange comparison thrown in via multimethods to make sure things like C<< 1 equal "1" >> are true. The particular case of comparing two abstract list generators seems (in the specific case of ranges, anyway) to be amenably to some amount of analysis, at least to the point of recognizing when the generators are no longer amenable to analysis. The only real "math" that has to be done by (0...) equal (1...) is comparing 0 to 1, once you've determined that they're both infinite lists. Similarly, (1..Inf:1) equal (1..Inf:2) would have to compare the steps, but that's about it. Finite ranges are slightly hairier insofar as you have to determine whether the range is big enough that differing steps are effective: (1..1:2) equal (1..1:3) # true (1..7:2) equal (1..7:3) # false But that can still be evaluated without "triggering" the generators. On the other hand, generators like: <$handle1> equal <$handle2> are just gonna have to chug through the two streams to compare all the lines. Darn... :-) (Well, actually, if both streams are known to represent files, we could probably optimize it somewhat. But suppose one of them of them is a socket...) Hmm. If C<equal> wants a list on either side, perhaps it has a very low precedence near "or". But maybe it's more straightforward to keep it the same as "eq" and friends, and require parens around lists. That seems cleaner, and clearer. Forcing parens around a list is not always evil. Larry