TL;DR

Your supposed "exact value of pi" that you were comparing against was not exact. It was only correct up to decimal 15. In fact, the value of pi that your loop computed was more correct (and therefore departed from the value of math.piafter decimal 15).

However, the algorithm you use to compute pi has serious stability problems from a point. [See final extension for a possible solution]

Understand Decimal

First of all, the type Decimal()is not a miracle formula. When you convert a floatto Decimalyou're not going to instantly get more precision than the floatinput had. For example, if you ask him to represent the quantity 3.14 with 51 decimal places, you will not get more decimals of pi, moreover, you will not even get 3.1400000...00000 (49 zeros) but

>>> print(decimal.Decimal(3.14))
3.140000000000000124344978758017532527446746826171875

As you can see, "rare" decimals appear after a point. Those decimals were already there in number 3.14 because its binary representation has infinite decimals, and since saving it to floatthat truncates, you're making a mistake. In other words, when you do a = 3.14(type float), the number that is actually stored in ais an approximation of 3.14 (and specifically, the approximation shown above).

To avoid these rounding errors you should not pass a floatto the constructor of Decimal(), but a string. If we do Decimal("3.14"), then yes, the stored value will be exact:

>>> print(decimal.Decimal("3.14"))
3.14
# Almacena en realidad
# 3.140000000000000000000000000000000000000000000000000

Although it doesn't show non-significant zeros at print time, they are actually correctly stored within the Decimal representation.

I say all this because you start with:

pi2 = Decimal(math.pi)

and you consider this variable to be "the exact value of pi", but it is not since it has been generated from the fact math.pithat it is an approximation valid only up to decimal 15, since it is a floating point number that has inherent errors as already explained here

Compare the value of pi2to a more exact value generated by Wolfram Alpha to decimal 65:

Exacto con 65 cifras: 3.141592653589793 23846264338327950288419716939937510582097494459231
    Decimal(math.pi): 3.141592653589793 115997963468544185161590576171875

Some additional details about your program

In your program you have several decimal.Decimal()that could be eliminated.

For example left over here:

x1 = decimal.Decimal(Decimal(2)+a).sqrt()

which can be shortened to:

x1 = (a+2).sqrt()

since it awas already of type Decimal, so it a+2will also be Decimal(python will convert 2to Decimal, exactly because it is an integer, and do the addition). Since the result is a Decimal()and we apply the method .sqrt()of the Decimal(), the result of that root will in turn be another Decimal()that we can assign to x1directly, without having to convert it back toDecimal()

Running your corrected program

We are going to execute a simplified version (removing the decimal.Decimal()superfluous) in which we compare ourselves with the "true" value of pi, at least up to the number 65, which is what we have obtained from Wolfram Alpha

This is the program:

# @title pi
import math
from decimal import Decimal
import decimal

decimal.getcontext().prec = 65

a = Decimal(0)
valorN = 0
i = 3

pi = Decimal(0)
pi2 = Decimal("3.14159265358979323846264338327950288419716939937510582097494459231")

valorN = int(input('Ingrese el valor de n que sea mayor a 2 y menor a infinito: '))
a = Decimal(0)

while i <= valorN:
    x1= (2+a).sqrt()
    x = (2-x1).sqrt()
    y = Decimal(pow(2,i-1))
    pi = x*y
    a = (2+a).sqrt()
    i = i + 1 

print('El valor de pi es ')
print(pi)
# este es el valor real #
print (pi2)

When we run it for N=28 we get correct results up to decimal 15

Ingrese el valor de n que sea mayor a 2 y menor a infinito: 28
El valor de pi es 
3.141592653589793 1667462219700150778696165489637681660703093062077
3.141592653589793 23846264338327950288419716939937510582097494459231

But what did you expect? In 28 iterations of the algorithm that is the precision that has been achieved. If you want more precision, we can keep iterating. Let's try for example 35 iterations:

Ingrese el valor de n que sea mayor a 2 y menor a infinito: 35
El valor de pi es 
3.1415926535897932384 582661602928534441638628573935649839361286949
3.1415926535897932384 6264338327950288419716939937510582097494459231

As we can see, the precision has improved so that we now have 19 correct decimal places (which is already more than we could have in a float).

It happens that N iterations does not give you N correct decimal places. The algorithm does not converge that fast. To achieve 19 decimal places you must iterate 35 times. But from a point on, continuing to iterate no longer improves the result. In fact it makes it worse!

The problem with this approach

This is not a good mechanism for finding decimals of pi, as it is unstable. As you iterate, it x1's getting closer to 2, so it 2-x1's getting closer to zero, and so xtoo.

In fact, there comes a time when the 65 decimal places are not enough to save x(which would be less than 10^-65) and its value is truncated to zero. From that point everything fails, because if it xis zero, it will also be zero x**yand therefore suddenly your approximation of pi becomes zero.

This happens relatively soon (for n=110). But well before that happens, important errors appear in the computation of x**y, since it xwill take very small values, while it ywill take very large values ​​(powers of 2). On small values ​​of xthere is an error because we are truncating it at its decimal 65, and that error is amplified by raising it to y. The result is that before the "catastrophe" occurs that causes it to pigo to zero, the previous approximations were getting worse and worse instead of being better and better.

For example, for n=105the approximation pithat came out was:

Ingrese el valor de n que sea mayor a 2 y menor a infinito: 105
El valor de pi es 
3.14 21373846360117824379164873499126756724026658776749425705467686
3.14 15926535897932384626433832795028841971693993751058209749445923

Take! It is wrong already from the third decimal!

It seems then that as we increase N we get closer to pi, but only up to a point from which we move away again due to the errors caused because it xis very very small and does not fit in 65 decimal places, until finally the error is already catastrophic because our pi is zero.

final curiosities

As a curiosity I have made a graph of the absolute error made (difference between the approximation of pi and its "true" value) as we increase N (loop iterations):

I have used logarithmic scale on the Y axis. We see how up to N approximately equal to 53 things went well. The error was reducing exponentially, but from there things went wrong. Rounding errors due to instability x**ycaused the error to grow again (irregularly, somewhat chaotically), until reaching an error equal to 3.1415... when piit becomes 0 (and from that point the error it already stays at 3.1415.. because every subsequent iteration of the loop produces pi = 0.

For N=53, the best approximation of all is produced, which is the following:

Ingrese el valor de n que sea mayor a 2 y menor a infinito: 53
El valor de pi es 
3.141592653589793238462643383279 4390490856382359047953080772238233
3.141592653589793238462643383279 5028841971693993751058209749445923

Correct up to decimal 30.

I have painted another graph that shows how many correct digits the approximation has as you increase valorN. Is the next:

Where it is seen again that the maximum is reached for N around 55 and also that up to that moment the progression is not linear. Sometimes going from N to N+1 increases the number of correct digits by 1, other times it doesn't. And from 55 the number of correct digits decreases, also "in jumps".

It therefore seems that with a precision of 65 you get correctly up to decimal 30. By increasing the precision you could get more correct decimals.

Extension

Apparently, based on some tests I've been doing, to get N digits correct, you have to work with a precision of at least 2*(N+3) (it's a heuristic I have no justification for). So, to correctly get 65 digits you should work with a precision of 136.

Instead of asking the user for the number of iterations to perform, we can automatically detect when to stop, and it will be when the value that comes out of piis equal to that of the previous iteration (from that point on the approximation would start to get worse).

So this would be the code:

import math
from decimal import Decimal
import decimal

valorN = int(input('Ingrese el valor de dígitos deseado: '))

# Trabajar con la precisión adecuada
decimal.getcontext().prec = 2*(valorN+3)

a = Decimal(0)
i = 3
pi = Decimal(0)
a = Decimal(0)

while True:
    piold = pi
    x1= (2+a).sqrt()
    x = (2-x1).sqrt()
    y = Decimal(pow(2,i-1))
    pi = x*y
    if piold==pi:
      break
    a = (2+a).sqrt()
    i = i + 1 

print(f"Detenido tras {i} iteraciones")
print('El valor aproximado de pi es ')
print(pi)
# este es el valor real con 65 digitos #
print("3.1415926535897932384626433832795028841971693993751058209749445923")

Execution result:

Ingrese el valor de dígitos deseado: 65
Detenido tras 116 iteraciones
El valor aproximado de pi es 
3.141592653589793238462643383279502884197169399375105820974944592307844062894732236752971209989019846026985971418316643805175816308465281
3.1415926535897932384626433832795028841971693993751058209749445923

Naturally the rest of the decimals that come out from position 65 would be wrong. We could truncate the result with:

print(str(pi)[:valorN+1])