[sage-support] power function with runtime error

[bb]

sage: 2^3^4^5
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)

/home/bb/sage-4.3.5/<ipython console> in <module>()

/home/bb/sage-4.3.5/local/lib/python2.6/site-packages/sage/rings/integer.so
in sage.rings.integer.Integer.__pow__ (sage/rings/integer.c:12114)()

RuntimeError: exponent must be at most 9223372036854775807
sage: float(2^3^4^5)
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)

/home/bb/sage-4.3.5/<ipython console> in <module>()

/home/bb/sage-4.3.5/local/lib/python2.6/site-packages/sage/rings/integer.so
in sage.rings.integer.Integer.__pow__ (sage/rings/integer.c:12114)()

RuntimeError: exponent must be at most 9223372036854775807
sage: long(2^3^4^5)
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)

/home/bb/sage-4.3.5/<ipython console> in <module>()

/home/bb/sage-4.3.5/local/lib/python2.6/site-packages/sage/rings/integer.so
in sage.rings.integer.Integer.__pow__ (sage/rings/integer.c:12114)()

RuntimeError: exponent must be at most 9223372036854775807
sage:

I get a runtime error, but just would expect infinity! Is there
something wrong or any explanation?

This works:
sage: 2^3^4^2
and results in a huge number!


Tnx & Regards BB

--
To post to this group, send email to sage-s...@googlegroups.com
To unsubscribe from this group, send email to sage-support...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-support
URL: http://www.sagemath.org

[Mike Hansen]

On Mon, Apr 19, 2010 at 11:52 AM, bb <bbl...@arcor.de> wrote:
> I get a runtime error, but just would expect infinity! Is there something
> wrong or any explanation?

This is because when you do 2^3^4^5 you are computing that number
exactly as an integer, and that number is definitely not infinity. If
you wanted to use floating point arithmetic, then you should start
with something like 2.0:

sage: 2.0^3^4^5
+infinity

Doing something like float(2^3^4^5) computes 2^3^4^5 as an integer and
then tries to convert that to a float.

Also, note that when you type in such an expression, the operations
are done in the following manner:

