11:30 <LiliumAtratum> Hello! I have a question about `hpx::parallel::transform_inclusive_scan`. The function takes a sequence of Ts, the unary transformation operator `conv` T->R, and a binary reduction operator `op` (R,R)->R. And yet, the documentation requires that T is *implicitly* convertible to R. And in fact it does! It doesn't call `conv` before calling `op`.

11:30 <LiliumAtratum> Why is that?

11:30 <LiliumAtratum> In my code I cannot make `T` implicitly convertible to `R`, but I have my `conv` function.

11:31 <LiliumAtratum> Note that `std::transform_inclusive_scan` does not have this requirement and I can use with my code without a problem

12:26 <K-ballo> LiliumAtratum: sounds like a bug.. do you have the full error message output?

12:27 <LiliumAtratum> I can prepare somehting. But I found a mistake(?) on my side by not including the 'init' parameter.

12:28 <K-ballo> sounds like another bug, `init` is optional, unless you needed it for type reasons?

12:29 <LiliumAtratum> what I am concerned is, that arguments to op seems to be given in the opposite order. Which for a non-commutative operators may be breaking.

12:30 <LiliumAtratum> i'll prepare a running example, give me a minute

12:34 <K-ballo> there is no order

12:46 <LiliumAtratum> well, there is a difference if you call op(a,b) and op(b,a) for a noncommutative operator

12:47 <K-ballo> sure, but the types of a and b are the same already

12:47 <K-ballo> or are we discussing values now?

12:47 <LiliumAtratum> Yes, I am talking about my second issue at the moment

12:47 <LiliumAtratum> preparing an example...

12:53 <LiliumAtratum> https://ideone.com/plain/UoSDCn

12:55 <LiliumAtratum> Now, no matter the order in which the summation is performed, the left argument should always be smaller than the right. So I expect the code to just perform a prefix sum. But I get -10000 everywhere.

12:56 <K-ballo> this doesn't look related to the type conversions from earlier

12:56 <LiliumAtratum> No, that's a second issue

12:56 <LiliumAtratum> I'll prepare the first issue too

12:56 <K-ballo> ok

13:04 <LiliumAtratum> Here is the first thing: https://ideone.com/plain/g4TTh7

13:04 <LiliumAtratum> uncomment `Integer{0}` and it works.

13:22 <K-ballo> LiliumAtratum: that last one is definitely a bug, hpx is using a default constructed iterator's value type as init when one isn't provided, which is just wrong

13:22 <K-ballo> please report it on github

13:24 <LiliumAtratum> ok, I'll do

13:26 <hkaiser> HPX PMC meeting today at 9am CDT/16:00 CEDT here: https://lsu.zoom.us/j/335605227

13:33 <LiliumAtratum> And how does the former issue look for you?

13:38 <K-ballo> I don't understand what the first example is supposed to ilustrate

13:39 <K-ballo> what are the actual and expected outputs?

13:44 <hkaiser> ms[m]: yt?

13:50 <LiliumAtratum> In the first example I am performing { 1 op 10 op 100 op 1000 } with that fancy operator `op`. Since the left argument is always lower than the right (no matter how you put the parenthesis in the expression) I expect it to produce an output: 1, 11, 111, 1111.

13:50 <LiliumAtratum> But I get -10000, -10000, -10000, -10000 instead

13:51 <K-ballo> ok, sounds wrong too

13:52 <LiliumAtratum> Out of curiosity I also put `hpx::cout` when the operator is invoked, and to my surprise it seems to be invoked twice, once with the expected parameters, and once with flipped parameters (which should not happen since op may be non-communatitive)

13:53 <K-ballo> I have a vague recollection of already discussing something about the scans and non-commutative operations, specifically I remember crafting tests for string concatenation

13:53 <K-ballo> uh... so what's your actual actual output then?

13:55 <LiliumAtratum> Currently: `1+0 / 0+1 / 10+1 / 1+10 / 100+11 / 11+100 / 1000+111 / 111+1000 / -10000 / -10000 / -10000/ -10000` (where `/` stands for a newline)

13:56 <LiliumAtratum> the last 4 items is the content of the `output` vector. The first 8 items are debug prints from within the `op` invocation.

13:56 <K-ballo> that sounds like something else entirely

13:57 <LiliumAtratum> While I understand the amount of `op` invocations may vary because of scheduling etc, I would still expect the contents of `output` to be correct. Which I believe should be: `1 / 11 / 111/ 1111`

14:00 <K-ballo> here are those tests https://github.com/STEllAR-GROUP/hpx/blob/master/libs/algorithms/tests/regressions/scan_non_commutative.cpp

14:01 <hkaiser> heller1: yt?

