"Jeremy Howard" <[EMAIL PROTECTED]> writes:
> > Oops, a correction. [..] should mean 'the set of all integers'. _Not_ the
> > univeral set. So my code snippet should be:
> > @i = [..]; # @i contains the integers
> > $s = sum (grep 0<__<=100 @i);
> > print "The sum of the 1st 100 integers is: $s";
> >
> Oh dear, another correction! I meant, of course:
> @i = (..);
> not
> @i = [..];
>
> It just goes to prove that Sunday morning is a poor time to sit in front of
> a computer... Time to go outside!
This (and your preceeding messages on the subject) is unfortunately
not possible to do in a clean manner; for that matter, neither is the
(..0) proposal. The I<order> in which results are produced depends on
the order in which you generate the elements of (..). Since there's
no universally "good" order of the integers (do you take
0,-1,+1,-2,+2,...; or maybe 0, -1,-2, 1,2,3, -3,-4,-5,-6, 4,5,6,7,8;
or any other order), there's no way `grep' can generate the results in
the correct order. But this iterator B<is> an iterator; in
particular, you I<expect> a well-defined order.
As an example, consider this code (which uses some other language
extensions):
@ints = (..);
@threes = grep {(-100 <= $_ <= 100) && ($_ % 3 == 0)} @ints;
"Clearly", we should have in @threes the list
(-99,-96,...,0,3,...,96,99). The list is lazy, of course (so trying
to access elements after 99 is an infinite loop), but even so I see no
way of generating the elements in the correct order (for a general
grep predicate). So laziness "at the start" of the list means you can
never generate -99 as the first element, since there might be a
previous element!
So the best any language can do with the above code is generate some
permutation of (-99,...,99).
But as soon as you're specifying some well-ordering of the integers,
you might as well use C<@ints = map {well_order $_} (1..)>, where
well_order is a bijection of the natural numbers onto the integeers.
Note that the ordering is different than ...,-2,-1,0,1,2,...
Similarly, the only useful meaning of C<@negs = (..-1)> would simply
be C<@negs = map {-$_} (1..)>, and the ordering of the result is again
"wrong".
Somebody please prove me wrong by writing useful-looking code that
does not depend on the order of elements, and will work with this sort
of "disordered iterator"!
--
Ariel Scolnicov |"GCAAGAATTGAACTGTAG" | [EMAIL PROTECTED]
Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St. |Tel: +972-3-7658514 (Main office)`---------------------
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 http://3w.compugen.co.il/~ariels