It doesn't seem like Eigen supports bitwise operations.
I would like bitwise SIMD functionality for "shift left" and "and".
Is there a quick and dirty way to implement this functionality? Can i call an intrinsic function and input it with something like Eigen vector.data()?
I think Eigen don't support this because that there isn't a good way to do this for float, double and complex numbers.
You can always override those C++ bitwise operators by yourself, taking two MatrixBase as parameters.
For bitwise assignment operators, you need to add a function inside MatrixBase class.
Eigen made this possible, see here how to.
Related
Given a double x, it is known that it is more efficient to use x*x instead of pow(x,2). Imagine for simplicity that we have to calculate the square root of x: as it is a unary operation, for this purpose we have sqrt(x). Now, also raising x to the second power is a unary operation, but we have nothing like (as far as I know) pow2(x).
I implemented my own pow2 as:
inline double pow2(double a){return a*a;}
which should be still better than pow(a,2), but it is based on the * operator that is not unary.
How to implement a genuine unary implementation of pow2? Would it be the most efficient way to obtain the second power of a double?
NOTE: I am aware of the fact that every real power of a positive real is an unary operation and that it is nonsense to define an infinite number of pow2, pow3, pow3.14... from the practical point of view I'm very happy with pow(double, double).
"it is more efficient to use x*x instead of pow(x,2)"
Not certainly more efficient. It might be the same. C allows analyze-ability of such functions like pow() and both may emit the same code.
A compiler may not analyze your pow2() and create sub-optimal code as compared to pow(a,2).
If truly concerned, profile your code. Yet what is best on one platform may differ on others.
How to implement a genuine unary implementation of pow2?
inline double pow2(double a){return a*a;} is OK.
Would it be the most efficient way to obtain the second power of a double?
"most efficient" --> I suggest no function, just x*x.
Also note that C allows FP to evaluate at higher precision that required. Research FLT_EVL_METHOD. The goal for most efficient way to obtain the second power of a double with a function may defeat overall performance.
In C/C++ there is a unary minus operator, which returns the additive inverse of an arithmetic type (at least in most cases), i.e.
int x = 2, y = 2;
assert(x + (-x) == 0);
From a mathematical viewpoint it doesn't matter if one writes -x or 0-x, but from a programmer perspective it does. The sequence of instructions used to evaluate -x is in general different than the sequence of instructions used to evaluate 0-x! Having a unary minus operator in C++ does actually make sense despite being just syntactic sugar. So does a unary operator returning the multiplicative inverse, doesn't it? But why does C++ (like many (most?all?) languages) lack such an operator?
EDIT:
My main point is, that calculating an inverse of a number x (additive or multiplicative) does not require neutral elements (0 or 1 respectively) being processed by the computer. In fact 0 and 1 are non trivial entities for computers. While evaluating 0.0-x or 1.0/x is rather "simple" (precision is still a big problem here) for floating types (like float or double in C), it can become quite complex in general. Like for muti. precision floating point types 0.0-x is way more complex than -x and thus -x is not just handy but also generates more efficient code. On the other hand one has to introduce a function like inv(x) or x.inv() or whatever to achieve the same for multiplication (multiplicative inverse), instead of maybe just writing /x for 1.0/x ... Afaik the lack of such an operator is not only observable in C and C++ but in many other languages even in languages primarily designed for math which gets me puzzled ;)
Because there is no unary multiplicative inverse symbol in mathematics.
You either represent it as x^-1 or 1/x both of which can be down (albeit in a roundabout way for power) in C++ as well.
Unary negation only exists because it exists in mathematics.
Guvante's answer correctly points out that there's no common mathematical notation for the multiplicative inverse (though x-1 could loosely be thought of as a postfix operator).
In addition, C++ is derived from C, which is derived from B. The B language didn't even have floating-point arithmetic.
C itself is primarily a systems programming language, which a greater emphasis on integers than on floating-point arithmetic. A multiplicative inverse operation on integers is not particularly useful. (Well, it might be useful for modular arithmetic, but C unsigned types don't behave that way.)
The set of arithmetic operators hasn't changed much from B to C to C++. I think the addition of unary + was the biggest change.
Furthermore, there's really no great need for a multiplicative inverse operator even for floating-point. It's easy enough to write 1.0 / x -- and any decent compiler will generate the same code that as it would for a hypothetical inverse operator applied to x. (For some CPUs, that code would apply a division operator to the values 1.0 and x anyway.)
Is there a tutorial somewhere that explains on which datatypes bitwise operations can be used? I don't know why Lady Ada thinks that I cannot bitwise OR two Standard.Integer...
$ gnatmake test.adb
gcc -c test.adb
test.adb:50:77: there is no applicable operator "Or" for type "Standard.Integer"
gnatmake: "test.adb" compilation error
Really? I excused the compiler for not being able to AND/OR enumerated data types. I excused the compiler for not being able to perform bitwise operations on Character type. I excused the compiler for not being able to convert from Unsigned_8 to Character in what I thought was the obvious way. But this is inexcusable.
Ada doesn't provide logical (bit-wise) operations on integer types, it provides them on modular types. Here's the section in the reference manual.
The "and", "or", and "xor" operators are defined for Boolean, for modular types, and for one-dimensional arrays of Boolean.
The language could have defined them for signed integer types, but that would create confusion given the variety of ways that signed integers can be represented. (Most implementations use two's-complement, but there are other possibilities.)
If you insist, you could define your own overloaded "or" operator, such as:
function "or"(Left, Right: Integer) return Integer is
type Unsigned_Integer is mod 2**Integer'Size;
begin
return Integer(Unsigned_Integer(Left) or Unsigned_Integer(Right));
end "or";
(I've verified that this compiles, but I haven't tested it, and I'd expect it to fail for negative values.)
But if you need to perform bitwise operations, you're better off using modular types or arrays of Boolean rather than signed integers.
How can I shift a QBitArray in QT?
For example, I have 0010000 which I'd like to shift left, so I would get 0100000. There is no function for this in QT's documentation concerning QBitArray.
QBitArray's purpose is using it for bitmasks of arbitrary sizes, not for arithmetic operations. You cannot shift a QBitArray. If you think you need to shift a QBitArray, then chances are you are abusing this class rather than using it.
I have developed my own BigInteger library in C++, for didactic purpose, initially I have used base 10 and it works fine for add, subtract and multiply, but for some algorithms such as exponentiation, modular exponentiation and division it appears to be more appropriate use base 2.
I am thinking restart my project from scratch and I would know what base do you think is more adequate and why?. Thanks in advance!
If you look at most BigNum type libraries you will see that they are built on top of the existing "SmallNum" data types. These "SmallNum" data types (short, int, long, float, double, ...) are in binary for too many reasons to count. Rather than a vector of base 10 digits, your code will be much faster (much, much, much faster!) if work with a vector of (for example) unsigned ints.
This is one of those places where performance does count. Suppose you use a BigNum package to solve a problem that could be solved without resorting to BigNums. Even the best BigNum library will be much slower (much, much slower) than will a simplistic, non-BigNum approach. If you try to solve a problem that is beyond the bounds of the standard representations that performance penalty will make things even worse.
The best way to overcome this inherent penalty is to take as much advantage of the builtin types as you possibly can.
A base the same as the word size on your target machine, where you have word x word = doubleword as a primitive. The primitive operations work out neatly in terms of machine instructions.
A base 10 representation makes sense for a BigDecimal type, where you need to need to represent decimal fractions exactly (for financial calculations and the like).
I can't see much benefit to using a base 10 representation for a BigInteger. It makes string conversion really easy, but at the expense of making mathematical operations much more complicated. This doesn't seem like a good tradeoff in most cases.