<K-ballo>
and yes, that is a sentinel for any iterator
<K-ballo>
`FwdIterE` should be renamed to something other than `Iter`, what's the E for?
<hkaiser>
I think the unreachable_sentinel is already weakly equality comparable to any type, so this should work out of the box
<gonidelis[m]>
K-ballo: The E is for "end iterator" and the B for "begin iterator". The reason we changed it is for those two iterators to be able to be of different type. Like iterator_pointer - sentinel
<K-ballo>
oh, in that case I'd suggest FwdIter, Sentinel
<gonidelis[m]>
But that's 1 of the 3 cases. After the last specification it is proposed that the algorithm should accept either : 1. pointer_iter - pointer_iter (as before) 2. pointer_iter - D (relevant distance) 3. pointer_iter - sentinel value
<gonidelis[m]>
1 is the already implemented default case and 2 had been implemented recently I think...
<K-ballo>
a pointer is an iterator, and an iterator is a sentinel, so 1 is fine
<K-ballo>
2 sounds dubious.. do ranges do this, vs having `_n` overloads or something else?
<gonidelis[m]>
The reason we do that is for the ranges wrappers to call this iterator adapted algos.
<K-ballo>
yes, that's the same thing ranges does.. how does that affect things?
<gonidelis[m]>
K-ballo: I have not encountered any problems with this case. My questions the last days have been around the 3rd case only... ;)
<gonidelis[m]>
As for the "_a pointer is an iterator, and an iterator is a sentinel, so 1 is fine_" statement I 've spent the last 6 days trying to separate those cases but I still have not managed to create an example-test to prove that just 1. does the work
<gonidelis[m]>
<hkaiser "I think the unreachable_sentinel"> hkaiser: Do you mean that I shouldn't prefer `unreachable_sentinel` on my unit test?
<K-ballo>
but the whole design point of sentinels was that iterators are sentinels for their own kind
<K-ballo>
is_sentinel_for<Iter, Iter> is always true
<gonidelis[m]>
K-ballo: So then shouldn't we adapt the algorithms to accept sentinels????
<K-ballo>
ideally yes, but we are working on top of <algorithms> which doesn't support them, no? so that would mean rewriting all of them
<K-ballo>
it's possible to implement the entire ranges-v3 without adapting the algorithms (it had no control over <algorithms> either), but rather by adapting the sentinels to the algorithms
<K-ballo>
given a sentinel and an iterator, it is possible to define a common-iterator type pair that represents the same range
<hkaiser>
gonidelis[m]: I meant that if you implement is_sentinel_for<> it will return true for any iterator if the sentinel is unreachable_sentinel, i.e. is_sentinel_for<unreachable_sentinel, Iter> is true for any Iter
<gonidelis[m]>
hkaiser: ohh ok... i guess i am still familiarizing myself with the sentinels then 😕
<hkaiser>
K-ballo: yes, but in our case we want to use the existing algorithms (accepting the iterator pair) to implement the ranges version, which would require for our algorithms to accept different iterator types
<K-ballo>
that's what I said, yep
<K-ballo>
btw "different iterator types" makes little sense
<K-ballo>
it's iter pair or iter+sentinel, never iterA+iterB
<hkaiser>
well, essentially our for_each will look like for_each(IterB, IterE, F)
<hkaiser>
K-ballo: I agree, that's why we need is_sentine_for to weed out the IterA+IterB case
<K-ballo>
mmh? there is no IterA+IterB case (those are types, not values)
Nikunj__ has joined #ste||ar
<gonidelis[m]>
Shouldn't the algo accept iterators of different types? What hkaiser I think is trying to say is `typename IterA` + `typename IterB` which means different types...
<gonidelis[m]>
K-ballo: ^^
<K-ballo>
no, why would an algorithm accept iterators of different types? what would it do with them?
<hkaiser>
gonidelis[m], rori: I might be 5-10 minutes late, I apologize
<gonidelis[m]>
hkaiser: np for me
nikunj97 has quit [Ping timeout: 256 seconds]
<rori>
👍️
<gonidelis[m]>
K-ballo: I was thinking of a Sentinel as "the different type" but maybe I got it wrong
<K-ballo>
a sentinel will be a different type, but not an iterator type
<K-ballo>
the only sentinel which is an iterator type is the same iterator type as the first iterator
<K-ballo>
not all sentinels are iterators, remember?
<K-ballo>
our algorithms ought to take an Iterator and a Sentinel, which already covers the case of the Sentinel being the same Iterator type
nikunj97 has joined #ste||ar
<K-ballo>
when in doubt just look at what standard ranges or ranges-v3 do
<gonidelis[m]>
K-ballo: So is it just a problem of readibility - variable naming (`FwIterE`) ? Or do we have to handle `typename FwIterE` in a different - special way ?
<K-ballo>
the convention for algorithms is that a template parameter named FwdIter* needs to model the forward iterator concept (which most sentinels won't)
<gonidelis[m]>
K-ballo: You suggest that reading the ranges-v3 code-base would help understand the iterator+sentinel pair in a better way, aren't you?
Nikunj__ has quit [Ping timeout: 260 seconds]
<K-ballo>
noooo don't go reading the ranges-v3 code, don't don't don't
<K-ballo>
I'm suggesting you look at the interface, the documentation
<weilewei>
for hazard pointer c++ proposal, I saw the p0233r0 to r6, and then it shifted to p1121r0, why proposal number changed?
<weilewei>
also HP is mentioned in p0566r4
<hkaiser>
rori, we're ready whenever you are
<rori>
coming
sayefsakin has joined #ste||ar
<heller1>
nikunj: I don't have a compute bound test at hand. Nbody and matrix-matrix multiplication are compute bound of done right
<nikunj>
heller1: yea I was looking into blas3 matrix-matrix multiplication
<nikunj>
Don't think I can have something similar implemented
<nikunj>
heller1: any suggestions on mm multiplication with hpx?
<hkaiser>
nikunj97: look at David's matrix multiplication with HPX