Re^5: Infinity and Inf? (MAX

> You are mistaken.

did you read my updates before answering?

> That limit be obtained using the following:

I question these design decisions forcing the user to care about such implementation details.

From a higher language perspective it doesn't make sense why a range operator within a for(..){} can't iterate thru the same spectrum like a while($x++){ } can do.

IMHO the cleanest syntax would be allowing to use Inf which is automatically translated to whatever maximum the current implementation of an operator can handle.

Cheers Rolf

Comment on Re^5: Infinity and Inf? (MAX_INT) Select or Download Code

Replies are listed 'Best First'.
Re^6: Infinity and Inf? (MAX_INT) by ikegami (Patriarch) on Sep 01, 2010 at 19:16 UTC
I question these design decisions forcing the user to care about such implementation details. Which users are those? Very few will ever needed to iterate over numbers greater than 2,147,483,648, and very few will ever need to iterate over numbers greater than 9,223,372,036,854,775,807 (64-bit builds). It's a compromise between resources and utility. Only using integers internally is faster, requires less memory and requires less code than supporting both integers and floats. the cleanest syntax would be allowing to use Inf If we pretend that `for` to take a lazy list, you'll complain that it doesn't make sense for `map` not to, from a higher language perspective. Mind you, I think `for ($x..Inf)` has merit. for(..){} can't iterate thru the same spectrum like a while($x++){ } can do. If you think the range op has a seemingly arbitrary limit, you should see ++'s! For example, 1e16 to 1e16 is ok, but 1e16 to 1e16+1 isn't. `$ perl -E'for (my $_ = 1e16; ; ++$_) { say }' 1e16 1e16 1e16 1e16 ...` [download] Update: Mixed $x and $_ in last snippet. Fixed.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^6: Infinity and Inf? (MAX_INT)
by ikegami (Patriarch) on Sep 01, 2010 at 19:16 UTC

I question these design decisions forcing the user to care about such implementation details.

Which users are those? Very few will ever needed to iterate over numbers greater than 2,147,483,648, and very few will ever need to iterate over numbers greater than 9,223,372,036,854,775,807 (64-bit builds).

It's a compromise between resources and utility. Only using integers internally is faster, requires less memory and requires less code than supporting both integers and floats.

the cleanest syntax would be allowing to use Inf

If we pretend that for to take a lazy list, you'll complain that it doesn't make sense for map not to, from a higher language perspective.

Mind you, I think for ($x..Inf) has merit.

for(..){} can't iterate thru the same spectrum like a while($x++){ } can do.

If you think the range op has a seemingly arbitrary limit, you should see ++'s! For example, 1e16 to 1e16 is ok, but 1e16 to 1e16+1 isn't.

$ perl -E'for (my $_ = 1e16; ; ++$_) { say }'
1e16
1e16
1e16
1e16
...
[download]

Update: Mixed $x and $_ in last snippet. Fixed.

[reply]
[d/l]
[select]