Thank you for your quick review. Just updated the code comments.

I think this is quite nice - plotly has always been fairly difficult for me to install (particularly to get them to show up in jupyter).

Great, you've already implemented several of them. I'm just curious what the scope of this PR is. I believe we should also discuss how to introduce the matplotlib dependency and how to expose these features to the user. The sooner the better?

Yes, we should discuss how to bring features to users. Sooner is better.

The scope of this PR itself is to implement the matplotlib backend as internal functions.
#1539 (comment)

Did you plan to cover all of them? I'm wondering if some visualization functions aren't somewhat tricky to implement, such as the parallel coordinate plot. As you've already done a great job implementing several of the existing functions, how about moving on to designing the public API? I think we can cover the logic for how Optuna should behave when a function is not implemented with either library there, and then work on the visualization functions one by one. Having separate PRs for each one would make reviewing easier as well, which presumably would benefit us all.

Thank you for your comments.

1. Scope

Did you plan to cover all of them?

Yes, I intend to implement all the functions with matplotlib backend in this PR.

2. Point of dev focus

how about moving on to designing the public API? I think we can cover the logic for how Optuna should behave when a function is not implemented with either library there, and then work on the visualization functions one by one.

I'm confused. @toshihikoyanase commented in issue #1539 as follows:

how about just keeping the current API for now and adding a matplotlib version of get_optimization_history? It may be an internal function in the first PR, and then we can discuss how to make it public in the second PR.

On the other hand, in my understanding, your suggestion is to stop implementing matplotlib backend functions now and to start thinking about the modification of current APIs (e.g. plot_optimization_history) first. Please correct if I misunderstand.

3. PR size

Having separate PRs for each one would make reviewing easier as well, which presumably would benefit us all.

OK, I close this PR and will instead make separate PRs later.

I’m sorry if my comment confused you, it was just an idea to open up a discussion. Let me try to make up for it.

First and foremost, you don’t have to close this PR. Instead, we could continue working on this one to discuss the public API.
Once that is fixed/this PR is merged. We can continue implementing the remaining visualization functions.

What do you think @toshihikoyanase, @ytknzw?

Some approaches for how we could go about designing the public API.

1. Introduce a “backend” parameter to existing visualization functions.
   • User must consider the argument in each call, implementation becomes somewhat complicated, and the return value becomes a Union.
2. Define a global/thread local state.
   • User only have to configure it once. Other cons remain. We introduce a global state.
3. Introduce optuna.visualization.matplotlib to define plot_*
   • User switched between backends by changing the top import statement(s). Pro that we don’t have to keep a global state, code is clearly separated. What functions are implemented in what backend becomes very clear. Return value is not a Union.

I would suggest 3., as you might have noticed. And if so, changes required from this PR are not that large and we could incorporate them here.

@ytknzw @hvy I'm sorry for confusing you. When I suggested separating the PRs, we didn't have implementation and I couldn't imagine the pros & cons of the Interface choices. Now, thanks to the hard work of @ytknzw , we have three visualization functions and IMO, we can discuss the interface now.

@hvy Thank you for your comments on the interface. I agree with your suggestion to introduce optuna.visualization.matplotlib. It doesn't affect existing code, and we may be able to build the implementation based on the first and second approaches on top of it. In addition, I don't think it requires more code changes than the other approaches (I think (1) add public plot functions, (2) create the sub module directory, and move the files).

@ytknzw I'm really sorry for changing my mind, but I think we can keep this PR and add a few changes to create the minimum public interface. What do you think?

@hvy @toshihikoyanase Thank you for clarifications and sorry for my slow reply! I agree with you two. To introduce optuna.visualization.matplotlib would be the best option.
Let me try it in this PR, or another PR is better for review?

Not slow at all, thanks for taking your time.

Let me try it in this PR, or another PR is better for review?

I'm fine with either. What do you feel more comfortable with?

It would be easier to focus on the implementation/review if we create different PRs, one for fixing the API, followed by PRs for implementing the graphics. It's not a strong opinion.

Thanks. I agree with your points. Modifying API and implementing matplotlib backend are different tasks. I'll creat another PR for optuna.visualization.matplotlib.

Thanks, @ytknzw for the great work for plotting functions! I'm very excited to merge these functions into Optuna. I will check and review this and subsequent PRs.

@HideakiImamura
Thank you!
Unfortunately, the API structure in #1756 is now largely changed from this PR, so I close this PR and instead create 1 PR for each graph style (function) based on #1756 .