var(sage: var('x, y, z')
(x, y, z)
sage: x^y^z
x^(y^z)

which is different than

sage: (x^y)^z
(x^y)^z

Since exponentiation is non-associative, you need to be careful with
such differences.

--Mike

[bb]

bb schrieb:

With another input Sage can do the job.
sage: ((2^3)^4)^5
1152921504606846976
sage:
The same with maxima! maxima crashes without parenteses.
I did some experiments with different systems with the statement with
FreeMat:

--> 2^3^4^5

ans =

0

-->

I wonder about the last result? I would expect infinity or such a thing.
It works this way:

--> ((2^3)^4)^5

ans =

1152921504606846976

-->

Something strange happens with this:

--> 2^3^4

ans =

2,4179e+24

--> 2^3^4^3

ans =

0

--> 2^3^4^2

ans =

inf

-->

One might calculate with another calculator, that 2^3^4 should give 4096.

In Octave I get the following:

octave3.2:15> 2^3^4^5
ans = 1.1529e+18
octave3.2:16>

Maxima crashes and ends the program unexpected with an error message.
Maxima as well can handle it in this expression:
(%i1) ((2^3)^4)^5
;
(%o1) 1152921504606846976
(%i2)


Regards BB

The exponent will be set high by the Mail-Program!

[bb]

Mike Hansen schrieb:

> On Mon, Apr 19, 2010 at 11:52 AM, bb <bbl...@arcor.de> wrote:
>
>> I get a runtime error, but just would expect infinity! Is there something
>> wrong or any explanation?
>>
>
> This is because when you do 2^3^4^5 you are computing that number
> exactly as an integer, and that number is definitely not infinity. If
> you wanted to use floating point arithmetic, then you should start
> with something like 2.0:
>
> sage: 2.0^3^4^5
> +infinity
>
> Doing something like float(2^3^4^5) computes 2^3^4^5 as an integer and
> then tries to convert that to a float.
>
> Also, note that when you type in such an expression, the operations
> are done in the following manner:
>
> var(sage: var('x, y, z')
> (x, y, z)
> sage: x^y^z
> x^(y^z)
>
> which is different than
>
> sage: (x^y)^z
> (x^y)^z
>
> Since exponentiation is non-associative, you need to be careful with
> such differences.
>
> --Mike
>
>

Thank you for your answer! I think there is a fundamental question left
apart from the question of assoziativity/non-assoziativity. There Sage
(I think coming from python) does not follow the common rule to evaluate
an expression with operators of the same precedence from left tor right.

Since Georg Cantor there is a difference between countable infinity (in
the actual example) and noncountable infinity ( in the example
calculated with a float). I would not say, that infinity is wrong in
this case, only just because there is existing an infinite set of
integers so that infinity never might be reached. (I think that is the
line of argument of your explanation?) The essential point is, one has
to map the unlimited ideas of math to the restricted possibilities of a
computer.

From a mathamatical point of view one can call the result of the
calculation

sage: 2^(3^(4^5))

---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)

/home/bb/sage-4.3.5/<ipython console> in <module>()

/home/bb/sage-4.3.5/local/lib/python2.6/site-packages/sage/rings/integer.so
in sage.rings.integer.Integer.__pow__ (sage/rings/integer.c:12114)()

RuntimeError: exponent must be at most 9223372036854775807
sage:

just a bug! Infinity is infinity, if countable or not countable. The
correct math-answer only could be countable infinity! But I think
infinity would in any case be better than "RuntimeError" as an answer!

May be one might introduce a new constant "countable infinity"? Anyway,
I only can recommend the Sage people to catch/raise an exception to
handle that case of an integer overflow of an exponent and avoid the
landing in the mathematical "nirvana" of a RuntimeError. If one thinks
about that problem, one might find that any integer overflow of an
exponent always ends in contable infinity in due consideration of the
computer limits.

Regards BB

[Robert Bradshaw]

The exponentiation operator is a common exception to the left-to-right
rule. This is probably because a^(b^c) is more useful than (a^b)^c =
a^(b*c). Magma, Mathematica, and even bc follow the right-to-left rule
for exponentiation. (Maple actually raises an error if you don't have
the parenthesis.)

> Since Georg Cantor there is a difference between countable infinity
> (in the actual example) and noncountable infinity ( in the example
> calculated with a float). I would not say, that infinity is wrong in
> this case, only just because there is existing an infinite set of
> integers so that infinity never might be reached.

The infinity given here has nothing to do with set cardinalities, it
is better understood as the compactification of the real line.

> (I think that is the line of argument of your explanation?) The
> essential point is, one has to map the unlimited ideas of math to
> the restricted possibilities of a computer.
>
> From a mathamatical point of view one can call the result of the
> calculation
>
> sage: 2^(3^(4^5))
> ---------------------------------------------------------------------------
> RuntimeError Traceback (most recent
> call last)
>
> /home/bb/sage-4.3.5/<ipython console> in <module>()
>
> /home/bb/sage-4.3.5/local/lib/python2.6/site-packages/sage/rings/
> integer.so in sage.rings.integer.Integer.__pow__ (sage/rings/
> integer.c:12114)()
>
> RuntimeError: exponent must be at most 9223372036854775807
> sage:
>
> just a bug! Infinity is infinity, if countable or not countable. The
> correct math-answer only could be countable infinity! But I think
> infinity would in any case be better than "RuntimeError" as an answer!

I strongly disagree--infinity is an approximation to very large
numbers, not an exact answer. This is fine for floating point numbers
where one is only working with approximations to real numbers anyways,
but integer arithmetic is supposed to be exact. The error above is
desirable, as it tells you it can't to the computation because it
can't represent the result in memory (in particular, no one I know has
a place to store all 9223372036854775807 x 8 bytes of the answer).

- Robert