>>> -const unsigned int Upper = UpperTriangularBit;
>>> -const unsigned int StrictlyUpper = UpperTriangularBit | ZeroDiagBit;
>>> -const unsigned int Lower = LowerTriangularBit;
>>> -const unsigned int StrictlyLower = LowerTriangularBit | ZeroDiagBit;
>>> +const unsigned int Upper = UpperTriangularBit | UpperHessenbergBit;
>>> +const unsigned int StrictlyUpper = Upper | ZeroDiagBit;
>>> +const unsigned int Lower = LowerTriangularBit | LowerHessenbergBit;
>>> +const unsigned int StrictlyLower = Lower | ZeroDiagBit;
>>>
>>> here I don't really follow. These are parameters for part(). So unless
>>> you want to add Hessenberg support in part (which would be a good
>>> idea) no need to change that. If you want to add Hessenberg support,
>>> you need to make the corresponding changes in Part.h.
>>
>> I saw that the product helper checked for diagonals using the flags,
>> so I did the same for tridiagonals.
>
> OK right, sorry. These are always convenient shortcuts. What needs to
> be updated then is the comment saying that these are the parameters
> for part(), actually they're not used only for part().
Wait, no, I answered too fast. We really can't do such a thing as
+const unsigned int Upper = UpperTriangularBit | UpperHessenbergBit;
for example how would we then in part() distinguish between upper
triangular and upper hessenberg...
the real problem is that in the first place we allowed ourselves this
silly shortcut Upper for upper triangular. Now that there is upper
hessenberg too, this is getting ambiguous. I think we just rename
Upper to UpperTriangular and then we add UpperHessenberg alongside.
Yes this is an incompatible API change, there's a reason why we
haven't released yet. KDE / KOffice is not affected, as far as I can
remember.
Cheers,
Benoit
---