The lack of an overloaded function for specifying an iwork workspace was an oversight on my part, there should be an overload for it. When I was implementing the bindings i remember being a little confused about the iwork and i didn't see the heevd implementation so i settled on creating it with the size specified in the intel MKL reference manual using the function ilaenv with a parameter of 9 for getting the number of subproblems.
For the iwork parameter should the user be able to select a minimum/optimal configuration like the other workspaces?
Jesse
Rutger ter Borg wrote:This impression is absolutely correct.
> I had the impression the workspaces (user interface) where something
along
> the line of
>
> * minimal
> * optimal
> * user-defined
No, the user is able to pass all workspaces in case of three different
> and looking at workspace.hpp, a user is allowed to pass up to two
arguments
> to the workspace template functions. Doesn't this mean that a user is
not
> able to pass an all workspaces in cases of three different value types
/
> workspaces?
workspaces, as the example from heevd shows:
template <typename T, typename R>
void operator() (..., optimal_workspace, ...)
template <typename T, typename R, typename W, typename RW, typename WI>
void operator() (..., std::pair<detail::workspace2<W,RW>,
detail::workspace1<WI> > work, ...)
>>> Perhaps it's safer to select the number of workspaces by the numberI'm saying that "n_workspace_args<value_type>::value" and
of
>>> workspaces defined in the Fortran code :-).
>>
>> Not really.
>
>Please elaborate, (fortran) workspaces are marked explicitly in the
code.
>Are you saying the number of C++ workspaces does not equal the number
of
>fortran workspaces?
"detail::workspace2" don't refer to the number of fortran workspaces.
Perhaps the names are misleading, but it is actually true that
detail::workspace2 holds two workspaces.
This solution was proposed in
http://lists.boost.org/MailArchives/ublas/2008/05/2762.php
Since no objections were raised, I assume that this solution was
accepted. Feel free to raise objections, than we can see whether there
is a better solution.
I will use the same strategy for the 64-bit modification. I proposed a
solution in
http://lists.boost.org/MailArchives/ublas/2008/11/3109.php
and as long as no objection are raised, I assume that the proposed
solution is accepted.
Regards,
Thomas
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas