Rare Q&A "Visualization and Graphics" session from Wolfram R&D, some are members of this community

Question

In a rare virtual event, Wolfram R&D developers (some are old-timers, who also are members of this community) will go live for Q&A session about one of the most popular topics Visualization and Graphics. You know something is in demand if it has a tag like THIS. We are trying to gather important questions PRE-event from our global user community so our R&D leaders can address what is most important to you. Whether you will be interacting in the live event or watching the recording after - I think you will appreciate if your interests were addressed.

Details of the event are here: https://community.wolfram.com/groups/-/m/t/2618033

Please express your wishes via commenting (and voting) here or on the Wolfram Community thread I linked. We would be very happy to see you joining the live event and/or contributing ideas for the discussion.

Answer 1

Too long for a comment, so here it goes.

First, thanks for the prompt to submit questions for the Visualization and Graphics developers.

Post processing

One of the things that bothers me about the visualization outputs of Wolfram Mathematica is that they are not easy to parse post production.

From the completely abandoned FullGraphics (Try FullGraphics@Plot[x,{x,0,1}] to see it fail. Function introduced in 1991, v2.0 but malfunctioning and abandoned at least since v6.0) to the very untidy vector graphics output (Try to make sense of ExportString[Plot[x, {x,0,1}, PlotLabel -> "Test string"],"SVG"]).

A reasonable assumption is that Wolfram can not possible implement all the features one may want in a visualization procedure. Consequently, it would be desirable that the outputs should be simple and well-structured to facilitate further manipulation.

However, that is not what we see. In my examples I would expect FullGraphics to not be broken, and Export to produce elements that are properly labelled and grouped (Background, foreground, axis, labels, traces) and with low-level access to the format features, like metadata, annotations and so on.

So the question is:

"Can we expect that future development will facilitate post-processing of Visualization and Graphics outputs?"

---

Details

SVG

If it's not clear what the issue is with most vector outputs, particularly SVG (An XML format) is that elements have meaningless labels, they are not grouped, statements are not very economic, text is transformed to curves by default.

FullGraphics

Known issue for long time, I reported it to Wolfram Support back in 2017 [CASE:3897155]. Was discussed on "Live CEOing (239): Graphics Framework for #WolfLang"

Answer 2

These aren't questions, but (not necessarily good) feature requests, the devs are welcome to discuss them if they'd like:

1. A builtin for converting Labeled and Legended (and similar) expressions to true Graphics objects, its frustrating that almost all visual things can be converted to Graphics.
2. Some sort of Visualization Tools that would allow you to make quick changes to a plot without having to reexecute the (often expensive code). Bonus points if it can export the code that would result in those changes to the plot (ie if you add a y-axis label to the vertical axis of a plot produced with Plot[x^2, {x, -1, 1}] it would export Plot[x^2, {x, -1, 1}, Frame -> True, FrameLabel -> {{"one", ""}, {"", ""}}]).
3. Make ResourceFunction["InteractiveGraphics"] a builtin. Bonus: just export to an external viewer that can handle larger amounts of data faster.
4. An explicit option in Plot and all other plotting functions to make text scale with the size of the plot, make this

Plot[x^2, {x, -1, 1}, Frame -> True, 
 FrameLabel -> 
  Map[Text[Style[#, FontSize -> Scaled[0.05]]] &, {{"left", 
     "right"}, {"bottom", "top"}}, {2}]]

be doable with just

Plot[x^2, {x, -1, 1}, Frame -> True, 
 FrameLabel -> {{"left", "right"}, {"bottom", "top"}}, 
 TextScaling -> True]

Similarly for the tick labels* and even any text included as an inset or something. I think the general expectation when working with an SVG like format is that the text will act like any other law abiding member of the image and scale proportionally to the image size, I'm kinda surprised MMA doesn't do this by default.

I have some friends who use Matlab and its kinda hard to argue MMA's graces when it can't do 2 and 3 out of the box and is slow for thousands of data points.

