Not going to lie, probably one of the best talks I've ever watched. I'm also very impressed by the fact that it was his first talk at a conference. He sounded very confident for a first-timer.
One of my favourite additions to Kotlin was windowed() to have a nicely named alternative to zipping the start of a range with its tail. In range-v3, it's called view::sliding.
Very good talk. Did anyone notice the slide code at 31:20 had used an undeclared var `v`? That must have meant to be `coins`. Slide code almost always has some bug.
I think the difference between transform and reduce should be made explicit so as to avoid confusion. From my point of view, inclusive scan can be seen as both since it transforms each value into another one, but it also performs an accumulation since the new values depend on all the previous ones.
46:00 They totally should have not call it "zip_reduce" and specially not if i got this talk right. You ""could"" get that before, its comming in c++23 i think, you make a pair combining each elem, pass it to transform, and then unbind them inside. zip plus reduce is not what you want, is what you would had to do to overcome not having a way to transform_reduce in this way. You can use transform_reduce without ever knowing what zip is, it will still solve your problem -using this other range(vector) to transform this result/this one. Thinking of it as a zip is intuitive, but in the wrong way...
At 1:22:38: He "invents" adjacent_inclusive_scan, doing some writeup and comes to the conclusion, that this algorithm is already in the std library under the name transform_inclusive_scan. I took several looks but i think this is wrong? transform_inclusive_scan takes "just" an unary operation for its transform part. In the "invented" adjacent_inclusive_scan we are using a binary operation for the transform part. Am i missing something? Great presentation tho!
"inner product" is the perfect name for the function. Look up "dot product" on wikipedia. And then "Hilbert space". Inner product is fundamentally the correct name.
Would using reduce for any_of impl short circuit it? think this: stackoverflow.com/questions/47692180/is-stdany-of-required-to-follow-short-circuit-logic . thanks.
Thank you Michael! I realized this after the fact (I should have checked their Twitter bio as it is listed there), and I feel really bad about it. In my upcoming September CppCon talk I will make sure not to make the same mistake, and hopefully I will meet them in person and be able to apologize (probably Simon hasn't seen the talk though - but in case they ever do).
Not going to lie, probably one of the best talks I've ever watched. I'm also very impressed by the fact that it was his first talk at a conference. He sounded very confident for a first-timer.
He is a natural speaker and an expert at algorithms with only 5 Years C++ experience, now let me go find his channel.
@@TheReferrer72 5 years is like no experience relatively speaking
"This is phenomenal, I want to write code like CONOR!!!!"
One of my favourite additions to Kotlin was windowed() to have a nicely named alternative to zipping the start of a range with its tail. In range-v3, it's called view::sliding.
I love sliding as well. It is covered in one of my recent videos: ruclips.net/video/cClOEG-_dns/видео.html
Very good talk. Did anyone notice the slide code at 31:20 had used an undeclared var `v`? That must have meant to be `coins`. Slide code almost always has some bug.
I think the difference between transform and reduce should be made explicit so as to avoid confusion. From my point of view, inclusive scan can be seen as both since it transforms each value into another one, but it also performs an accumulation since the new values depend on all the previous ones.
46:00 They totally should have not call it "zip_reduce" and specially not if i got this talk right.
You ""could"" get that before, its comming in c++23 i think, you make a pair combining each elem, pass it to transform, and then unbind them inside. zip plus reduce is not what you want, is what you would had to do to overcome not having a way to transform_reduce in this way.
You can use transform_reduce without ever knowing what zip is, it will still solve your problem -using this other range(vector) to transform this result/this one. Thinking of it as a zip is intuitive, but in the wrong way...
At 1:22:38: He "invents" adjacent_inclusive_scan, doing some writeup and comes to the conclusion, that this algorithm is already in the std library under the name transform_inclusive_scan. I took several looks but i think this is wrong? transform_inclusive_scan takes "just" an unary operation for its transform part. In the "invented" adjacent_inclusive_scan we are using a binary operation for the transform part. Am i missing something? Great presentation tho!
Wow, amazing catch. That is absolutely correct. That is definitely an oversight. transform_inclusive_scan definitely doesn't look at 2 indexes.
Great Video!
Wow, it is like Mendeleev chemical elements table for algorithms. As far as I could understand. All is visible
Excellent talk. That BlackMirror clip seems familiar :)
I do not see how the algorithm'ized versions are better than for loops, for the most part.
"inner product" is the perfect name for the function. Look up "dot product" on wikipedia. And then "Hilbert space". Inner product is fundamentally the correct name.
Where can we get the slides? Couldn't find it on cppnow.org!
It doesn't look like they have uploaded them yet. I will try to post them to github later today.
I have uploaded them to my github: github.com/codereport/Talks/blob/master/2019-05-CppNow/AlgorithmIntuition/AlgorithmIntuition%20-%20FINAL.pdf
Would using reduce for any_of impl short circuit it? think this: stackoverflow.com/questions/47692180/is-stdany-of-required-to-follow-short-circuit-logic . thanks.
Using reduce or accumulate for the impl would not. But the actual implementation of any_of definitely does short circuit.
Interesting talk, but my goodness isn't C++ messy/irregular!
But, Its blazingly Fast !
he is a rebel:)
hopefully, east const was a trolling
FYI Conor, Simon Brand uses they/them pronouns not he/him. Great Talk!
Thank you Michael! I realized this after the fact (I should have checked their Twitter bio as it is listed there), and I feel really bad about it. In my upcoming September CppCon talk I will make sure not to make the same mistake, and hopefully I will meet them in person and be able to apologize (probably Simon hasn't seen the talk though - but in case they ever do).