Calc uses number type "double" and 7^19 is to large to be represented in 53 Bits. So the needed figures don't exist. I don't know whether Calc should produce an error, if the second argument of MOD is integral and the first argument is to large. (Teaching cryptography to pupils I introduce "PowerMod" then.)

For your spreadsheet the solution is to calculate it iterative.
Start with 1 in cell C1.
In cell C2 use the formula =MOD(C1*7;13)
In cell C3 use the formula =MOD(C2*7;13) and so on with drag fill.

.

Thanks for your help, but it's already too late. I didn't expect such an error because I used integers and some programming languages such as python have no problem with very big integers. In my opinion, there should be a sign for the user if a number gets too large (is this possible?).

(In reply to comment #1)
> Calc uses number type "double" and 7^19 is to large to be represented in 53
> Bits. So the needed figures don't exist. I don't know whether Calc should
> produce an error, if the second argument of MOD is integral and the first
> argument is to large. (Teaching cryptography to pupils I introduce "PowerMod"
> then.)
> 
> For your spreadsheet the solution is to calculate it iterative.
> Start with 1 in cell C1.
> In cell C2 use the formula =MOD(C1*7;13)
> In cell C3 use the formula =MOD(C2*7;13) and so on with drag fill.

Changed to low-enhancement to match 32834 (related by 32866) 
Low because happens to small set of users in integer functions applied to large values. Issue is very real for users requiring extended precision - in this case a mathematically sound workaround exists.  Integer ops on very large #s must eventually run afoul of the underlying implementation's precision limit.  
It is an Enhancement to consider either a different implementation or different action (err past limits) for integer operators/functions on very large or very tiny numbers in either Calc or BASIC.

for large numbers crunching, you must use mathematica, matlab or similar programs.
Calc (and Excel) are wrong decissions.

calc calculates correctly - in this case and within it's limitations, 

the 'double' representation of 7^19 is 11398895185373144,00 you can 'see' the digits hidden by calcs 'Standard' display format 1,13988951853731E+016
by '=RAWSUBTRACT(7^19;1,13988E+016)'

that's off by 1 from the correct value 11398895185373143, double-floats have a granularity of '2' in this range, thus the result of the mod calculation is off too, that's correct for calc, but not for users, 

to regain some harmony between the expectations of users - who think a computer for several thousand bucks should be able to calculate better than they themself - and the meager abilities of calc and ex$el, many ways would be possible, two come to my mind immediately: 

- calculation results should be provided with information how accurate - or inaccurate! - they are, and where one has to expect that the inaccuracy violates the expectations of users, a warning should be given! 

- tasks for which in principle exact results are possible but not directly reachable in fp-math should be calculated 'intelligently decomposed', e.g. in extension of @Regina's approach in c#2 one could calculate '=mod(7^19;13)' as '=mod(7^10;13) * mod(7^9;13)' - and take the whole again mod-13 as the product might be >=13, so '=mod(mod(7^10;13) * mod(7^9;13);13)',  that holds, 

to recognize the necessity of such decompositions and to initiate them intelligently is - automated - not trivial, but also not witchcraft, 

1st step i'd propose: each mathematical procedure is preceeded by a 'range-check' and if the operands exceed or fall below the range for which exact results are possible a warning is issued, 

2nd step: after that 'calculation tricks' can be added bit by bit which extend the capabilities of the procedures and are activated in case of 'off-range' instead of the warning, 

the actual solution in calc to compute and display '0' for such tasks is ... suboptimal ... user take that as a result instead of a warning