Ok, thank you for the suggestion Wolfgang! My only "objection" to this approach is that the computed data type is a quite ugly. But then, this is only if the user wants to do it.
Then, as soon as I have time, I shall go back to those functions and add an extra argument. Best, Giovanni Il giorno martedì 15 gennaio 2019 00:22:13 UTC+1, Wolfgang Bangerth ha scritto: > > > Giovanni, > > > Storing "cpm" (output from the sparsity function) and then re-using it > in the > > matrix function would be ideal. > > > > My question is, what is the best way to do so? > > > > One possibility is to modify the functions' interfaces (e.g. make > sparsity > > return this tuple, modify the arguments of generate matrix), but I fear > this would > > break a number of things in deal.lI > > > > The other "natural" option would be to add a "temporary basket" in > Cache, > > which allows functions to store data and flag it as "theirs. I believe > this > > behaviour is in the "spirit" of Cache and would probably turn out to be > useful > > elsewhere. > > > > After a quick google search I think I'd try to add a few elements like > this to > > the cache: > > > > std::map< unsigned int, std::vector<boost::any>> > > > > Where the unsigned int is a tag used by functions to "mark" what's > inside the > > vector. Would a solution like this be ok? Are there better alternatives? > > > > What about the update flags? This information can't be computed by > Cache, so > > would it be ok to make it so the update simply resets this map? > > Or should we return the map anyway (plus an "old" tag)? > > No, that doesn't seem like the right solution. The Cache wouldn't know > what > this object is, wouldn't know how to update it, it wouldn't be > thread-safe, > and it would require unrelated parts of the code base to agree what a > particular 'tag' number means -- which you wouldn't ever know unless you > actually read through the entire code base trying to figure out whether > someone else has already used tag 661 somewhere. > > The better solution would be if both of your functions took an optional > argument that denotes the information both functions currently compute > separately. This way, if users want to optimize their codes, they can > compute > the common information once up front and then pass it down to both of > these > functions via regular arguments. > > Best > W. > > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: [email protected] > <javascript:> > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
