# Testing map\_rect & its implementations

**URL:** <https://discourse.mc-stan.org/t/testing-map-rect-its-implementations/3333>\
**Category:** Developers\
**Created:** [February 17, 2018, 11:47am UTC](https://discourse.mc-stan.org/t/testing-map-rect-its-implementations/3333 "2018-02-17T11:47:51Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![wds15](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wds15/32/908_2.png) [@wds15](https://discourse.mc-stan.org/u/wds15)\
**Post date:** [February 17, 2018, 11:47am UTC](https://discourse.mc-stan.org/t/testing-map-rect-its-implementations/3333/1 "2018-02-17T11:47:51Z")

</div>

Hi!

I would like to start implementing tests for the map\_rect along with the usual input checking of the inputs to the function and I was wondering how to do it most efficiently. So the structure of the code is roughly as

```
map_rect(...input...) {
#ifdef STAN_HAS_MPI
  return (map_rect_mpi(...input...));
#else
  return (map_rect_serial(...input...));
#endif
}

```

The question I have are

- Can I put the input checking code inside `map_rect` only? This would mean that `map_rect_mpi` and `map_rect_serial` would always expect that the input given is already correct.
- If the answer to above is “yes” =\> should I move the `_mpi` and `_serial` flavor into our `internal` namespace?
- Should the answer to the above be “no” =\> may I then at least write the tests which check that a wrong input is being rejected only once, but basically ensure that the same code gets compiled once with `STAN_HAS_MPI` and once without?

Other proposals to make this efficient?

Thanks!

Best,  
Sebastian

---

<div class="post-metadata">

**Author:** ![Bob\_Carpenter](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bob_carpenter/32/9230_2.png) [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)\
**Post date:** [February 18, 2018, 12:17am UTC](https://discourse.mc-stan.org/t/testing-map-rect-its-implementations/3333/2 "2018-02-18T00:17:54Z")

</div>

Which branch are you working on? I see a bunch of MPI branches and now don’t know which one to base the language changes on.

> [@wds15](#):
>
> Can I put the input checking code inside map\_rect only?

Yes, that is the right thing to do. Only check user inputs once, then it’s up to the programmer to keep everything correct on the inside.

> [@wds15](#):
>
> should I move the \_mpi and \_serial flavor into our internal namespace?

Yes, that sounds reasonable.

> [@wds15](#):
>
> Other proposals to make this efficient?

Hopefully this won’t be too hard to test beyond config. Ideally, you’ll be able to have a single set of tests that applies to both serial and MPI with the flip of a config switch somehow.

---

<div class="post-metadata">

**Author:** ![wds15](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wds15/32/908_2.png) [@wds15](https://discourse.mc-stan.org/u/wds15)\
**Post date:** [February 18, 2018, 5:10pm UTC](https://discourse.mc-stan.org/t/testing-map-rect-its-implementations/3333/3 "2018-02-18T17:10:16Z")

</div>

Great. Makes all sense to me. The switch will be a compile time switch, but we can manage that in the tests.

> [@Bob\_Carpenter](#):
>
> Which branch are you working on? I see a bunch of MPI branches and now don’t know which one to base the language changes on.

The one with the serial version of `map_rect` is here:

[https://github.com/stan-dev/math/tree/feature/issue-686-map\_rect\_serial](https://github.com/stan-dev/math/tree/feature/issue-686-map_rect_serial)

---

<div class="post-metadata">

**Author:** ![Bob\_Carpenter](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bob_carpenter/32/9230_2.png) [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)\
**Post date:** [February 19, 2018, 1:04am UTC](https://discourse.mc-stan.org/t/testing-map-rect-its-implementations/3333/4 "2018-02-19T01:04:08Z")

</div>

I’m working through the code that’s there now in `feature/issue-686-map_rect_serial` and I see usages of things I don’t understand.

You have

```
#pragma once

```

at the beginning of the `hard_work.hpp` test functor include. I looked it up and it’s a widely supported, but non-standard replacement for header guards. I don’t think we want to go down the route of using non-standard pragmas. Maybe @syclik has an opinion.

On another note, in the actual `map_rect.hpp` file in `prim`, what is

```
#define STAN_REGISTER_MAP_RECT(CALLID, FUNCTOR)

```

doing? I couldn’t find `STAN_REGISTER_MAP_RECT` used anywhere. Something like this probably needs doc.

---

<div class="post-metadata">

**Author:** ![wds15](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wds15/32/908_2.png) [@wds15](https://discourse.mc-stan.org/u/wds15)\
**Post date:** [February 19, 2018, 9:54am UTC](https://discourse.mc-stan.org/t/testing-map-rect-its-implementations/3333/5 "2018-02-19T09:54:25Z")

</div>

The pragma once needs to be replaced, yes.

The macro definition is left empty on purpose. The parser needs to add a call to the macro for every call of map rect. For the mpi case the macro is redefined to inject the required code which registers the map rect call with the boost serialization library which is needed to trigger remote calls of the function. This needs to be documented, of course.

---

<div class="post-metadata">

**Author:** ![wds15](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wds15/32/908_2.png) [@wds15](https://discourse.mc-stan.org/u/wds15)\
**Post date:** [February 24, 2018, 2:19pm UTC](https://discourse.mc-stan.org/t/testing-map-rect-its-implementations/3333/6 "2018-02-24T14:19:58Z")

</div>

I have started to add the usual checking logic to the `map_rect` function along with tests.

Is there a testing framework which you think I can use to check the `rev` part of the function? I remember there is a finite diff testing framework, but I have never used it.

---

<div class="post-metadata">

**Author:** ![Bob\_Carpenter](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bob_carpenter/32/9230_2.png) [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)\
**Post date:** [February 27, 2018, 7:09am UTC](https://discourse.mc-stan.org/t/testing-map-rect-its-implementations/3333/7 "2018-02-27T07:09:16Z")

</div>

The testing framework is really just for univariate functions.

For this, it’s easy to implement the mapped function directly, so I’d just use that to compare rather than finite differences (though you could use finite differences). Both the finite diffs and autodiff are available as functionals (e.g., gradient, hessian, etc.).