Additional settings for plot_surface.

[mdaley]

I wanted to be able to do more with the surface plot. What I've done here is add the ability to set different types of settings - boolean, float, int, string - as the additional arguments for the surface plot. So, this allows you to do things like:

• set any color map for the surface,
• set the cstride and rstride (i.e. the size of the segments of the surface)
• set line width, type and color for those segments
• set transparency for the surface
• set other things (whatever they are as long as they are of the types I've implemented so far).

The things that can now be set I removed from being hardcoded in the code.

An example of what can now be done is:

    map<string, plt::SettingValue> settings;

    settings.insert({"edgecolor", plt::SettingValue(string("black"))});
    settings.insert({"linewidth", plt::SettingValue(2.0f)});
    settings.insert({"linestyle", plt::SettingValue(string("--"))});
    settings.insert({"alpha", plt::SettingValue(0.5f)});
    settings.insert({"rstride", plt::SettingValue(10)});
    settings.insert({"cstride", plt::SettingValue(10)});
    settings.insert({"cmap", plt::SettingValue(string("gist_rainbow"))});

    plt::plot_surface(a, b, c, settings);
    plt::show();

Is it just me or is the formatting of the matplotlibcpp.h files rather messed up at the moment. I didn't change this but I think it should be.

Oh, and finally, I'm mainly a Java and clojure programer. All this C++ stuff is new to me, so please tell me whatever needs to be different to be more idiomatic...

[mdaley]

[mdaley]

That's an example of an improved surface plot image.

[mdaley]

An alternative: pass in all settings in a stringmap; have some code that knows all of the keys that have float values and transforms them before putting them into kwargs, same for boolean values, same for ints, etc... Advantages: no change to existing interface, simpler code for users, disadvantantages: less flexible, more hard coding, easy to miss some settings out.

[Cryoris]

I agree, this is much needed functionality. But the SettingValue solution is quite verbose, especially if you also have to wrap the string type.

As every function currently converts the map to a PyDict at the moment, which should probably we exported to its own function, I think your second suggested solution would fit well and would be closer to the Python behaviour of matplotlib.
To add flexibility, the methods could override some of the kwarg-name-to-type mappings.

[mdaley]

I'll have a go at that at some point. However, for the moment, I'm seeing what VTK will give me in terms of graphing. It seems to be very capable - if hard to use perhaps - and does other imaging things that I'm interested in.

[Bidibulke]

Hi, @mdaley.

Did you take a look at pull-request #166 ? I use a tuple of variadic templates to do quite the same thing. The code in C++ is very readable. I didn't have it for the plot_surface at the moment but It's easy to develop it. If you are interested in, please tell me, I'll be glad to do it.

[mdaley]

@Bidibulke that certainly sounds interesting if you are up for it. I expect it would be very helpful to others.

[Cryoris]

Since this seems like a lot of code it would be nice to get feedback from @lava to see if this is something that could be included.

[Bidibulke]

I began development before seeing your post @Cryoris .
I updated my branch just to show to @lava that it could be insert in matplotlibcpp without a huge cost: the function's body is mutualised between existing function and the new one.
@mdaley @Cryoris I added plot_surface and imshow with this new arguments.

[lava]

Hey, sorry for being a bit late to the party here. I basically agree with most of what was said, that is:

1. We certainly need something like this
2. Ideally, the solution would be backwards-compatible, so we can eventually enable it for all functions and no working code breaks when updating the library.

I was thinking that maybe a good path would be to take a bit of both PRs make a struct that has:

• implicit constructor from map<string, string>
• implicit constructor from initializer_list<pair<string, string>>
• implicit constructor from, e.g., struct matplotlib::kwarg where kwarg would have some constructor of factory function that can do all the template magic to dispatch on the correct type etc.

@Cryoris @Bidibulke @mdaley wdyt?

[mdaley]

Hi, I don't have time to do any of this at the moment. And I've started playing with VKT instead. It's only a spare time thing for me. If any of what I've tried is useful please feel free to reuse it, although I expect given my lack of C++ experience there are better ways of doing things... Matt

…

On Wed, Jun 17, 2020 at 6:59 PM Benno Evers ***@***.***> wrote: Hey, sorry for being a bit late to the party here. I basically agree with most of what was said, that is: 1. We certainly need something like this 2. Ideally, the solution would be backwards-compatible, so we can eventually enable it for *all* functions and no working code breaks when updating the library. I was thinking that maybe a good path would be to take a bit of both PRs make a struct that has: - implicit constructor from map<string, string> - implicit constructor from initializer_list<pair<string, string>> - implicit constructor from, e.g., struct matplotlib::kwarg where kwarg would have some constructor of factory function that can do all the template magic to dispatch on the correct type etc. @Cryoris <https://github.com/Cryoris> @Bidibulke <https://github.com/Bidibulke> @mdaley <https://github.com/mdaley> wdyt? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#184 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRAEOHSNSAKNCEYIIU3N3RXD76VANCNFSM4MS52FDQ> .

[Bidibulke]

Hi all,

That's a good idea : having a flexible API without breaking anything. For the moment, I don't know how mix everything (specifically for the implicit constructor for tuple<Args...>) in a efficient and elegant way, I'm gonna think about it.
Is it possible to use C++17 features (with some #ifdef around it of course) ?