Revision history [back]
 | 1 | initial version |
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.
| | 2 | No.2 Revision |
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.
