Additional settings for plot_surface. by mdaley · Pull Request #184 · lava/matplotlib-cpp

mdaley · 2020-04-28T15:29:08Z

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 · 2020-04-28T15:31:08Z

mdaley · 2020-04-28T15:31:39Z

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

mdaley · 2020-05-11T06:21:14Z

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 · 2020-05-23T20:50:16Z

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 · 2020-05-24T16:08:12Z

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 · 2020-06-04T13:33:07Z

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 · 2020-06-04T16:51:34Z

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

Cryoris · 2020-06-05T09:32:37Z

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 · 2020-06-09T09:00:03Z

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 · 2020-06-17T17:58:52Z

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

We certainly need something like this
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 · 2020-06-17T20:34:02Z

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 · 2020-06-19T08:10:43Z

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) ?

Additional settings for plot_surface.

26577e8

mdaley added 2 commits April 28, 2020 17:00

Changed string to std::string in a few places.

45eb4aa

Some additions to .gitignore.

13e6ba5

Cryoris mentioned this pull request May 25, 2020

Unable/unclear to use keyword 'extent' with imshow #192

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Additional settings for plot_surface.#184

Additional settings for plot_surface.#184
mdaley wants to merge 3 commits intolava:masterfrom
mdaley:master

mdaley commented Apr 28, 2020

Uh oh!

mdaley commented Apr 28, 2020

Uh oh!

mdaley commented Apr 28, 2020

Uh oh!

mdaley commented May 11, 2020

Uh oh!

Cryoris commented May 23, 2020

Uh oh!

mdaley commented May 24, 2020

Uh oh!

Bidibulke commented Jun 4, 2020

Uh oh!

mdaley commented Jun 4, 2020

Uh oh!

Cryoris commented Jun 5, 2020

Uh oh!

Bidibulke commented Jun 9, 2020

Uh oh!

lava commented Jun 17, 2020

Uh oh!

mdaley commented Jun 17, 2020 via email

Uh oh!

Bidibulke commented Jun 19, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

mdaley commented Apr 28, 2020

Uh oh!

mdaley commented Apr 28, 2020

Uh oh!

mdaley commented Apr 28, 2020

Uh oh!

mdaley commented May 11, 2020

Uh oh!

Cryoris commented May 23, 2020

Uh oh!

mdaley commented May 24, 2020

Uh oh!

Bidibulke commented Jun 4, 2020

Uh oh!

mdaley commented Jun 4, 2020

Uh oh!

Cryoris commented Jun 5, 2020

Uh oh!

Bidibulke commented Jun 9, 2020

Uh oh!

lava commented Jun 17, 2020

Uh oh!

mdaley commented Jun 17, 2020 via email

Uh oh!

Bidibulke commented Jun 19, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants