# Revision history [back]

The first step in debugging is to look to see what the first argument actually is. I'm assuming that you did n = var("n") or something at some point. So we can get the first element:

sage: Pps = np.arange(103421.359,1013529,6895.75729)
sage: Pps[0]
103421.359
sage: Pp = Pps[0]
sage: Pp * Vt
144.05561095109999
sage: Pp * Vt == n
False
sage: Pp * Vt == n*r*t
False


.. and we see that Sage is automatically evaluating the expression, and since it can't prove that it's true -- which is good, because it's not true in general -- it's saying that it's False.

Ultimately this is because

sage: type(Pp)
<type 'numpy.float64'>


Pp is a numpy float, which doesn't interact too well with the Sage types. As soon as the __eq__ method of the float is called, the game's over. You can work around this in some fragile ways, such as flipping the order:

sage: n*r*t == Pp*Vt
2446.62193200810*n == 144.055610951
sage: solve(n*r*t == Pp*Vt, n)
[n == (52361895020038/889307677165161)]


But a better and more robust way would be to avoid getting numpy involved at all, and stick with Sage-native objects. For example, you can use srange and sxrange:

srange(start, end=None, step=1, universe=None, check=True, include_endpoint=False, endpoint_tolerance=1e-05)
Return list of numbers a, a+step, ..., a+k*step,
where a+k*step < b and a+(k+1)*step >= b over
exact rings, and makes a best attempt for inexact rings
(see note below).


which would give

sage: eng5= [solve(Pp*Vt == n*r*t,n) for Pp in srange(103421.359,1013529,6895.75729)]
sage: len(eng5)
132
sage: eng5[:3]
[[n == (52361895020038/889307677165161)], [n == (56778965120683/904048017111831)], [n == (74168281138961/1111449736506101)]]


Short version: don't use numpy unless you need to, and here you don't.

The first step in debugging is to look to see what the first argument actually is. I'm assuming that you did n = var("n") or something at some point. So we can get the first element:

sage: Pps = np.arange(103421.359,1013529,6895.75729)
sage: Pps[0]
103421.359
sage: Pp = Pps[0]
sage: Pp * Vt
144.05561095109999
sage: Pp * Vt == n
False
sage: Pp * Vt == n*r*t
False


.. and we see that Sage is automatically evaluating the expression, and since it can't prove that it's true -- which is good, because it's not true in general -- it's saying that it's False.

Ultimately this is because

sage: type(Pp)
<type 'numpy.float64'>


Pp is a numpy float, which doesn't interact too well with the Sage types. As soon as the __eq__ method of the float is called, the game's over. You can work around this in some fragile ways, such as flipping the order:

sage: n*r*t == Pp*Vt
2446.62193200810*n == 144.055610951
sage: solve(n*r*t == Pp*Vt, n)
[n == (52361895020038/889307677165161)]


But a better and more robust way would be to avoid getting numpy involved at all, and stick with Sage-native objects. For example, you can use srange and sxrange:

srange(start, end=None, step=1, universe=None, check=True, include_endpoint=False, endpoint_tolerance=1e-05)
Return list of numbers a, a+step, ..., a+k*step,
where a+k*step < b and a+(k+1)*step >= b over
exact rings, and makes a best attempt for inexact rings
(see note below).


which would givegive:

sage: s = srange(103421.359,1013529,6895.75729)
sage: len(s)
132
sage: s[:5]
[103421.359000000, 110317.116290000, 117212.873580000, 124108.630870000, 131004.388160000]


and then

sage: eng5= [solve(Pp*Vt == n*r*t,n) for Pp in srange(103421.359,1013529,6895.75729)]
sage: len(eng5)
132
sage: eng5[:3]
[[n == (52361895020038/889307677165161)], [n == (56778965120683/904048017111831)], [n == (74168281138961/1111449736506101)]]


Short version: don't use numpy unless you need to, and here you don't.