K-ballo changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
K-ballo has quit [Quit: K-ballo]
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
parsa has joined #ste||ar
hkaiser has joined #ste||ar
hkaiser has quit [Quit: bye]
bita has joined #ste||ar
syrex has joined #ste||ar
bita has quit [Ping timeout: 276 seconds]
bita has joined #ste||ar
bita has quit [Ping timeout: 265 seconds]
tiagofg[m] has quit [Quit: Idle for 30+ days]
syrex has quit [Quit: syrex]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
<gonidelis[m]> K-ballo: do you know what iterators are used for the `for_each` to run by range-v3?
<K-ballo> vi's iterators?
<gonidelis[m]> what type of iterators^^
<gonidelis[m]> forward?
<K-ballo> vi's iterators
<K-ballo> vi is a vector
<K-ballo> did you mean to for_each on rng instead?
<gonidelis[m]> yes sorry
<K-ballo> and what's the type of rng?
<gonidelis[m]> K-ballo: it's typeid(rng).name() ;p
<gonidelis[m]> which if i throw into some compiler error
<gonidelis[m]> it will give me
<gonidelis[m]> remove_if_view(std::vector<int>) or sth
<gonidelis[m]> i guess it's a rhetorical question
<K-ballo> and what's the iterator category of remove_if_view<vector<*>>'s iterator?
<gonidelis[m]> no idea
<gonidelis[m]> K-ballo: that's what i asked
<K-ballo> what's the iterator type?
<gonidelis[m]> do you ask me or do you ask me to verify the question?
<K-ballo> I'm asking you to tell me what the iterator type of remove_if_view<vector<*>> is
<gonidelis[m]> i don't know, i think it's the same qestion with what i am asking
<K-ballo> and you do not know how to find out the iterator type corresponding to a range?
<gonidelis[m]> yes
<gonidelis[m]> i don't
<K-ballo> it's not exactly the same question, it is an intermediate step, but you should be more than able to answer them all
<K-ballo> see if you can find something that would help here https://en.cppreference.com/w/cpp/ranges
<K-ballo> if not, you can always just find the type of an expression returning the iterator itself, say begin(view)
<gonidelis[m]> ahh great
<gonidelis[m]> should i `cout << typeid(...).name()` it, or would choosing the path of compilation error be more wise?
<K-ballo> whatever works for you
<gonidelis[m]> `facade_iterator_t` !!????
<gonidelis[m]> are you kidding me
<gonidelis[m]> aka `ranges::basic_iterator`
<K-ballo> why would it be kidding you?
<gonidelis[m]> whatever my reaction, indees that's the most reasonable result
<gonidelis[m]> indeed^^
<gonidelis[m]> now i suppose basic_iterator is sth that translates into the basic iterator categories per case...
<K-ballo> yes, how do you ask for an iterator's category given its type?
<gonidelis[m]> ok just by asking me this
<gonidelis[m]> i am learing that type != iterator category
<gonidelis[m]> good thing to keep in mind
<gonidelis[m]> so 1. thanks
<gonidelis[m]> 2. what's the difference between iterator type and category ?
<gonidelis[m]> 3. since i don't know the diff i cannot determine a possible solution on that
<K-ballo> some basic googling should tell you what an iterator category is.. you already know
<gonidelis[m]> i know categories
<gonidelis[m]> i didn't know types
<K-ballo> ?
<gonidelis[m]> categories are input/output, bidir, forward, random
<K-ballo> and you know the type too
<gonidelis[m]> i don't know what iterator type means in general
<K-ballo> type means type
<gonidelis[m]> i think it's something like the combination of the category+the type of the container's elements
<K-ballo> iterator type is the type of something that happens to be an iteratorr
<K-ballo> given an iterator type (that is, a type of something that happens to be an iterator), you can always find out the iterator category
<gonidelis[m]> what are the possible types of an iter though?
<gonidelis[m]> is it a closed set?
<K-ballo> unbounded
<gonidelis[m]> whaaaat?
<K-ballo> well how many types can you have in C++?
<gonidelis[m]> infnite
<K-ballo> how many of those infinite types could be iterators?
jehelset has joined #ste||ar
nanmiao has quit [Ping timeout: 240 seconds]
bita has joined #ste||ar
nanmiao has joined #ste||ar
<gonidelis[m]> K-ballo: infinete? since the num of iter types, is the num of possible containers?
<gonidelis[m]> ok maybe not infinite
<gonidelis[m]> let's say, it's the number of containers that are feasible to construct
<K-ballo> all containers have iterators, but not all iterators correspond to containers
<K-ballo> containers can only have forward or greater iterators, not strictly input/output iterators
<gonidelis[m]> yes
<gonidelis[m]> so the iterator type exposed by views is... ?
<K-ballo> ?
<K-ballo> each view will likely have its own iterator type
<gonidelis[m]> iterator category^^
<K-ballo> that will depend on each view too
<K-ballo> a random access view will necessarily expose random access iterators, a bidirectional view ....
nanmiao has quit [Quit: Connection closed]
<gonidelis[m]> great
<gonidelis[m]> K-ballo: thanks!
<K-ballo> so, what was the category of the iterators from `rng`?
<gonidelis[m]> K-ballo: i guess remoe if imposes a forward_iterator barrier
<gonidelis[m]> `remove_if` ^^
<K-ballo> what's the guess based on?
<gonidelis[m]> on the fact that remove_if has a predicate
<gonidelis[m]> so it nees to be accessed one element at a time
<gonidelis[m]> it's bidirectional ;p lol
<gonidelis[m]> (i found out using a script)
<gonidelis[m]> my guess was bad?
<K-ballo> well, is it forward or is it bidirectional?
<gonidelis[m]> it's biderectional, that's for sure. the code says it
<gonidelis[m]> i guessed it's forward, probably for wrong reasons
<K-ballo> then your guess is wrong... or are you asking something else?
<gonidelis[m]> no no
<gonidelis[m]> i shouldn't ask
<gonidelis[m]> my was bad.
<gonidelis[m]> affirmative
<K-ballo> your use of a script is what you should have done in the first place (or actually reading the docs, but range's docs are... not..)
<K-ballo> for reference, my script was https://wandbox.org/permlink/V6UTMppss6lLFapX
<gonidelis[m]> !!!!
<gonidelis[m]> pro move
<K-ballo> what's your script?
<gonidelis[m]> i wouldn't call it mine
<K-ballo> that's... an odd one... but if it gets the job done
<gonidelis[m]> odd?
<gonidelis[m]> it's nooby
<K-ballo> is checking compile time properties at run time
<gonidelis[m]> huh
<gonidelis[m]> yes
<gonidelis[m]> indees
<gonidelis[m]> i forgot about the incomplete template trick
<hkaiser> why not use is_random_iterator<range_iterator_t<decltype(r)>>::value
<K-ballo> there's a random_access_range concept too (one for each category actually)
<gonidelis[m]> the relieving part is that augustin needed a script, too
<hkaiser> lol
<gonidelis[m]> the remove_if seems like didn't impose any iterator category barriers after all
<gonidelis[m]> hkaiser: ^^
<hkaiser> huh?
<hkaiser> I'd expect remove_if to expose bidir iterators
<gonidelis[m]> someone hacked math here
<K-ballo> for any decent library I would have just read the docs
<gonidelis[m]> K-ballo: shouldn't c++20 specify this?
<K-ballo> C++20 doesn't have a remove_if view, does it?
<K-ballo> scroll down to "Range adaptors"
<hkaiser> they don't have any algorithmic views, I believe
<gonidelis[m]> K-ballo: what are you
<hkaiser> except transform and filter
<gonidelis[m]> hkaiser: yes they don't
<gonidelis[m]> they cheated
<gonidelis[m]> everything is easy without algorithmic views
<gonidelis[m]> K-ballo: plz don't call range-v3 "un-decent"
<K-ballo> sure I will
<hkaiser> heh
<K-ballo> it's docs are a complete entire mess
<K-ballo> almost as if it wasn't targeted at users (that's actually the reason)
<gonidelis[m]> its^^
<gonidelis[m]> K-ballo: so there is nothing to blame it for
<gonidelis[m]> hkaiser: hpx:info doesn't refer to the build type https://gist.github.com/gonidelis/5d570e9faa2c75108a484dad8ae75cba
<hkaiser> then it is --hpx:version ;-)
<hkaiser> we should combine these two at some point...
<gonidelis[m]> hkaiser: ahh great
<gonidelis[m]> hkaiser: so with release i get the same results. i supsect the problem is on the iterator being bidir
<gonidelis[m]> and not random
<hkaiser> makes sense
<gonidelis[m]> so no one hacked the math. i was wrong
<gonidelis[m]> hkaiser: our hope lies in asyncrhony
<K-ballo> remove_if view cannot possibly be random access
<gonidelis[m]> K-ballo: because of math
<K-ballo> math how?
<gonidelis[m]> hkaiser: and yes, if i just use "parallelizable" views, say `transfrom`, we do have a performance boost
<gonidelis[m]> hkaiser: so bottom line, it's what operations you choose to chain
<gonidelis[m]> K-ballo: there is no algorithmical way to chain the result of `remove_if` to some other "simple" operation (e.g. `transform`) and expect for the `remove_if` to provide the result with rand. iterators
<K-ballo> I don't know what that means
<gonidelis[m]> since the predicate needs to be applied to all the elements
<gonidelis[m]> one by one
<gonidelis[m]> you cannot find an algorithm impl of remove_if that gives me random access to the elements of its result
<gonidelis[m]> its = remove_if
<gonidelis[m]> K-ballo: ^^
<K-ballo> so it can't be random access because it can't be random access? I'll agree to that
<hkaiser> everything is determined by the iterator category of the iterators the range view generates
<gonidelis[m]> hkaiser: that's a perfect explanation. but there is no way for remove_if to generate random access
<gonidelis[m]> <K-ballo "so it can't be random access bec"> what's your reasoning?
<K-ballo> advance can't meet the O(1) complexity guarantee required by random access
<K-ballo> because, as you said, needs to apply the predicate one by one until it finds the next element
<gonidelis[m]> we aggree
<gonidelis[m]> i like your wording though
<K-ballo> similarly for distance
<gonidelis[m]> yy
<gonidelis[m]> K-ballo: now put `future`s on that... and you may get sth better than non-parallel-at-all
<K-ballo> futures on a view..?
<gonidelis[m]> K-ballo: ahh not exactly... sorry
<gonidelis[m]> i meant, take advantage of the pipelining operation by using async.algorithms (instead of views) + executors (chain continuation)
<gonidelis[m]> that's like an inbred of views i know
<gonidelis[m]> but you still get to chain things
<gonidelis[m]> not that composable though
<gonidelis[m]> i don't want to spoil it for you, "Come to CppNow talk and find everything you need to know, Now!"
<gonidelis[m]> my^^
<gonidelis[m]> gnikunj[m]: cppnow published your talk on twitter
<gnikunj[m]> ohh nice!
nanmiao has joined #ste||ar
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar