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!
