[seqfan] Rif: Factorials (A000142) "compressed" through the int data type

john.mason at lispa.it john.mason at lispa.it
Fri Jun 30 09:16:50 CEST 2017


In Java, use : import java.math.BigInteger;
john
__________________________________





Da:     Alonso Del Arte <alonso.delarte at gmail.com>
Per:    Sequence Fanatics Discussion list <seqfan at list.seqfan.eu>
Data:   29/06/2017 23:43
Oggetto:        [seqfan] Factorials (A000142) "compressed" through the int 
data type
Inviato da:     "SeqFan" <seqfan-bounces at list.seqfan.eu>



One of the things we take for granted in Maple and Mathematica is that
integers can be arbitrarily large. There are practical limitations, of
course, but in those programs we can deal with larger numbers than in
BASIC, FORTRAN, Pascal, etc., without having to worry about overflows and
such things.

I'm taking a Java course. The instructor told one of my classmates that a
function can't call itself. I suppose that's proper at this point in the
class, no pun intended. But it got me thinking about the classic example 
of
the function that calls itself, the factorial function implemented
recursively.

  public static int factorial(int n) {
    if (n > 0) {
      return n * factorial(n - 1);
    } else {
      return 1;
    }
  }

It works up to 12! But for 13! the overflow should trigger some kind of
runtime error and stop program execution, right? It doesn't.

1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880, 3628800, 39916800,
479001600, 1932053504, 1278945280, 2004310016, 2004189184, -288522240,
-898433024, 109641728, -2102132736, -1195114496, -522715136, 862453760,
-775946240, 2076180480, -1853882368, 1484783616, -1375731712, -1241513984,
1409286144, 738197504, -2147483648, -2147483648, 0, 0, 0, 0, 0, 0, 0, 0, 
0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, BUILD SUCCESSFUL (total time: 1 second)

Of course there are larger data types that can be chosen, but that only
postpones the inevitable overflow.

Somehow it makes sense to me that this says 32! = 0. And it also makes
sense that there are negative values for 17! and 18! and a few more after
that.

But I'm not understanding how the overflow from 13 * 12! gives 1932053504.
I'm hoping someone here can give some insight on this.

Al

-- 
Alonso del Arte
Author at SmashWords.com
<https://www.smashwords.com/profile/view/AlonsoDelarte>
Musician at ReverbNation.com <http://www.reverbnation.com/alonsodelarte>

--
Seqfan Mailing list - http://list.seqfan.eu/



More information about the SeqFan mailing list