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

Brad Klee bradklee at gmail.com
Fri Jun 30 05:21:07 CEST 2017


Words of wisdom, and some simple code from:

> https://stackoverflow.com/a/3394634
>> https://www.gnu.org/software/bc/manual/html_mono/bc.html
>> https://ptpb.pw/jl4F

In this case the terminal is good enough, no Java-GUI needed. Compare the
pasted terminal session output with b-files for A027868 & A027869. At least
these two preliminary checks pass. And I notice that the entry for A027869
employs no FOSS implementation. The following seems to work for me:

~Terminal~
[bklee at seabiscuit OEIS]$ cat A027869Code

#!/bin/bash
for Z in {0..30};do
echo -n ${Z}" ";
echo "define f(x) {if (x>1){return x*f(x-1)};return 1}
           f(${Z})" | bc | grep -o "0" | wc -l
done;

[bklee at seabiscuit OEIS]$ ./A027869Code

0 0
1 0
2 0
3 0
4 0
5 1
6 1
7 2
8 2
9 1
10 2
11 2
12 4
13 4
14 2
15 4
16 4
17 4
18 5
19 6
20 7
21 7
22 8
23 5
24 6
25 9
26 8
27 9
28 10
29 7
30 9
~End Terminal~

Do any of the OEIS entries have program code using "bc" ? A027869 doesn't
yet. Maybe A160106 or A143936, both from Lewis Mammel.

Thanks,

Brad


On Thu, Jun 29, 2017 at 9:43 PM, Alonso Del Arte <alonso.delarte at gmail.com>
wrote:

> 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