14:02 <K-ballo> seems we need those for the transform_ cases as well

14:06 <LiliumAtratum> seems so :(

14:07 <LiliumAtratum> should I file a bug at the github for this too?

14:08 <K-ballo> sure

14:23 <LiliumAtratum> done. Thank you!

14:24 <hkaiser> LiliumAtratum: I'm not sure the sacn algorihtms should support non-commutative operators

14:26 <K-ballo> they do, they are required to

14:35 <hkaiser> ok

14:35 <hkaiser> wasn't sure anymore

14:36 <hkaiser> K-ballo: the spec says GENERALIZED_\-NONCOMMUTATIVE_\-SUM

14:37 <hkaiser> so I'd assume commucativity is not required

14:38 <K-ballo> indede

14:38 <hkaiser> the algorithms require associativity, though

14:38 <K-ballo> all the parallel ones do, afair

14:38 <K-ballo> note we fixed this for the non transform_ scans a few years ago

14:38 <hkaiser> did we? ok.

14:39 <K-ballo> see above for the related regression tests

14:40 <hkaiser> ahh, see http://eel.is/c++draft/numeric.ops#numerics.defns-2

14:40 <hkaiser> so it requires commutativity after all

14:41 <hkaiser> or not :/

14:41 <hkaiser> standardeeze is obtuse, always

14:42 <hkaiser> so generalized_sum allows for the elements to be permutations, generalized_noncommucative_sum does not allow for any permutation

14:43 <hkaiser> so we can't assume commucativity of op as the sequence has to be observed

14:44 <K-ballo> noncommutative means we can't assume commutativity, yes

15:19 <diehlpk_work_> https://github.com/google/caliban

15:20 <diehlpk_work_> Caliban is a tool that helps researchers launch and track their numerical experiments in an isolated, reproducible computing environment. It was developed by machine learning researchers and engineers, and makes it easy to go from a simple prototype running on a workstation to thousands of experimental jobs running on Cloud.

15:33 <jbjnr> hkaiser: I am grumpy. The function arguments are being called - even for print<false> invocations. I need to find a way to stop that that doesn't require an extra if wrapper around the call

15:35 <jbjnr> fix - wrap arguments in a lambda - that solves it, but it's not ideal.

15:40 <hkaiser> jbjnr: using lambdas everywhere bloats code generation

15:40 <hkaiser> we have had that for assertions, but decided to stay away from it in the end

15:41 <jbjnr> and it doesn't work when ptint<true> is enabled

15:42 <jbjnr> I only need it inside my debug print statements, so I will add a delayed:: invoke wrap for arguments that are function calls, thgen specialize for that

15:42 <jbjnr> or something ....

15:42 <jbjnr> must go out in a moment, so will look into it later.

15:55 <diehlpk_work_> jbjnr, What is the status of the libfabric parcelport? We intend to submit a porposal for Piz Daint in October?

15:55 <diehlpk_work_> So we like to use libfabric for this proposal. Do you think you can get time to work on it if we submit the proposal

18:26 <bita__> https://gist.github.com/taless474/05fb593094a2eed051c94540927cf6d3

21:11 <jbjnr> diehlpk_work_: I have been working on the libfabric PP quite a lot recently, but it is still not tested on anything major like octotiger. It is functioning on my test cases, but some recent system changes on daint broke the gni layer and I need to do more testing there to see if it is working properly. It should be working well enough for you to get scaling runs for a proposal if you need them. The bug that causes octotiger to

21:11 <jbjnr> fail has not been fixed, but if I can reproduce it on daint with the latest builds of the LF PP, then I would hope to be able to fix it quite quickly. I need to get everything working soon anyway, so it would be better to get things fixed in the next weeks or so. I am working on a libfabric backend for another project and so this is a good time to get things going. Ideally I'd like to abstract most of the code into a smaller

21:11 <jbjnr> library that can be used by both projects and I'm working towards that, though they have very different use cases...

21:12 <diehlpk_work_> jbjnr, Thanks for the update

21:13 <diehlpk_work_> We would have to submit the the proposal in october

21:13 <diehlpk_work_> I am working to get Octo-Tiger with Kokkos running on SUmmit

22:09 <gonidelis[m]> any idea why the foreach tests fail?

22:10 <gonidelis[m]> actually, all algorithms tests fail

22:17 <gonidelis[m]> I run the on rostam

22:18 <gonidelis[m]> them ^^

22:28 <gonidelis[m]> That's a sample verbose output

22:29 <gonidelis[m]> "48: /home/giannis/build/foreach_adaptation/bin/foreachn_projection_test: error while loading shared libraries: libc++.so.1: cannot open shared object file: No such file or directory"

22:29 <K-ballo> missing libc++ ...?