---

• Heres code that accomplishes this

autolabel[newstyle_] := Module[{framelabel},
   framelabel[{x0_, label : Except[_Spacer], {plen_, mlen_}, style_}] := {x0, newstyle[label], {plen, mlen}, style};
   framelabel[{x0_, label : Except[_Spacer], {plen_, mlen_}}] := {x0, newstyle[label], {plen, mlen}}; 
   framelabel[tick_] := tick;
   framelabel /@ Charting`ScaledTicks[{Identity, Identity}][#1, #2, {5, 5}]&
];

style[size_] := Text[Style[#1, Black, FontFamily -> "Arial", FontSize -> Scaled[size]]] &;
axisLabelStyle = style[0.03];
tickLabelStyle = style[0.03];

Plot[x^2, {x, -1, 1}, Frame -> True, 
 FrameTicks -> {{autolabel[style[0.03]], True}, {autolabel[style[0.03]], True}}]

While I'm at it I'll mention the docs for FrameTicks doesn't mention in the Details section that FrameTicks can accept a function as it does in the Generalizations and Extensions section.

Answer 3

Plot[x^2, {x, -2, 2}] == Plot[x^2, {x, -2, 2}] used to evaluate to True. So did Plot[x^2, {x, -2, 2}] === Plot[x^2, {x, -2, 2}].

How can I get them to evaluate to True?

---

NIntegrate[{x, xx^2}, {x, -2, 2}] issues a NIntegrate::inumr message; but Plot[{x, xx^2}, {x, -2, 2}] does not issue any message.

Is there a message that can be turned On[] so that Plot[] generates a warning if, say, it cannot generate at least one line segment to plot for some of the functions being plotted?

Answer 4

Symbolic region arithmetic

Full disclosure, I have not used v13, which means I have not tried CSGRegion and other new functions. Please let me know if v13 has already resolved my feedback, and if so to what degree it has been implemented.

---

It would be magical if such an input

RegionIntersection[Disk[{0,0},a],Disk[{1,0},a]]

yielded something like

Piecewise@{
  {EmptyRegion@2,a<1/2},
  {Point@{1/2,0},a==1/2},
  {RegionUnion[
    DiskSegment[{0,0},a,{-#,#}],
    DiskSegment[{1,0},a,{\[Pi]-#,\[Pi]+#}]
  ]&@ArcCos[1/(2a)],a>1/2}
}

or for more general symbolic regions. Imagine explicit piecewise Sphere-Sphere-Sphere intersections being represented as exact region unions of SphereSegment's (even the 2d case of arbitrary Disk multiple intersections is difficult, but possible).

A different example would be to derive conditions for line/line intersections, i.e.

RegionIntersection[Line@{a,b},Line@{c,d}]

could yield an explicit Cases for when the result is a Point or EmptyRegion or a Line segment, I think I'll add a full example in a day.

Honestly, I believe that such meticulous and case-involved work would be a huge step towards rhermans goal of simplified internal graphics presentations.

Reduce already does generate conditions in most cases, and to be honest I'm not really sure what explicit benefits are had by identifying in particular which cases are Lines/Points/Empty... vs just letting the result be a big logical condition of parameters. That's not to say there are no benefits (and maybe a strategy which attempts to recover graphics primitives from Reduce outputs would be more fruitful); I simply haven't thought enough about this topic.

Answer 5

Plotting functions supports has many options. When setting for PlotLayout to "Rows" or "Columns" then plots are shown separated in a grid (like MATLAB's subplot), which presents the issue of how to apply options to a subset of the generated plots. This seems to be supported now only for PlotLabels under ListPlot usage.

Is it planned to make other options work on specific plots when using PlotLayout to "Rows" or "Columns"?

UPDATE: Question addendum: We now have a MultiaxisArrangement option but it seems that it is incompatible with the setting PlotLayout to "Rows" or "Columns". Is there any plan to make this work together? Making a grid of multiaxis plots is not an uncommon need.