When doing power operation issue encountered TypeError: '<' not supported between instances of 'str' and 'int'

[timbrist]

TypeError: '<' not supported between instances of 'str' and 'int'

code:
import numexpr as ne
A = 10
B = 2
print(ne.evaluate("A**B"))

[robbmcleod]

This is a point where I'm unsure what the intention of the original authors was with regards to the attribute .value on these ExpressionNode objects. Because the 'value' is the variable string, 'a' and 'b' here. So there's a lot of the short-circuit code that shouldn't work in this case, because they clearly expect it to be an actual numerical value.

The documentation for ASTNode, which is not connected to ExpressionNode, seems to suggest that value is a mutable type.

class ASTNode(object):
    """Abstract Syntax Tree node.

    Members:

    astType      -- type of node (op, constant, variable, raw, or alias)
    astKind      -- the type of the result (bool, float, etc.)
    value        -- value associated with this node.
                    An opcode, numerical value, a variable name, etc.
    children     -- the children below this node
    reg          -- the register assigned to the result for this node.
    """

So, yeah, unsure how this code was intended to work. I might need to go way back in Git to guess.

[timbrist]

This is a point where I'm unsure what the intention of the original authors was with regards to the attribute .value on these ExpressionNode objects. Because the 'value' is the variable string, 'a' and 'b' here. So there's a lot of the short-circuit code that shouldn't work in this case, because they clearly expect it to be an actual numerical value.

The documentation for ASTNode, which is not connected to ExpressionNode, seems to suggest that value is a mutable type.

class ASTNode(object):
    """Abstract Syntax Tree node.

    Members:

    astType      -- type of node (op, constant, variable, raw, or alias)
    astKind      -- the type of the result (bool, float, etc.)
    value        -- value associated with this node.
                    An opcode, numerical value, a variable name, etc.
    children     -- the children below this node
    reg          -- the register assigned to the result for this node.
    """

So, yeah, unsure how this code was intended to work. I might need to go way back in Git to guess.

Hi robmcleod,
Thank you for the reply, I wasn't planing to dig too much at first, but your reply encourage me to run the source code;

I have debug a little, the attribute .value is supposed to link to .astKind but somehow .value is str, the astkind is forgotten to change;

well I only add a condition and solve the problem; I will also go further to check the mechanism

[timbrist]

things are really bad, I have understood the intention of the power function
the condition to raise ValueError() is a numpy nagative error

https://stackoverflow.com/questions/43287311/why-cant-i-raise-to-a-negative-power-in-numpy

but as I dig more, things go bad as following example;

if the b is a constant node, then we can raise the error here

but if y is a the expression, we can not access the variable at this function

[robbmcleod]

I think in terms of having negative numbers in arrays we probably just have to accept the behaviour of the C++ virtual machine (which outputs zero if the exponent is a negative integer).

The problem is these code shortcuts for singletons. The simplest answer may simply be to remove the shortcuts. They're not very helpful from a performance perspective because the typical use case is when people are using NumExpr as a parser. IIRC, it takes about 1 ms to spin up the virtual machine in 2.X.

[timbrist]

I don't know whether the owner will see this issue.
since I didn't have the push permission, I will stop here

I believe that numpy Error should not be handle in pow_op(a,b) ;
And we have to accept the fact that x**-2, if x is a integer(number or vector) then answer is 0;

[timbrist]

I think in terms of having negative numbers in arrays we probably just have to accept the behaviour of the C++ virtual machine (which outputs zero if the exponent is a negative integer).

The problem is these code shortcuts for singletons. The simplest answer may simply be to remove the shortcuts. They're not very helpful from a performance perspective because the typical use case is when people are using NumExpr as a parser. IIRC, it takes about 1 ms to spin up the virtual machine in 2.X.

Thanks for the reply, I spent hours on this and you are right we just need to accept the behavior of the C++ virtual machine.

[robbmcleod]

Closing with release of 2.8.5.