Re: == vs. eq
Tom Christiansen wrote: 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? Godel seems to think there is an answer, but he doesn't know what it is. Turing is trying to working it out on a piece of paper, but he can't say when (or if) he'll be finished. :-) A
Re: == vs. eq
Steffen Mueller wrote: Tom Christiansen wrote: [...] 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. [...] Unless I'm very wrong, there are more whole numbers than natural numbers. An induction should prove that there are twice as many. Actually it is easy to do a mapping that is one to one and onto, between them so in that sense there is the same number of numbers in them. /Stefan
Re: == vs. eq
On Sat, Apr 05, 2003 at 05:28:16PM -0700, Tom Christiansen wrote: Is it possible that finite internal representations will differ in internal representation yet produce identical series? ..[snip].. Those define identical list, for any natural numbers X and Y, even as compile-time constants. However, save for special case of X==Y, I do not expect their internal representation to be the same. I just said you can *compare* them, I didn't say test whether they're identical. Obviously comparing internal representations is a tricky business, and may have three results: yes, the lists they generate are equal, no, the lists they generate are not equal, I have no clue. In the last case, per-element comparison will need to be done. for ($i = 1; $i = fn(); $i++) for $i ( 1 .. fn() ) and making instead a list or array whose members are ( 1 .. fn() ) However, do you evaluate fn() only once or repeatedly? If a compiler does such an optimization, it needs to make sure fn() is evaluated repeatedly unless it knows for sure fn() will return the same value for each iteration and has no side-effects. I think this means that if fn() does *not* meet those conditions, the compiler can not use a list, because it would risk changing the semantics. I believe we are indeed trying to define what we want it to do, no? So sure, you can create a new infinite set by conjoining some new elements to an existing one. That's what all the numberic sets are, pretty much. Do be careful that the result has consistent properties, though. Well, in perl's tradition, I think it's more important for Inf to do what we mean than to be consistent. IEEE Inf behavior is useful enough, with some constructions (such as the range operator) behaving specially when it occurs as one of the operands. But most of the Laws of Arithmetic as you and I know them do not apply to these values. (One could say as much for floating-point numbers, I suspect.) Yes you can. But since the p in perl stands for practical, I don't see that as a problem. If we really want a mathematically pure system, it could probably be implemented using a module. -- Matthijs van Duin -- May the Forth be with you!
Re: == vs. eq
--- Matthijs van Duin [EMAIL PROTECTED] wrote: I just said you can *compare* them, I didn't say test whether they're identical. Obviously comparing internal representations is a tricky business, and may have three results: yes, the lists they generate are equal, no, the lists they generate are not equal, I have no clue. In the last case, per-element comparison will need to be done. Unless the compiler already knows it's from a generator. Then it only has to compare the existing elements, and if they compare, then the generator itself. ( 1 .. fn() ) However, do you evaluate fn() only once or repeatedly? If a compiler does such an optimization, it needs to make sure fn() is evaluated repeatedly unless it knows for sure fn() will return the same value for each iteration and has no side-effects. I think this means that if fn() does *not* meet those conditions, the compiler can not use a list, because it would risk changing the semantics. I must've missed something. Why would the compiler consier the value of fn() any if it's business? Unles the sig expressly states it as Inf or some other generative value, then that's a run-time issue. It it returns any integer-equivelent value (for that context) then what's the difference between that and 1..999? The compiler should probably just assume the number will be large, take whatever hit is associated with that possibly mistaken assumption, and go about it's business. If the function returns Inf with no warning, what would it do? the same thing. But you *can't* know what it will return in cases where there hasn't been enough info supplied. If 1..fn() is called in a list context, then it's 1..To_Be_Determined. Now, in a *scalar* context it's another story, and would call fn() as often as appropriate. I believe we are indeed trying to define what we want it to do, no? [snip] Do be careful that the result has consistent properties, though. Well, in perl's tradition, I think it's more important for Inf to do what we mean than to be consistent. IEEE Inf behavior is useful enough, with some constructions (such as the range operator) behaving specially when it occurs as one of the operands. Agreed, within the boundaries of the principle of least surprise. I *do* want whatever it does to make some sense, preferably to more people than not -- even if that violates IEEE, though I doubt it will. But most of the Laws of Arithmetic as you and I know them do not apply to these values. (One could say as much for floating-point numbers, I suspect.) Yes you can. But since the p in perl stands for practical, I don't see that as a problem. If we really want a mathematically pure system, it could probably be implemented using a module. Again, agreed. Not all programmers are engineers. Some of us are even working with less than the ideal theoretical mathematical background, but are still trudging along trying to make a living shovelling bits. I for one *love* most any kind of theory discussion, but have never actually taken a trigonometry course, much less anything more advanced. Perl needs to be able to handle complicated situations, but how often will you need imaginary numbers? Python handles complex numbers out-of-the-box; I've *never* seen a use for it, other than saying oh, that's cool. But then, I don't do deep math at my job. I just shovel bits. :) On the other hand, Perl could implement a module that does complex numbers, and I suspect there are more available that I could shake a search engine at. Inf is going to be supported in the core, but we need to keep in mind that it doesn't represent INFINITY in any literal sense: it represents it in a metaphorical sense, the same way $revenue represents money. It's just an untyped scalar, and could easily hold a digital image of a tuna, but the coder uses it to do a particular thing, and names it accordinly. Inf is intended to stand in for an unreachable distant point in Perl, or an incalculable of some sort. It's the optimizer's job to make sure the program never actually tries to generate the entire set represented by 1..Inf -- which I personally think is *much* better written as (1...)! Ok, I think I'm ranting. Up too late, up too early getting ready for a model that can't make it, found out this morning the time had changed and I was an hour off schedule but hey, now I have time to rant here. :) Good morning, people. __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
Re: == vs. eq
Tom Christiansen wrote:
Unless I'm very wrong, there are more whole numbers than natural
numbers. An induction should prove that there are twice as many.
We're probably having a language and/or terminology collision. By natural
numbers, I mean the positive integers. By whole numbers, I mean the
natural numbers plus the number zero.
[...]
I meant naturals plus 0 plus negative integers by whole numbers.
Nonethelesss, I was wrong and stand corrected. I'll think about my posts
a little more thoroughly in future before hitting the send button.
Steffen
--
@n=([283488072,6076],[2105905181,8583184],[1823729722,9282996],[281232,
1312416],[1823790605,791604],[2104676663,884944]);$b=6;@c=' -/\_|'=~/./g
;for(@n){for$n(@$_){map{$h=int$n/$b**$_;$n-=$b**$_*$h;[EMAIL PROTECTED]
0..11;[EMAIL PROTECTED],[EMAIL PROTECTED];[EMAIL PROTECTED]\n[EMAIL PROTECTED];
Re: == vs. eq
On Sun, Apr 06, 2003 at 05:52:30AM -0700, Paul wrote: I just said you can *compare* them, I didn't say test whether they're identical. Obviously comparing internal representations is a tricky business, and may have three results: yes, the lists they generate are equal, no, the lists they generate are not equal, I have no clue. In the last case, per-element comparison will need to be done. Unless the compiler already knows it's from a generator. Then it only has to compare the existing elements, and if they compare, then the generator itself. That falls in the first case: the internal representation would consist of the already-generated elements and a genereator for the rest. Comparison of the internal states will yield yep, they're equal so no (potentially infinite) per-element comparison is necessary. ( 1 .. fn() ) However, do you evaluate fn() only once or repeatedly? If a compiler does such an optimization, it needs to make sure fn() is evaluated repeatedly unless it knows for sure fn() will return the same value for each iteration and has no side-effects. I think this means that if fn() does *not* meet those conditions, the compiler can not use a list, because it would risk changing the semantics. I must've missed something. Why would the compiler consier the value of fn() any if it's business? What you've missed is that the context was the optimization of: for ($i = 1; $i fn(); $i++) Semantically this code is required to evaluate fn() for each iteration, so the optimizer can't just replace it with for ( 1 .. fn() ) in the general case, however it can do so if and only if it can ascertain that fn() will return the same value for each iteration, and has no side-effects. Perl needs to be able to handle complicated situations, but how often will you need imaginary numbers? Python handles complex numbers out-of-the-box; I've *never* seen a use for it, other than saying oh, that's cool. But then, I don't do deep math at my job. I just shovel bits. :) Complex numbers can be useful, although not for typical applications in perl's target audience. It seems to me they can however be easily added as a class. Inf is going to be supported in the core, but we need to keep in mind that it doesn't represent INFINITY in any literal sense [...] and could easily hold a digital image of a tuna I vote yes on that, if it doesn't add too much to the size of the runtime library :-) -- Matthijs van Duin -- May the Forth be with you!
Re: == vs. eq
On Tue, Apr 01, 2003 at 06:39:24PM -0500, Miko O'Sullivan wrote: : Of course, you can also cast the objects to change what type of comparison : you want. So, for example, C$a =:= $b compares the outputs of the : value_for_comparison methods, but C~$a =:= ~$b compares the numification : of the objects, or, to get into the guts of the matter, the objects are : evaluated in numeric context, which causes them to run their overflow : methods for numification, which returns number objects, which then call : their value_for_comparison methods, which return the numbers as : represented by some string which is formatted according to some : unambiguous rule (we already have those unabiguou rules). The problem with this approach is that it assumes you can efficiently return a string to be compared. I'm not sure this is even true of strings, let alone arrays and hashes. 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. It's just a generalization of how eq and cmp give up as soon as they see two different characters in a string. 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. Larry
Re: == vs. eq
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. 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. 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. 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 =begin ASIDE Yes, it's platform dependent what you'll get: mach1% perl -le 'printf On $^O, NaN == NaN is %g\n, Nan == NaN' On openbsd, NaN == NaN is 1 mach2% perl -le 'printf On $^O, NaN == NaN is %g\n, Nan == NaN' On linux, NaN == NaN is 0 I believe that's because the libc on openbsd doesn't nummify string NaN to any special IEEE float, whereas the redhate one did. I am truly hoping that on Perl6, comparing apples with greed will mean that you're testing NaN with itself, that testing NaN and *anything* including another Nan with == will get you into trouble no matter what your platform, and that that trouble will be the same irrespective of platform. =end ASIDE 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. :-) 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. 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
Re: == vs. eq
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. Based on his description, he meant element-wise equality. And since the first element of (1..Inf) is 1, and the first element of (0..Inf) is 0, I agree with the result being false. So no blank stare from me (student of mathematics) The length of both will be Inf ofcourse (meaning countably infinite. I don't think we have a need for working with uncountably infinite sets in perl ;-) Practically speaking, I'm not sure how--even whether--you *could* define it. You can define is very easily: two lists are equal if the ith element of one list is equal to the ith element of the other list, for all valid indices i. As for whether you can *evaluate* this test in bounded time, that depends. Computers are incapable of storing truly infinite lists, so the lists will have finite internal representations which you can compare. As for two dynamically generated infinite lists (which you can't easily compare, for example if they're based on external input)... it will either return false in finite time, or spend infinite time on determining they're indeed equal. 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. There is no problem with doing that, as long as you define what you want it to do. Remember, most of mathematics is just an invention of humans :) (crap about testing first/last N elements) testing the first/last N elements is not the same as testing the whole list for all N :) 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 If he has, he's a very narrow-minded Mr Mathematician how can you say 1+Inf? Unless you're speech-impaired, it's not too hard 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. *cough*bullshit writing the interval 1..infinity is very common I've skipped the rest.. not in the mood... but you make many references to a Mr Mathematician I don't think I want to work with... luckily I haven't seen him around here at the maths faculty -- Matthijs van Duin -- May the Forth be with you!
Re: == vs. eq
On Sun, Apr 06, 2003 at 12:38:29AM +0200, Matthijs van Duin wrote: 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. There is no problem with doing that, as long as you define what you want it to do. Actually, if you really want to do infinities the math-way, then just grab a book on set theory. one thing you might not like however is that when you go beyond the finite, it becomes necessary to differentiate between cardinal and ordinal numbers. That's probably something you don't want to do in perl The IEEE-float-style infinities are quite sufficient for most purposes One thing I agree is that writing 1..Inf is a *bit* sloppy since the range operator n..m normally produces the numbers i for which n = i = m while n..Inf gives n = i Inf but I can live with it -- Matthijs van Duin -- May the Forth be with you!
Re: == vs. eq
Tom Christiansen wrote:
[...]
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.
[...]
Unless I'm very wrong, there are more whole numbers than natural
numbers. An induction should prove that there are twice as many.
Steffen
--
@n=([283488072,6076],[2105905181,8583184],[1823729722,9282996],[281232,
1312416],[1823790605,791604],[2104676663,884944]);$b=6;@c=' -/\_|'=~/./g
;for(@n){for$n(@$_){map{$h=int$n/$b**$_;$n-=$b**$_*$h;[EMAIL PROTECTED]
0..11;[EMAIL PROTECTED],[EMAIL PROTECTED];[EMAIL PROTECTED]\n[EMAIL PROTECTED];
Re: == vs. eq
You can define is very easily: two lists are equal if the ith element of
one list is equal to the ith element of the other list, for all valid
indices i.
The problem is that you've slipped subtly from a well-known creature, like
1..10, a finite set of ten distinct integers, to a quite a different sort
of beast entirely, 1..Inf, which while notationally similar to the first,
does not share some very fundamental properties. For example, it no longer
has an integral membership count, that is, a length. This is problematic
if one is not quite careful.
As for whether you can *evaluate* this test in bounded time, that depends.
Computers are incapable of storing truly infinite lists, so the lists will
have finite internal representations which you can compare.
Is it possible that finite internal representations will differ in
internal representation yet produce identical series? It seems to me that
some meta-analsys would be required if this is possible. If it is not
possible, then that means that every distinct series has a distinct
internal representation. Certainly this is not true lexically: I can
use many variant lexical representations to produce the same infinite
series. For example:
(1 .. X, X+1 .. Inf)
(1 .. Y, Y+1 .. Inf)
Those define identical list, for any natural numbers X and Y, even as
compile-time constants. However, save for special case of X==Y, I do
not expect their internal representation to be the same.
As for two dynamically generated infinite lists (which you can't easily
compare, for example if they're based on external input)... it will either
return false in finite time, or spend infinite time on determining they're
indeed equal.
I suppose you could classify
(1 .. X, X+1 .. Inf)
(1 .. Y, Y+1 .. Inf)
as dynamically generated infinite lists, but again, given constants X and
Y, they really needn't be. Even a run-time thing like the list (1 .. $X)
shouldn't actually need to spend infinite time on determining its
equivalence to (1 .. $Y). However, there are more interesting
possibilities: generic iterator functions that you repeatedly call and
which produce successors that aren't generally recognizable. Remember the
old flipflop, as in
if ( 1 .. /^$/ ) { }
if ( /foo/ .. /bar/ ) { }
if ( f() .. g() ) { }
You could, a think, have an infinite list that was really some fancy
interface to a dynamic interator of some sort. I know it's interesting,
but whether this would be sufficiently useful to justify its complexity is
rather less obvious. But if you did have such a list, where stepping
down it implicitly called some sort of -ITER method or whatnot, then
for those I could see the intractability of finite evaluation, since it's
perfectly conceivable that it wouldn't terminate. Another pitfall is
non-reproduceability; think about readline() as an iterator on a stream
object whose underlying file descriptor is not seekable. But I'm not sure
that the any of the sorts of lists we've been talking about have to have
that problem. But I don't know whether we can be clever enough to step
around infinite evaluation through some sort of higher-level analysis.
A clever compiler could move things around. Maybe it could change
for ($i = 1; $i = 10_000; $i++)
into
for $i ( 1 .. 10_000 )
and then perhaps take advantage of that construct's lazy evaluation.
Given general purpose lazy evaluation, you could start doing things
like thinking of
for ($i = 1; $i = fn(); $i++)
for $i ( 1 .. fn() )
and making instead a list or array whose members are
( 1 .. fn() )
However, do you evaluate fn() only once or repeatedly?
Hm.
If it were repeatedly, then I do see what you mean by dynamically
generated infinite lists.
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.
There is no problem with doing that, as long as you define what you want
it to do.
Well, sure, you could let Inf = MAXINT + 1 for example, and then define
things as you want them to act, but that doesn't mean that this resulting
Inf is either what people think of as a Number nor what they think of as
Infinity. See below on IEEE, which found it very useful to something of
the like.
Remember, most of mathematics is just an invention of humans :)
I believe we are indeed trying to define what we want it to do, no?
So sure, you can create a new infinite set by conjoining some new elements
to an existing one. That's what all the numberic sets are, pretty much.
Do be careful that the result has consistent properties, though.
(crap about testing first/last N elements)
testing the first/last N elements is not the same as testing the whole list
for all N :)
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
Re: == vs. eq
Unless I'm very wrong, there are more whole numbers than natural numbers. An induction should prove that there are twice as many. We're probably having a language and/or terminology collision. By natural numbers, I mean the positive integers. By whole numbers, I mean the natural numbers plus the number zero. Since both sets have infinite members, each has just as many members as the other has. It just *looks* like the whole numbers have one more. But they don't, you know, because Inf+1 == Inf, as IEEE shows us in their seminal treatise on How to Lie With Computers under IEEE Floating Point. It's not really relevant to figuring out how to evaluate equality testing on unbounded lists in Perl, but I think that your inductive proof would lead you to conclude the opposite of what you're thinking. You can pick a first member of both sets. Then you can pick a second member of both sets. Then a third, then a fourth, and so and so forth for all cardinal numbers. Even though your list of pairings one from each set itself stretches to infinity (not that that means it actually stops somewhere, of course, as though infinity were a place; I mean it just stretches ever upwards without bound), then I think induction will convince you that in the resulting pair-list, there are no missed members from either set. So we are comfortable saying that there are just as many of one as the other; well, *I* am comfortable saying that, at least, and I hope you are, too. :-) It's initially a bit disturbing, though, when you realize that this necessarily leads to saying there are just as many multiple of two as there are of, oh, eight. Maybe that's why Cantor died mad. :-) --tom
Re: == vs. eq
The IEEE-float-style infinities are quite sufficient for most purposes One thing I agree is that writing 1..Inf is a *bit* sloppy since the range operator n..m normally produces the numbers i for which n = i = m while n..Inf gives n = i Inf but I can live with it I could sure save myself a lot of typing by reading ahead to message N+1 before answering message N. :-) --tom PS: For all N. :-):-)
Re: == vs. eq
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 Cequal 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 Cequal as a comparison character by character, only they happen to be list elements instead. One could *almost* extend Ceq 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
Re: == vs. eq
Austin Hastings wrote:
It has been pointed out once already that we already talked about this,
and I for one am in favor of the general version of it.
The original discussion posited an adverbial comparison, viz:
C$a eq:ref $b. Which, looking at your proposal, is very close to
C$a =:= $b, because I'm reading that as equals, under assignment.
What was decided about the adverbial ops -- did we ever get a
confirmation or rejection on that proposal, or did it die in the ether?
I like the idea lots (though I still would argue that identity-compare
=:= is important enough conceptually to be a separate case.) My only
worry is that we make sure they don't cannibalize their own namespace.
For example, to create an adverbial eq that works like this:
$a eq:soundex $b;
I wonder if it shouldn't be declared as:
sub infix:eq:soundex ($a,$b) {...}
as opposed to the simpler:
sub soundex ($a,$b) {...}
I.E. would you ever use the 'soundex' adverb without the 'eq', and if
not, mightn't you just call it 'eq:soundex' and be done with it? (If we
made the colon allowable for the case of infix other ops
declarations?) That way you could have things like
$a eq:foo $b;
$a gt:foo $b;
$a lt:foo $b;
$a +:foo $b;
and the various declarations of 'foo' wouldn't get in each other's way,
even if you had a whole mess of 'em.
MikeL
Re: == vs. eq
--- mlazzaro [EMAIL PROTECTED] wrote: Austin Hastings wrote: It has been pointed out once already that we already talked about this, and I for one am in favor of the general version of it. The original discussion posited an adverbial comparison, viz: C$a eq:ref $b. Which, looking at your proposal, is very close to C$a =:= $b, because I'm reading that as equals, under assignment. What was decided about the adverbial ops -- did we ever get a confirmation or rejection on that proposal, or did it die in the ether? I'd still like to know as well. I must've missed it. I like the idea lots (though I still would argue that identity-compare =:= is important enough conceptually to be a separate case.) I *disagree* with that, though only in principle. I don't want the code to require a lot of special cases. That was one of P5's problems. Larryco are doing a beautiful job of designing a system by which the language is systematically and semantically consistent. Admittedly, I'm not doing any of the under-the-hood design, but for the sake of those who are as well as my own, I'd rather see the smallest possible number of seperate case situations. __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
Re: == vs. eq
On Thu, 3 Apr 2003, mlazzaro wrote: Yes. I expect that internally, that's how it will work. (And agreed, C.ref is probably a good name.) My concern with explicitly comparing refs in order to compare identity is a philosophical one. It may be perfectly acceptable to do it via $x.ref == $y.ref;# do they exist at the same location? but I worry that that is a bit obtuse. I'd rather people didn't have to worry about comparing reference locations, even indirectly, because it leads to thinking you can do things like this: my $loc = $x.ref; ...stuff... $loc == $y.ref;# OOPS: but has $x moved since then? Depending on the implementation, code like that might be dangerous. I don't thing there is any danger. Consider this: my $xref = \$x; ...stuff... print $$xref;# OOPS: but has $x moved since then? Obviously that oops is not a concern. The reference is not necessarily a memory address. The GC can move objects around if it wants, but it must make sure the references to an object still refer to the object. The danger I see with reference comparison involves the perl6 auto-dereferencing, and how to be sure we have a reference-to-an-object and not a reference-to-a-reference-to-an-object. For example: $b = @a; $b.ref; # is this [EMAIL PROTECTED] or [EMAIL PROTECTED] $b.ref == @a.ref; # will this work? should this work? I like the suggestion of =:= in particular because it so clearly relates to bound to, so it feels quite elegant. Personally, I doubt the necessity of yet-another-operator, because I'm not convinced the operation is a frequent one. We may both be biased by our personal coding experience on that count. But, no one can stop you from defining infix:=:= in your own code. ~ John Williams
Re: == vs. eq
John Williams wrote: On Tue, 1 Apr 2003, Michael Lazzaro wrote: So I *really* don't think comparing the equality of references will be a good idea, in P6. snip The main point is that the reference is a unique identifier for an object. At least, I haven't been able to think why it wouldn't be yet (barring persistence). Yes, I believe that to be true as well. For all practical purposes, the memory address of an object is a unique identifier for the object, since only one object can exist at the same point in memory. Well, probably. :-) So if you cede that point, achieving your identity comparison is a trivial matter of spelling the comparison correctly. Maybe its $x.ref == $y.ref, since 'ref' is less common than 'id'. Maybe its something else. Yes. I expect that internally, that's how it will work. (And agreed, C.ref is probably a good name.) My concern with explicitly comparing refs in order to compare identity is a philosophical one. It may be perfectly acceptable to do it via $x.ref == $y.ref;# do they exist at the same location? but I worry that that is a bit obtuse. I'd rather people didn't have to worry about comparing reference locations, even indirectly, because it leads to thinking you can do things like this: my $loc = $x.ref; ...stuff... $loc == $y.ref;# OOPS: but has $x moved since then? Depending on the implementation, code like that might be dangerous. In addition to discouraging the above behavior, the main reason I like an operator-based solution is that it can be used to test identity-equality in a very explicit way. You're not testing whether two objects exist at the same location -- you're testing whether two objects share the same identity. In practice, those two concepts are linked, but conceptually I'd rather teach people to think of it as the latter. I like the suggestion of =:= in particular because it so clearly relates to bound to, so it feels quite elegant. MikeL
Re: == vs. eq
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
One thing we should clear up is that we already *have* a generic
comparator, C~~, depending on what you mean by generic. It can
be
made to compare things however you like, according to whatever
standard
of similarness you decide you want to enforce, and can even compare
objects of disparate types (if you tell it how.)
The way I personally have been envisioning this working is:
$a == $b; # compares numerifications of $a and $b
$a eq $b; # compares stringifications of $a and $b
$a ~~ $b; # tests equality of $a and $b
$a =:= $b; # tests identity of $a and $b
Of these, I would expect that ==, eq, and =:= would almost never be
overloaded, because they have very specific meanings.[*]
You _could_ choose to override those == and eq for a particular
custom
class, and use those for comparing equality of objects. But since
some
people will tend to want to override ==, and some will want to
override
eq, it's not clear that the Perl6 community will converge on using
only
one or the other, which might make things quite confusing if you're
using a library that has standardized on the opposite convention from
your own.
~~, on the other hand, is meant to be overloaded to a
possibly-excruciating extent, and I've been assuming that it will be
the thing that classes most often overload when they want to test
equality of two arbitrary objects, without resorting to serializing
them via num/str. (Using num/str comparisions to test for object
equality obviously only works if num/stringifying _completely_
serializes the object -- which very often is _not_ what you want the
num/stringification of an object to do, by default.)
The proposed =:=, however, merely tests that two objects are
identical
-- that is, _that they are bound to the same underlying thing_. It's
possible for two objects to be equal, ~~wise, without actually being
identical, identitywise. I don't see ever wanting to overload =:=,
and
it's unclear if it should even be allowed.
It has been pointed out once already that we already talked about this,
and I for one am in favor of the general version of it.
The original discussion posited an adverbial comparison, viz:
C$a eq:ref $b. Which, looking at your proposal, is very close to
C$a =:= $b, because I'm reading that as equals, under assignment.
Likewise, I could argue that it be called C=:\ (the disgruntled
muppet operator?) since that reflects the equals, under reference
symbology. But that's yucky.
So: I believe that adverbial comparisons are desirable, and in fact
believe that arbitrary-sub comparisons are desirable, provided they
don't cost much.
sub budgetwise(Int $a, Int $b) { -1_000_000 = $a - $b = 1_000_000; }
my Int $log_rolling, Int $pork_barrel;
$log_rolling = random() * 1.0E9;
$pork_barrel = random() * 1.0E9;
if ($log_rolling eq:budgetwise $pork_barrel)
print They cost the same, give or take a million dollars.;
Note also that == and eq comparisions are naturally accompanied by
greater-than, less-than variants. But ~~ and =:= don't really have
those variants, because they wouldn't make much sense.
Even inverted comparisons are suspect in junctionville.
Having said all that, it should be noted that I'm completely making
this stuff up.
Finest kind.
Re: == vs. eq
--- Austin Hastings [EMAIL PROTECTED] wrote:
Likewise, I could argue that it be called C=:\ (the disgruntled
muppet operator?) since that reflects the equals, under reference
symbology. But that's yucky.
Shouldn't that be ==:/ (maybe the severely startled muppet operator?
lol...) A single = would be assignment, but I have no idea how
adverbial modification would affect that. Exactly what *would*
adverbial assignment be? Would
$a =:\ $b
be like
$a = \$b;
sub budgetwise(Int $a, Int $b){-1_000_000 = $a - $b = 1_000_000;}
my Int $log_rolling, Int $pork_barrel;
$log_rolling = random() * 1.0E9;
$pork_barrel = random() * 1.0E9;
if ($log_rolling eq:budgetwise $pork_barrel)
print They cost the same, give or take a million dollars.;
Is that saying to make budgetwise the comparison operator at the same
precedence as eq?
Wouldn't that be much like saying
my sub infix:um (Int $a, Int $b) is equiv(infix:eq) { # c.f.A6 p.11
-1_000_000 = $a - $b = 1_000_000; }
if ($log_rolling um $pork_barrel) # etc
So how does one get a ref in P6 that won't dereference itself???
The we could say
my sub infix:embodies ($a,$b) is equiv(infix:eq) {
$a.ref eq $b.ref # unless eq deref's even here.
}
if ($x embodies $y) {
print X and Y refer to the same entity\n;
}
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Re: == vs. eq
--- Austin Hastings [EMAIL PROTECTED] wrote:
--- Paul [EMAIL PROTECTED] wrote:
--- Austin Hastings [EMAIL PROTECTED] wrote:
Likewise, I could argue that it be called C=:\ (the
disgruntled muppet operator?) since that reflects the
equals, under reference symbology. But that's yucky.
Shouldn't that be ==:/ (maybe the severely startled muppet
operator? lol...) A single = would be assignment, but I have
no idea how adverbial modification would affect that. Exactly
what *would* adverbial assignment be? Would
$a =:\ $b
be like
$a = \$b
Still no input here. Was it a stupid question? :)
sub budgetwise(Int $a, Int $b) {
-1_000_000 = $a - $b = 1_000_000; }
my Int $log_rolling, Int $pork_barrel;
$log_rolling = random() * 1.0E9;
$pork_barrel = random() * 1.0E9;
if ($log_rolling eq:budgetwise $pork_barrel)
print They cost the same, give or take a million dollars.;
Is that saying to make budgetwise the comparison operator at the
same precedence as eq?
Actually, what I think I'm saying in this case is replace the do()
behavior of infix:eq with this sub.
Okay, that clicked. I'm here now.
Which has kind of startling effects, because then you can also say
things like this:
sub uniquely(@dest is rw, @src) {
my $last = @src[0] ~ 1;
for @src - $s {
@dest.push($last = $s) unless $s == $last;
}
}
my @a = ; # Read all lines from a file.
my @b =:uniquely @a;# Eat the duplicates
(Apologies: code above reformatted purely in the interest of readable
space, and not considered an improvement. :O)
Ok, so you replace ='s do{} with uniquely(). The example won't work to
assign to a scalar, right? I think I'm following you, and I like where
you're going.
My God, it's full of stars
Wouldn't that be much like saying
my sub infix:um(Int$a,Int $b)is equiv(infix:eq){#c.f.A6p.11
-1_000_000 = $a - $b = 1_000_000; }
if ($log_rolling um $pork_barrel) # etc
Looks right to me, modulo type-casting behavior -- I think yours does
typechecking and blows up if the types are misaligned enough, while
mine finds the right infix:= operator, and replaces the actual
mechanics. (Frankly, I'm not sure what the right behavior of mine is.
It may be better to think of it as temporizing the infix:= operator
for one expression only. More thought required.)
Good territory to expore.
So how does one get a ref in P6 that won't dereference itself???
No idea. I thought that the auto-da-fe^Wautodereference behavior was
intended to make loose references impossible -- that is, you have
to treat a reference object as an object, always. (Which just means
more backslashes, I guess.)
Then we could say
my sub infix:embodies ($a,$b) is equiv(infix:eq) {
$a.ref eq $b.ref # unless eq deref's even here.
}
if ($x embodies $y) {
print X and Y refer to the same entity\n;
}
Maybe you just have to say C\$a eq \$b ?
Makes sense to me. Then the right spelling of the above would be
my sub infix:embodies ($a,$b) is equiv(infix:eq) { \$a eq \$b }
The only reason I didn't put that to begin with was because of a
discussion I saw about arrays deref'ing themselves. Let's try again
with a little more complexity:
my sub infix:embodies(Ref $a is ref,$b is ref)is equiv(infix:eq){
$a eq $b
}
Could it be this simple? (Granted, for some definition of simple)
If I read this right, it means $a is a referencing alias of the first
argument, $b the second. Could we then say
if (@x embodies @y) { foople() }
and have it DWIM? Would that mean (in P5-speak) $a-[0] *IS* @x[0] ???
Because if so, then that's exactly what Larry was talking about. The
cruft has been sucked back up into the signature where the coder had
to work out the details *once*, and then the code of the operator is
deafeningly simple, as is it use.
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Re: == vs. eq
Error correction:
--- Paul [EMAIL PROTECTED] wrote:
no idea how adverbial modification would affect that. Exactly
what *would* adverbial assignment be? Would
$a =:\ $b
be like
$a = \$b
Thatv should have been: would
$a =:\ $b
be like
\$a = \$b
???
And does that mean that the do{} block of the \ operator replaces the
do{} of the = op? That wouldn't work.
But the resulting muppet really *IS* cute! ;~}
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
RE: == vs. eq
Luke Palmer:
# The first thing I noticed was the == / eq distinction. This
# has been invaluable for scripting, but since Perl 6 is
# desiring to be more of a formal language, I'm wondering
# whether the distinction is profitable. In generic programming
# (my specialty :), it is very useful to have a standard sort
# of equality[*] that all participating objects define.
Your desired standard sort of equality is provided by smartmatch.
$a ~~ $b
# The solution that springs to mind is to conform to other
# languages' thought and make == polymorphically compare
# equality. Thanks to context-forcing, the string/numeric
# distinction is still there, at the expense of a little extra
# verbosity:
#
# +$a == +$b; # Numeric compare
# ~$a == ~$b; # String compare
# $a == $b; # Generic compare
Conciseness and precision are lost. What's gained?
# Then we could also use eq for real identity, if we wanted to.
Which is the more common operation, string equality or identity check?
Thought so.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
Re: == vs. eq
Luke Palmer:
# The first thing I noticed was the == / eq distinction. This
# has been invaluable for scripting, but since Perl 6 is
# desiring to be more of a formal language, I'm wondering
# whether the distinction is profitable. In generic programming
# (my specialty :), it is very useful to have a standard sort
# of equality[*] that all participating objects define.
Your desired standard sort of equality is provided by smartmatch.
$a ~~ $b
Don't get too hasty here, I actually did put some thought into this.
Smart match was not what I was thinking of. I don't think two hashes
should be considered equal if their key intersection is nonempty.
# The solution that springs to mind is to conform to other
# languages' thought and make == polymorphically compare
# equality. Thanks to context-forcing, the string/numeric
# distinction is still there, at the expense of a little extra
# verbosity:
#
# +$a == +$b; # Numeric compare
# ~$a == ~$b; # String compare
# $a == $b; # Generic compare
Conciseness and precision are lost. What's gained?
IOne solitary equality operator. Remember, I'm considering this
from a generic programmer's point of view. I'm already aware that the
== eq distinction is useful for scripting.
class Map {
method insert(Pair $p) {
push @.elems: $p;
}
method get($key) {
for (@.elems) { return $_.value if $_.key == $key }
}
has Pair @.elems;
}
Or should that have been C$_.key eq $key? It certainly shouldn't have
been ~~ (lest this work:)
my Map $map;
my @array = (1..5);
my @other = (4..12);
$map.insert(@array = 1);
$map.get(@other); # Returns 1 !!!
Whatever the array equality operator is, it sure isn't that! :)
Do you see the problem now? If I use ==, then I get length
comparison. If I use eq, then I get string comparison (which,
depending on the elements' types, may not be correct).
Map was just a coded example of what Hash has to do if it doesn't want
to be keyed by strings (and that option is given in Perl 6).
Luke
Re: == vs. eq
Luke Palmer wrote:
Luke Palmer:
# The first thing I noticed was the == / eq distinction. This
# has been invaluable for scripting, but since Perl 6 is
# desiring to be more of a formal language, I'm wondering
# whether the distinction is profitable.
[...]
Brent Dax:
Your desired standard sort of equality is provided by smartmatch.
$a ~~ $b
Don't get too hasty here, I actually did put some thought into this.
Smart match was not what I was thinking of.
[...]
# The solution that springs to mind is to conform to other
# languages' thought and make == polymorphically compare
# equality. Thanks to context-forcing, the string/numeric
# distinction is still there, at the expense of a little extra
# verbosity:
#
# +$a == +$b; # Numeric compare
# ~$a == ~$b; # String compare
# $a == $b; # Generic compare
Conciseness and precision are lost. What's gained?
Sorry, but how's precision lost here? As Luke points out, we'd free up
the eq operator to do more sophisticated comparisons like (deeply)
checking for identity of data structures.
Admittedly, this would be a major break with Perl5's idioms, especially
since eq would work the same in some situations in Perl6 as it did in
Perl5, but even ignoring that it'd be slower, it'd break in other
situations where joe average-scripter used it as (s)he used Perl5's eq
operator.
[...]
Steffen
--
@n=([283488072,6076],[2105905181,8583184],[1823729722,9282996],[281232,
1312416],[1823790605,791604],[2104676663,884944]);$b=6;@c=' -/\_|'=~/./g
;for(@n){for$n(@$_){map{$h=int$n/$b**$_;$n-=$b**$_*$h;[EMAIL PROTECTED]
0..11;[EMAIL PROTECTED],[EMAIL PROTECTED];[EMAIL PROTECTED]\n[EMAIL PROTECTED];
Re: == vs. eq
Luke Palmer writes: The solution that springs to mind is to conform to other languages' thought and make == polymorphically compare equality. No! Please! PHP tried this and gets it very wrong indeed (searching Google Groups for posts by me to this list containing the word PHP should throw up a detailed explanation/rant on the issue). Having both variables and operators being untyped leads to too much guessing -- and guessing wrongly. (It's a matter of opinion whether it's the language or the programmer who guesses wrongly ...) Thanks to context-forcing, the string/numeric distinction is still there, at the expense of a little extra verbosity: +$a == +$b; # Numeric compare ~$a == ~$b; # String compare $a == $b; # Generic compare But what does a 'generic' compare do? While Perl 6 has typed variables, I get the impression that these are most useful for efficiency reasons (especially for array and hash elements), and that it'll still be common -- especially in simple scripts -- to continue to use Perl-5-style scalar variables. This very often leads to variables that contain textual representation of numbers. Pretty much all input from files, the keyboard, databases, and from a web forms comes in as text even if its source considers it to be numeric. Likewise, in the programmer's mind such data is numeric. Doing a string comparison because it currently happens to be stored as a string is far too confusing. The other reason for not having unary C+ and C~ to force numeric or string context is the reason that Larry gave when we were discussing the bitwise operators. Somebody suggested that a single operator could do for both numeric and character operations, using these symbols on the operands to resolve ambiguities. Larry rejected the idea, on the grounds that operands can be arbitrarily complex expressions, and that can leave the C+ or C~ for the left operand a considerable distance from the operator on which it has an effect. Smylers
Re: == vs. eq
[EMAIL PROTECTED] (Smylers) writes: No! Please! PHP tried this and gets it very wrong indeed Don't be too hasty on the basis of one failure - Ruby tried it and got it very right indeed. In fact, Ruby has three types of equality/match operator, all slightly different, but most people only need two. Also, don't forget to distinguish between typed variables and typed values. I was under the impression that Perl 6 is going to have both. -- Last week I forgot how to ride a bicycle. -- Steven Wright
Re: == vs. eq
Smylers wrote: Thanks to context-forcing, the string/numeric distinction is still there, at the expense of a little extra verbosity: +$a == +$b; # Numeric compare ~$a == ~$b; # String compare $a == $b; # Generic compare But what does a 'generic' compare do? While Perl 6 has typed variables, I get the impression that these are most useful for efficiency reasons (especially for array and hash elements), and that it'll still be common -- especially in simple scripts -- to continue to use Perl-5-style scalar variables. This very often leads to variables that contain textual representation of numbers. Pretty much all input from files, the keyboard, databases, and from a web forms comes in as text even if its source considers it to be numeric. Likewise, in the programmer's mind such data is numeric. Doing a string comparison because it currently happens to be stored as a string is far too confusing. The other reason for not having unary C+ and C~ to force numeric or string context is the reason that Larry gave when we were discussing the bitwise operators. Somebody suggested that a single operator could do for both numeric and character operations, using these symbols on the operands to resolve ambiguities. Larry rejected the idea, on the grounds that operands can be arbitrarily complex expressions, and that can leave the C+ or C~ for the left operand a considerable distance from the operator on which it has an effect. Very well put. My solution sucks. However, my problem remains. What does the poor generic programmer do when he needs generic equality!? Particularly, what does Hash(keyed = Object) use? Maybe a method in object, or a multimethod? Called Csame or somesuch? Something just rings false about that :). To outline the problem again, even disregarding user-defined objects: Generic containers need a way to compare nums to nums and strings to strings and only get true when they actually are equal. The kind that the user overloads with his own user-defined type to say what it means to be equal. No magic. Ooh! And I came up with a good identity operator! :== (or =:= if you like symmetry). There's a beautiful parallel with := . $a = $b; $a == $b; # is always true $a := $b; $a :== $b; # is always true ($a =:= $b; # looks a little better) Luke
Re: == vs. eq
Luke Palmer [EMAIL PROTECTED] writes: However, my problem remains. What does the poor generic programmer do when he needs generic equality!? unfortunetly, no such thing exists. see: http://xrl.us/fdz and http://www.nhplace.com/kent/PS/EQUAL.html although the specifics are common lisp related the underlying ideas are equally valid to perl. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Re: == vs. eq
On Tue, Apr 01, 2003 at 03:30:46PM +0200, Marco Baringer wrote: Luke Palmer [EMAIL PROTECTED] writes: However, my problem remains. What does the poor generic programmer do when he needs generic equality!? unfortunetly, no such thing exists. see: http://xrl.us/fdz and http://www.nhplace.com/kent/PS/EQUAL.html although the specifics are common lisp related the underlying ideas are equally valid to perl. Thanks Marco! I was pondering what generic equality meant (thinking Luke knows something I don't) and having some difficulty until I read these links. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: == vs. eq
On Tue, Apr 01, 2003 at 03:22:33AM -0700, Luke Palmer wrote: [snip] Ooh! And I came up with a good identity operator! :== (or =:= if you like symmetry). There's a beautiful parallel with := . [snip] $a :== $b; # is always true ($a =:= $b; # looks a little better) I like =:= as identity operator if we want one. If not, as long as .id returns something that compares properly with both == and eq, I'm happy. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: == vs. eq
On Tuesday, April 1, 2003, at 06:59 AM, Jonathan Scott Duff wrote: On Tue, Apr 01, 2003 at 03:22:33AM -0700, Luke Palmer wrote: ($a =:= $b; # looks a little better) I like =:= as identity operator if we want one. If not, as long as .id returns something that compares properly with both == and eq, I'm happy. Agreed, =:= is nice looking. As I said before, I would strongly doubt that there will be an .id method _at all_ on any builtin types/classes -- because unless we used memory location as the id, it would imply that a separate id had to be calculated and stored with each object, which would be expensive, and if we _did_ use mem location as the id, getting and storing the id would be largely useless, since it could change unpredictably. So I would imagine it _is_ possible to test that two values have the same identity, but I would imagine it is -not- possible to actually get what that identity is. There's no .id method, per se, unless you create one yourself. As to whether we want on identity op, the only purpose would be when building your own classes, so that string, numeric, smartmatch, and true identity comparisions could be overloaded separately. We'd almost certainly have identical mean points to the same object in memory, as opposed to the fuzzier matching of the other variants. Which sounds like a very good idea to me. We've talked about this before, and let it drop. We should decide... well, we should encourage the deciders to decide. Myself, I strongly vote for -no- .id function, but for an identity-test operator separate from ==, eq, and ~~. Called C=:= MikeL
Re: == vs. eq
On Tue, 1 Apr 2003, Michael Lazzaro wrote: As I said before, I would strongly doubt that there will be an .id method _at all_ on any builtin types/classes -- because unless we used memory location as the id, it would imply that a separate id had to be calculated and stored with each object, which would be expensive, and if we _did_ use mem location as the id, getting and storing the id would be largely useless, since it could change unpredictably. So I would imagine it _is_ possible to test that two values have the same identity, but I would imagine it is -not- possible to actually get what that identity is. There's no .id method, per se, unless you create one yourself. What about the \ (reference) operator? If you take two references to an object, they should compare the same, right? ~ John Williams
Re: == vs. eq
On Tuesday, April 1, 2003, at 10:35 AM, John Williams wrote: On Tue, 1 Apr 2003, Michael Lazzaro wrote: So I would imagine it _is_ possible to test that two values have the same identity, but I would imagine it is -not- possible to actually get what that identity is. There's no .id method, per se, unless you create one yourself. What about the \ (reference) operator? If you take two references to an object, they should compare the same, right? In theory, I would think so. But in P6 practice, that might not be as useful as it sounds: my @a; my @b := @a; # bind @b same as @a [EMAIL PROTECTED] == [EMAIL PROTECTED]; # true, but not for the reason you think! @a =:= @b; # true, are bound to the same array Note if we are truly strict about C== always meaning compare numerically, I imagine that the line: [EMAIL PROTECTED] == [EMAIL PROTECTED]; would in fact be identical to _this_ line: @a.length == @b.length;# or whatever it's called or even just: @a == @b; ...which is probably not at all what you meant when you tried to compare [EMAIL PROTECTED] == [EMAIL PROTECTED] Likewise, if you attempt to store the numerified reference of something, in hopes of using it later as an identifier: my num $id = [EMAIL PROTECTED]; You would be in for a world of hurt. That line would actually set $id to the number of elements in @a -- at least, I hope it would: my $x = @a; # stores a reference to @a my $x = [EMAIL PROTECTED]; # same thing my int $x = @a; # stores length of @a my int $x = [EMAIL PROTECTED]; # same thing So I don't think comparing references would do what you wanted, for arbitrary (non-scalar) objects. Or rather, I don't think it'll be easy to get at a numeric representation of a reference ... a true 'identity' test might be a better approach.[*] (?) MikeL [*] (Also, any identity test that relies on numerification or other transformation of the comparators is doing a lot of unnecessary work.)
Re: == vs. eq
[EMAIL PROTECTED] (Luke Palmer) writes: I don't know what the official (this week) policy is, but I think it's a bad idea for references to auto-dereference. keys %$hash_r would bore me compared to keys $hash_r, since 'keys' can easily know that it wants a hash; in fact, I thought that autodereferencing of references in this way was something that was guaranteed from early on. I seem to remember hacking it into the Perl 6 emulator, as was.. -- The bad reputation UNIX has gotten is totally undeserved, laid on by people who don't understand, who have not gotten in there and tried anything. -- Jim Joyce, former computer science lecturer at the University of California
Re: == vs. eq
Luke Palmer wrote: As much as I don't want to refute my own operator, I agree with you here. I don't know what the official (this week) policy is, but I think it's a bad idea for references to auto-dereference. The other way around is fine, though (arrays auto-referencizing). I'm pretty darn sure they autodereference... we last talked about this when we were trying to determine how an arrayref would behave when interpolated into a string literal (answer: just like the original array would). Here's the relevant message: On Fri, Dec 06, 2002, Larry Wall wrote: On Fri, Dec 06, 2002, Dan Sugalski wrote: : If an aggregate and a reference to an aggregate are going to behave : the same, which is what Larry's indicated in the past, then : stringifying a reference should be the same as stringifying its : referent. This is a bit of an oversimplification. $foo and @foo do not always behave the same, even if $foo and @foo refer to the same array object. In particular, $foo doesn't behave like @foo in a list context. snip But it's probably fair to say that $foo and @foo always behave identically in a scalar context. So I *really* don't think comparing the equality of references will be a good idea, in P6. :-) John Williams wrote: You're right, but personally, I have come to trust eq more that == when comparing things-which-might-not-be-numbers, such as references. [EMAIL PROTECTED] eq [EMAIL PROTECTED];# true, for the reason I think # (the string-representation of the refs are equal) I'm pretty sure that breaks too, for the same reason. It puts both sides in string context, which causes both sides to return the string representation of the underlying array, _not_ the string representation of the references themselves. MikeL
Re: == vs. eq
On Tue, 1 Apr 2003, Miko O'Sullivan wrote: =:= is a generic comparison operator that simply calls the value_for_comparison method of the objects on left and right. If they both return the same string, then the expression returns true, else it ^^ returns false. If they don't have that method, that's a fatal error. Their value_for_comparison() methods must have been defined in the same class, otherwise you're comparing apples and oranges. (Yes, I'm sure we can think of a better name than value_for_comparison.) I propose the name str for the value_for_comparison method, and eq for the generic comparison operator. That's how my objects will work, anyway. ~ John Williams
Re: == vs. eq
One thing we should clear up is that we already *have* a generic comparator, C~~, depending on what you mean by generic. It can be made to compare things however you like, according to whatever standard of similarness you decide you want to enforce, and can even compare objects of disparate types (if you tell it how.) The way I personally have been envisioning this working is: $a == $b; # compares numerifications of $a and $b $a eq $b; # compares stringifications of $a and $b $a ~~ $b; # tests equality of $a and $b $a =:= $b; # tests identity of $a and $b Of these, I would expect that ==, eq, and =:= would almost never be overloaded, because they have very specific meanings.[*] You _could_ choose to override those == and eq for a particular custom class, and use those for comparing equality of objects. But since some people will tend to want to override ==, and some will want to override eq, it's not clear that the Perl6 community will converge on using only one or the other, which might make things quite confusing if you're using a library that has standardized on the opposite convention from your own. ~~, on the other hand, is meant to be overloaded to a possibly-excruciating extent, and I've been assuming that it will be the thing that classes most often overload when they want to test equality of two arbitrary objects, without resorting to serializing them via num/str. (Using num/str comparisions to test for object equality obviously only works if num/stringifying _completely_ serializes the object -- which very often is _not_ what you want the num/stringification of an object to do, by default.) The proposed =:=, however, merely tests that two objects are identical -- that is, _that they are bound to the same underlying thing_. It's possible for two objects to be equal, ~~wise, without actually being identical, identitywise. I don't see ever wanting to overload =:=, and it's unclear if it should even be allowed. Note also that == and eq comparisions are naturally accompanied by greater-than, less-than variants. But ~~ and =:= don't really have those variants, because they wouldn't make much sense. Having said all that, it should be noted that I'm completely making this stuff up. MikeL [*] By 'overloading', I mean multimethod variants. The comparision operators are almost certainly accomplished via multimethods, $a and $b being the two invocants.
