# Intbv arithmetic operations return types

#1

Is there any particular reason why adding or subtracting `intbv`s return `int`s, but anding, shifting etc return `intvb`s?

#2

The reason could be that adding and subtracting (and alike) are arithmetic operations, where anding, shifting e.a. are bitwise logical operations.
But in all cases the result of the operation is used in an assignment and thus the actual integer value will be used. Making the promotion of the integer result of the bitwise logical operations to `intbv` superfluous.

#3

There is an old thread, on the old mailing-list, discussing this topic. I had tested returning `intbv` in all cases, it had a performance impact - at that time it was decided not to use `intbv` in all cases. I don’t recall the arguments for and / or against, just that in the past it was proposed to use `intbv` as all returns and it was, at that point in time, decided against.

#4

#5

Here is the thread (I believe) and the rational:
https://sourceforge.net/p/myhdl/mailman/message/22137406/

(gmane is down?)

#6

@cfelton Thanks for enlightening me (us?), I didn’t think of slicing of/indexing the result. But then we should never make a distinction between arithmetic and logical operators?

#7

@cfelton I ran into the case this morning …

``````movingxpattern[i].next = ((xcounter.Q << SHIFT_PIX) + ycounter.Q + i)[WIDTH_PIXEL:]
``````

throws an exception: AttributeError: ‘Subscript’ object has no attribute ‘vhd’, obviously because I’m trying to slice an integer. The work-around:

``````movingxpattern[i].next = ((xcounter.Q << SHIFT_PIX) + ycounter.Q + i) & (2 ** WIDTH_PIXEL - 1)
``````

is fine.

#8

That’s good to know. It seems like an arbitrary choice made for performance reasons. Perhaps we should document it?