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 ~~give~~give:

```
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.

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.