Eigen non constant MatrixReplacement for sparse solver
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I want to use matrix free sparse solvers with custom matrix-vector product object. Here is great example how to to it - https://eigen.tuxfamily.org/dox/group__MatrixfreeSolverExample.html
But in this example custom matrix-product object should be constant due to generic_product_impl signature
template<typename Dest>
static void scaleAndAddTo(
Dest& dst,
const MatrixReplacement& lhs,
const Rhs& rhs,
const Scalar& alpha)
In many my problems i need a lot of temporary buffers for each product call. It's pretty wise to allocate them once but i can't store them inside MatrixReplacement because it passed as const.
Is it possible in Eigen to overcome this problem?
c++ eigen eigen3 mutability
asked Nov 16 '18 at 13:38
Dark_DaiverDark_Daiver
7401932
add a comment |
I want to use matrix free sparse solvers with custom matrix-vector product object. Here is great example how to to it - https://eigen.tuxfamily.org/dox/group__MatrixfreeSolverExample.html
But in this example custom matrix-product object should be constant due to generic_product_impl signature
template<typename Dest>
static void scaleAndAddTo(
Dest& dst,
const MatrixReplacement& lhs,
const Rhs& rhs,
const Scalar& alpha)
In many my problems i need a lot of temporary buffers for each product call. It's pretty wise to allocate them once but i can't store them inside MatrixReplacement because it passed as const.
Is it possible in Eigen to overcome this problem?
c++ eigen eigen3 mutability
asked Nov 16 '18 at 13:38
Dark_DaiverDark_Daiver
7401932
add a comment |
I want to use matrix free sparse solvers with custom matrix-vector product object. Here is great example how to to it - https://eigen.tuxfamily.org/dox/group__MatrixfreeSolverExample.html
But in this example custom matrix-product object should be constant due to generic_product_impl signature
template<typename Dest>
static void scaleAndAddTo(
Dest& dst,
const MatrixReplacement& lhs,
const Rhs& rhs,
const Scalar& alpha)
In many my problems i need a lot of temporary buffers for each product call. It's pretty wise to allocate them once but i can't store them inside MatrixReplacement because it passed as const.
Is it possible in Eigen to overcome this problem?
c++ eigen eigen3 mutability
asked Nov 16 '18 at 13:38
Dark_DaiverDark_Daiver
7401932
I want to use matrix free sparse solvers with custom matrix-vector product object. Here is great example how to to it - https://eigen.tuxfamily.org/dox/group__MatrixfreeSolverExample.html
But in this example custom matrix-product object should be constant due to generic_product_impl signature
template<typename Dest>
static void scaleAndAddTo(
Dest& dst,
const MatrixReplacement& lhs,
const Rhs& rhs,
const Scalar& alpha)
In many my problems i need a lot of temporary buffers for each product call. It's pretty wise to allocate them once but i can't store them inside MatrixReplacement because it passed as const.
Is it possible in Eigen to overcome this problem?
c++ eigen eigen3 mutability
c++ eigen eigen3 mutability
asked Nov 16 '18 at 13:38
Dark_DaiverDark_Daiver
7401932
asked Nov 16 '18 at 13:38
Dark_DaiverDark_Daiver
7401932
edited Nov 16 '18 at 13:47
Dark_Daiver
asked Nov 16 '18 at 13:38
Dark_DaiverDark_Daiver
7401932
asked Nov 16 '18 at 13:38
Dark_DaiverDark_Daiver
7401932
asked Nov 16 '18 at 13:38
Dark_DaiverDark_Daiver
7401932
7401932
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
There are two immediate options:
Use the
mutablekeyword for the members that need to change inconstmethods (i.e. your temporary buffers). This keyword makes sense where observable behavior of your class is const, despite you needing to modify members. Examples include cached values, mutexes, or your buffers.C++ is not perfectly strict with propagating
const. Aconst unique_ptr<T>will return a (non-const)T&when dereferenced (because the const says "you can't change the pointer", not "you can't change the pointee"; this is the same with builtin pointers). You can similarly wrap your "real" sparse matrix class in something that pretends to be const but allows non-const access to the matrix if the STL smart pointers are insufficient. If you give it an appropriate name then it's not as terrible as it sounds.
I recommend option 1.
answered Nov 16 '18 at 13:55
Max LanghofMax Langhof
12.1k22241
Thank you for answer! Do i understand correctly that first option is preferable because of "explicitness"?
– Dark_Daiver
Nov 16 '18 at 14:01
1
It's just an appropriate place to usemutable, it is simply idiomatic. The second feels a lot like a hack (because it is circumventing the original intent of the interface entirely). I'm still suggesting it because sometimesmutableis not the "correct"/idiomatic solution.
– Max Langhof
Nov 16 '18 at 14:42
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53338985%2feigen-non-constant-matrixreplacement-for-sparse-solver%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There are two immediate options:
Use the
mutablekeyword for the members that need to change inconstmethods (i.e. your temporary buffers). This keyword makes sense where observable behavior of your class is const, despite you needing to modify members. Examples include cached values, mutexes, or your buffers.C++ is not perfectly strict with propagating
const. Aconst unique_ptr<T>will return a (non-const)T&when dereferenced (because the const says "you can't change the pointer", not "you can't change the pointee"; this is the same with builtin pointers). You can similarly wrap your "real" sparse matrix class in something that pretends to be const but allows non-const access to the matrix if the STL smart pointers are insufficient. If you give it an appropriate name then it's not as terrible as it sounds.
I recommend option 1.
answered Nov 16 '18 at 13:55
Max LanghofMax Langhof
12.1k22241
Thank you for answer! Do i understand correctly that first option is preferable because of "explicitness"?
– Dark_Daiver
Nov 16 '18 at 14:01
1
It's just an appropriate place to usemutable, it is simply idiomatic. The second feels a lot like a hack (because it is circumventing the original intent of the interface entirely). I'm still suggesting it because sometimesmutableis not the "correct"/idiomatic solution.
– Max Langhof
Nov 16 '18 at 14:42
add a comment |
There are two immediate options:
Use the
mutablekeyword for the members that need to change inconstmethods (i.e. your temporary buffers). This keyword makes sense where observable behavior of your class is const, despite you needing to modify members. Examples include cached values, mutexes, or your buffers.C++ is not perfectly strict with propagating
const. Aconst unique_ptr<T>will return a (non-const)T&when dereferenced (because the const says "you can't change the pointer", not "you can't change the pointee"; this is the same with builtin pointers). You can similarly wrap your "real" sparse matrix class in something that pretends to be const but allows non-const access to the matrix if the STL smart pointers are insufficient. If you give it an appropriate name then it's not as terrible as it sounds.
I recommend option 1.
answered Nov 16 '18 at 13:55
Max LanghofMax Langhof
12.1k22241
Thank you for answer! Do i understand correctly that first option is preferable because of "explicitness"?
– Dark_Daiver
Nov 16 '18 at 14:01
1
It's just an appropriate place to usemutable, it is simply idiomatic. The second feels a lot like a hack (because it is circumventing the original intent of the interface entirely). I'm still suggesting it because sometimesmutableis not the "correct"/idiomatic solution.
– Max Langhof
Nov 16 '18 at 14:42
add a comment |
There are two immediate options:
Use the
mutablekeyword for the members that need to change inconstmethods (i.e. your temporary buffers). This keyword makes sense where observable behavior of your class is const, despite you needing to modify members. Examples include cached values, mutexes, or your buffers.C++ is not perfectly strict with propagating
const. Aconst unique_ptr<T>will return a (non-const)T&when dereferenced (because the const says "you can't change the pointer", not "you can't change the pointee"; this is the same with builtin pointers). You can similarly wrap your "real" sparse matrix class in something that pretends to be const but allows non-const access to the matrix if the STL smart pointers are insufficient. If you give it an appropriate name then it's not as terrible as it sounds.
I recommend option 1.
answered Nov 16 '18 at 13:55
Max LanghofMax Langhof
12.1k22241
There are two immediate options:
Use the
mutablekeyword for the members that need to change inconstmethods (i.e. your temporary buffers). This keyword makes sense where observable behavior of your class is const, despite you needing to modify members. Examples include cached values, mutexes, or your buffers.C++ is not perfectly strict with propagating
const. Aconst unique_ptr<T>will return a (non-const)T&when dereferenced (because the const says "you can't change the pointer", not "you can't change the pointee"; this is the same with builtin pointers). You can similarly wrap your "real" sparse matrix class in something that pretends to be const but allows non-const access to the matrix if the STL smart pointers are insufficient. If you give it an appropriate name then it's not as terrible as it sounds.
I recommend option 1.
answered Nov 16 '18 at 13:55
Max LanghofMax Langhof
12.1k22241
answered Nov 16 '18 at 13:55
Max LanghofMax Langhof
12.1k22241
answered Nov 16 '18 at 13:55
Max LanghofMax Langhof
12.1k22241
answered Nov 16 '18 at 13:55
Max LanghofMax Langhof
12.1k22241
12.1k22241
Thank you for answer! Do i understand correctly that first option is preferable because of "explicitness"?
– Dark_Daiver
Nov 16 '18 at 14:01
1
It's just an appropriate place to usemutable, it is simply idiomatic. The second feels a lot like a hack (because it is circumventing the original intent of the interface entirely). I'm still suggesting it because sometimesmutableis not the "correct"/idiomatic solution.
– Max Langhof
Nov 16 '18 at 14:42
add a comment |
Thank you for answer! Do i understand correctly that first option is preferable because of "explicitness"?
– Dark_Daiver
Nov 16 '18 at 14:01
1
It's just an appropriate place to usemutable, it is simply idiomatic. The second feels a lot like a hack (because it is circumventing the original intent of the interface entirely). I'm still suggesting it because sometimesmutableis not the "correct"/idiomatic solution.
– Max Langhof
Nov 16 '18 at 14:42
Thank you for answer! Do i understand correctly that first option is preferable because of "explicitness"?
– Dark_Daiver
Nov 16 '18 at 14:01
Thank you for answer! Do i understand correctly that first option is preferable because of "explicitness"?
– Dark_Daiver
Nov 16 '18 at 14:01
1
1
It's just an appropriate place to use
mutable, it is simply idiomatic. The second feels a lot like a hack (because it is circumventing the original intent of the interface entirely). I'm still suggesting it because sometimes mutable is not the "correct"/idiomatic solution.– Max Langhof
Nov 16 '18 at 14:42
It's just an appropriate place to use
mutable, it is simply idiomatic. The second feels a lot like a hack (because it is circumventing the original intent of the interface entirely). I'm still suggesting it because sometimes mutable is not the "correct"/idiomatic solution.– Max Langhof
Nov 16 '18 at 14:42
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53338985%2feigen-non-constant-matrixreplacement-for-sparse-solver%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
