|
|
Ublas : |
Subject: Re: [ublas] [bindings] Workspaces
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2008-12-11 02:44:01
Hi all,
The introduction of the workspace function was meant to create a common
interface (same number of arguments) between real and complex valued
versions of LAPACK routines and different workspace options (choice
between memory savings or fast execution or user defined workspaces).
For integer workspaces this was never an issue, since the routines that
were supported that time did not have integer workspaces. This is
missing and should be added. This means that the introduction of a
workspace3 should be considered.
When I introduced the 3 workspace options, I was not fully satisfied
myself with the workspace2 function for the complex case, but I did not
see a more elegant way that time. If someone has a more user friendly
idea, this is very welcome of course.
Best regards,
Karl
Jesse Manning wrote:
> 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_at_[hidden] <mailto:Thomas.Klimpel_at_[hidden]>> 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_at_[hidden] <mailto:ublas_at_[hidden]>
> http://lists.boost.org/mailman/listinfo.cgi/ublas
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
>