Re: == vs. eq

2003-04-05 Thread Tom Christiansen
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

Re: == vs. eq

2003-04-05 Thread Matthijs van Duin
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

Re: == vs. eq

2003-04-05 Thread Matthijs van Duin
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

Re: == vs. eq

2003-04-05 Thread Steffen Mueller
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

Re: == vs. eq

2003-04-05 Thread Tom Christiansen
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

Re: == vs. eq

2003-04-05 Thread Tom Christiansen
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

Re: == vs. eq

2003-04-05 Thread Tom Christiansen
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

Re: Ruminating RFC 93- alphabet-blind pattern matching

2003-04-05 Thread Larry Wall
Um. Maybe it was just bad writing on my part, but it does not seem to me that what I already said about RFC 93 in A5 has sunk in at all. Larry

Re: Short-circuiting user-defined operators

2003-04-05 Thread Larry Wall
On Tue, Apr 01, 2003 at 08:26:38PM -0500, Joe Gottman wrote: :Is there any way to write a user-defined operator so that it : short-circuits, like and || ? This might be function trait, for : instance, : : sub infix:!! ($lhs, $rhs) is short_circuit {...} Honestly, you guys. You make

Re: == vs. eq

2003-04-05 Thread Larry Wall
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

Re: == vs. eq

2003-04-05 Thread Larry Wall
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 :

Have you tried using the accelerator?

2003-04-05 Thread Luke Palmer
Maybe it's time to pick this list up again. It seems the last thing that happened is that Mike started the Arrays/Hashes section. That was two months ago. What's the next thing up? Chapter 2 of the camel seems to think that typeglobs^Wfilehandles come next. IIRC, we haven't covered context