Interesting. However, since Octave just uses std::complex for this operation, I suppose it's the problem of libc's cpow. I don't think this is serious, but you can file a bug there. In any case I support the opinion that attempting to workaround every possible libc math defect would make Octave too bloated to be maintainable.

Being the guy who implemented the proper 64-bit arithmetics support in Octave 3.2, I can maybe share some interesting points. Matlab's design choice of double as the default type is both a blessing and a curse. Usually the blessing strikes you first (I always disliked it that 1/2 is 0 in C++ and Python, finally Python 3 changed that as well), but you start to feel the curse when diving deeper, and integer arithmetics (which I agree is far less used than floating point) is a perfect example. Initially, Matlab probably had no integers. Given that double is the default, Matlab creators decided to make the integers "intrusive", in the sense that integers combined with reals result in integers, not reals, contrary to most other languages. The motivation is probably so that you can write things like a + 1 or 2*a without a silent conversion. Hence, when I is integer, D is double and OP is any operator, I OP D behaves like int (double (I) OP D). Except that things like a + 1 seem to be optimized (something Octave currently lacks, but it shouldn't be hard to do). int64 is where things start to get messy, because not all 64-bit integers can be exactly represented in double. So, using the simple formula above, 0.5 * i64 could occassionally do something else that i64 / 2, which is highly undesirable. In order to do the "right thing", Octave will choose one of two options: first, if it discovers that "long double" is at least 80-bits wide (so that it can hold any 64-bit integers), it will use that to do the operations. If not, it will employ a custom code to emulate the operation as if it was performed with enough precision. It's based on manipulating the mantissa and exponent of the double and is much slower. Although it was kinda fun to implement it, it is really a lot of work for too little music, so that can partially explain MathWorks' attitude to this. Unlike Octave, MathWorks doesn't really need to aim at source portability (as they just distribute binaries), so maybe they're just waiting for proper long double support in all compilers they use, and then they will just use the simple approach. Or maybe they're waiting for some important future design change. When I implemented this, I was fully aware that it's not a killer feature, yet I thought it may make Octave more interesting to some Matlab users. So I'm glad someone noticed :) In any case, I suppose at some point Matlab will support this as well.