<weilewei>
hkaiser does std::vector guarantee that internal data are contiguous?
<hkaiser>
weilewei: the elements themselves will be contiguous
<hkaiser>
if the lements allocate data themselves those data items will not be guaranteed to be contibuous, however
<hkaiser>
weilewei: do you need a view onto a large (contiguous) array that presents itself as an array of reshapable matrices?
<weilewei>
hkaiser I see, so if I say MPI_Isend(vec_RMatrix.data(), vec_RMatrix.size() * N* M, ...) where N and M are shape of RMtrix, does it work?
<hkaiser>
don't think so
<hkaiser>
weilewei: it does not make a difference whether you call mpi_isend once for a very large array or several times for large arrays, really
<hkaiser>
moreover you can do that concurrently
<weilewei>
hkaiser Ok, then I might not hang myself there
<hkaiser>
I'd suggest you don't
<hkaiser>
the effect will not be worth your time
<weilewei>
lol right
bita__ has quit [Ping timeout: 260 seconds]
hkaiser has quit [Quit: bye]
bita__ has joined #ste||ar
bita__ has quit [Ping timeout: 252 seconds]
weilewei has quit [Remote host closed the connection]
mcopik has joined #ste||ar
mcopik has quit [Client Quit]
gonidelis has joined #ste||ar
* ms[m]
wonders why we don't generate our compatibility headers... would be so much easier
<ms[m]>
I guess that ship has mostly sailed now
<gonidelis>
question: why use `hpx::util::invoke(a, b)` instead of a(b)?? I have encountered this type of code many times in hpx source...
<rori>
Not sure what is the reason in our implementation but I've read somewhere that the `std::invoke` was here to simplify invoking a pointer function of an object `(obj->*f)()` which is ugly
<rori>
but my knowledge on hpx in general is still very limited ^^
<gonidelis>
wow. that IS ugly... thanks rori .
<zao>
gonidelis: Regarding yesterday's discussion on build/source directories, I recommend installing into a non-system location with -DCMAKE_INSTALL_PREFIX as well, so that you have more flexibility in what installation to use later, and ease of deletion.
<gonidelis>
zao yup... that's what I have done. It has been a month or so from my last installation and I think it was your advice back then that convinced me to intall it on non-system dir. Thank you
<zao>
:D
nikunj97 has joined #ste||ar
<jbjnr>
ms[m]: I also wondered why we do not have a script for generating the compatibility headers. I have only done mpi and cuda modules and that was annoying enough. doing dozens of them would drive me batty
<ms[m]>
jbjnr: oh, we have a script for generating them, so it's not too bad... but we could be generating them from cmake instead
<gonidelis>
I have been studying `iterator_traits` for the last couple hours, trying to understand their significance. I have visited various sites, docs and blogs and I have comprehended the basic points like that there are 5 certain traits types and that they facilitate generic/template functions formulation as they impose some serious level of abstraction.
<gonidelis>
But I still find hard to really understand how, when and why should be used. Any dummy explanation/source would be appreciated. I am in need of pure practical arguments and not just another theoretical approach.
<zao>
Traits are excellent customization points as they allow you to express that a type of yours adheres to some interface, by implementing the trait for them.
<zao>
They're an extrinsic way of doing so without necessarily having to modify the type itself, as you can put that functionality on the trait implementation.
<zao>
Kind of like external interfaces.
<zao>
Some traits don't contain code, they're just used for type-based selection, while other traits contain the actual functionality and you don't care much about the actual type at all.
<zao>
The standard iterator_traits are weird, tho.
hkaiser has joined #ste||ar
<gonidelis>
zao Thank you very much. I would like to respond using a certain small snippet of code. What tool do you guys use to publish small code here in IRC??
<zao>
I like Github gists.
<zao>
Other paste sites work too.
<gonidelis>
Thank you. Just give me a sec...
<gonidelis>
zao I totally get what you are saying. If we take a random example (e.g. https://gist.github.com/gonidelis/1bee955aa2759b86cda14550efaddb94) I do understand like 80% of the code but I have problem with the `iterator_traits` part. What is the relationship of `difference_type` with `RandIter` ? What would be the problem if `difference_type` was
<gonidelis>
declared as `int` (I know that's an oversimplification of course)?
<hkaiser>
gonidelis: difference_type is the type of the value resulting from subtracting one iterator of another
<zao>
The point of using the types from the trait (or the type itself) is that you're using the expected types.
<zao>
Instead of a type that happens to kind of be compatible in this case, but not necessarily for all things that provide the trait.
<hkaiser>
v.end()-v.begin() yields a value of type vector<>::iterator::difference_type
<zao>
If you use `i_t<T>::difference_type` you get the right type regardless of how it's defined.
<zao>
gonidelis: `int` and `ptrdiff_t` and `ssize_t` are sometimes quite different types.
<gonidelis>
hkaiser Your explanation seems pretty straightforward. I get it. Thanks. zao You are saying that trait's significance is that you incorporate the value type to which it refers to, in its (trait's) declaration. right?
<zao>
The wording up to Template parameters kind of help describe the purpose of the typedefs and why it might be useful.
<zao>
It's kind of a type adaptor, that provides a well-defined interface to the somewhat more vague thing that is an "iterator".
<zao>
Letting you write code that talks about an iterator's "difference_type", "value_type", etc.
<gonidelis>
hmm I really think I am a little bit more comfortable now. Thank you all. STL is like wow! The ideas of abstraction that it indicates are, without exaggeration, breath-taking!!!
<zao>
Just iterator_traits is old and weird, but it's common enough out in the wild to know the base idea.
<gonidelis>
are we using sth else besides besides iterator_traits (i reckon that's the same as std::iterator_traits), here in hpx community?
<hkaiser>
gonidelis: we use as much from the std library as possible