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

On Wed, Dec 10, 2008 at 6:28 PM, Thomas Klimpel <Thomas.Klimpel@synopsys.com> wrote:
Rutger ter Borg wrote:
> I had the impression the workspaces (user interface) where something
along
> the line of
>
>  * minimal
>  * optimal
>  * user-defined

This impression is absolutely correct.

> 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?

No, the user is able to pass all workspaces in case of three different
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 number
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?

I'm saying that "n_workspace_args<value_type>::value" and
"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