A lot of replies here are missing the key idea behind Penrose: that the "substance" and "style" of any mathematical diagram are separable. For example, the "substance" of a diagram might be a collection of sets with known subset relationships:
Set A, B, C
IsSubset(B, A)
IsSubset(C, A)
That same substance can then be rendered in many different styles, e.g. as a Venn diagram or as a tree diagram (substance vs. style is a lot like HTML vs. CSS). Importantly, Penrose's vision is that experts will author libraries of domains and styles, and end-users need only express the substance of their diagrams (i.e. the three lines of code above).
The second beautiful idea in Penrose is that diagram generation is expressed as a constrained optimization problem. This lets you easily experiment with layouts by writing constraints and sampling a variety of potential diagrams via stochastic search.
These two ideas set Penrose apart from most other diagram software out there. I really hope it gains wider adoption. Give it a try!
Given the popularity of frameworks like TailwindCSS, it seems that people here don’t understand the advantage of separating HTML and CSS either, so I’m not sure if this analogy is helpful…
> Importantly, Penrose's vision is that experts will author libraries of domains and styles, and end-users need only express the substance of their diagrams (i.e. the three lines of code above).
In that case, would it be a good idea to start the tutorial with some predefined domains and styles? Part of the intimidation factor here is not just the programming language, but also the abstraction one is faced with using and trying to understand before seeing their first picture. If the goal is to have predefined libraries, then why not start with pre-defined domains and styles and first teach people only how to do the substance, and leave domain & style definitions for advanced tutorials?
What are the advantages of making everything a constrained optimization problem? I like the idea that I can experiment with layouts sometimes, but I don’t really want a random diagram all the time. I realize it doesn’t have to be random, I have the choice to explicitly pin things down, but that takes extra work with Penrose, I’m asking why random is the default. Having done a lot of technical diagramming in papers and books, I would expect to almost always pin things down, and maybe once in a while free up a few elements to move around. Letting the whole thing go random is rarely if ever something I’d choose, especially near the end of making a more complicated diagram. What I’m wondering is whether this design is good for experts, and why, or if it mostly helps beginners.
I recently discovered GeoGebra, and would love to hear some compare & contrast notes. It doesn’t use constrained optimization, and it does separate style from substance as needed, but in a different way than Penrose. The important feature seems to be that it lets you define the relationships between elements of the diagram, so if you move a point, the line attached follows, and then parallel and perpendicular lines attached follow, and so on, everything in the diagram becomes responsive to adapt to the change while letting you put something right where you want it. This way I still get to experiment with layouts, but nothing in the construction needs to be random. Most of the style definitions are point & click GUI actions. Are there reasons that workflow is inferior to Penrose?
Yeah, exactly! Also, possibly a third idea of Penrose is the way the selector matching blocks in the Style language can be used to construct the constrained optimization problem as you mention. This is inspired by CSS, but there are a lot of differences too.
With regard to the separation of substance and style, I think that idea can be profitably applied in other settings as well. For instance, Graphviz, tikz-cd, and Mermaid are all fairly declarative. But also, I feel like this idea could be even more profitably applied by building a diagramming library inside of a general-purpose programming language like Python.
However, as I've commented on other software like this, why are none of the examples style-free Venn diagrams? That is, black on white 3 circle overlapping each other in pairs with a single shared triangle intersection at center? I apologize if one of these is already present. Style has little value there since it may obscure reality.
Thanks so much for sharing upset given the context of my question!
Their explication of Venn diagrams is exemplary and compelling, particularly the banana and the way the Venn is elucidated and visualized through the accompanying meta-detail, for lack of a better phrase.
I cannot thank you enough. This will literally propel much of my work on data going forward.
Mermaid has been nice to use. It's very much in a beta phase still, with some odd quirks and missing documentation. I'm excited to see where it will be in a year's time.
Anyway, I think that mermaid.js have an advantage there in a lot of environments as it is supported by a lot of markdown renderers, I would like that ChatGPT one does that too.
yup but ... right now things are in a bit of a primitive state.
i have tried a lot of stuff with the ChatGPT Wolfram integration and it just fails all kinds of ways. its really cool when it works, but a lot of time it just gets really confused and cannot do basic things like "make that line black instead of red"
I looked at a random example [1], and this needs heavy rework if it needs to work as an example. I'm scared to look at other examples.
- The second half of the 900 line style file is commented out code. Ugh. Should I be learning from examples or reviewing code when I read this?
- The end if the style file define/replaces coordinates which are not defined in the substance file. Why? Isn't it the point that a substance file has all the data? All coordinates and whatnot?
Overall, it does look cool. I like the idea of distinct substance/style/domain files. I probably won't give it a spin until it looks rock solid from a distance.
It's plain text in the generally accepted definition [1] of the term. It's not a binary file that requires special software to author. It's possible to read and write the files in a text editor.
"Plain text" does not imply "natural language description", though I can see the term could be confusing.
I think they were working on an Obsidian plug-in at some point, and got some primitive functionality up, but don’t know what the state of that is currently.
So possible rendering point, though I guess falls under browser engine
I have always found "diagrams as code" tools to be limiting. There will be that scenario where the generated diagram is not what you expected. The flexibility you get by using code is outweighed by these limiting scenarios. I switched to Mermaid.js but ended up switching back to normal diagramming tools because of these limitations.
Our team uses diagrams-as-code (plantUML) to document processes, interactions, and state machines. Because our use case is functional, they don't have to look good - just good enough and understandable.
Some reasons on why we still use them: (1) They're source-control friendly. And (2) in some cases, we could generate them directly from code. We deal with a lot of state machines on embedded devices, and whenever management asks for "documentation", we run a transformer script that consumes the source code and spits out state diagrams that would placate them.
I think the point of those tools is to abandon the idea that one needs full say over every aspect of a diagram. Or even that all diagrams must be done in one tool - the most flexible one. Having more version-controlled documentation next to code is only a plus to me.
Right; there seem to be cross-cutting benefits and drawbacks for declarative text-based specification of diagrams vs direct manipulation. One research project exploring this tension is Sketch-n-Sketch https://ravichugh.github.io/sketch-n-sketch/ which tries to combine both together in a single system via bidirectional programming. We've been wanting to explore similar ideas more in Penrose, but it's definitely challenging.
Barring bidirectionality, another possibility could just be to make it easier to integrate Penrose into existing workflows; for instance, if you're writing a LaTeX document then it'd be nice to have a package for Penrose diagrams rather than having to switch back and forth between your LaTeX editing environment and the Penrose editor.
But then, let's say you make a Penrose diagram and you want to tweak it in Illustrator to make it look better, because as you mentioned, the text-based input modality of Penrose is limited. So we could try to make it smoother to export Penrose diagrams to put in Illustrator. You edit the diagram and add it to your LaTeX document. But now, you decide you want to make a tweak to the original diagram by modifying the Penrose source code. This obliterates any changes you made in Illustrator, so now you have to manually repeat the tweaks you already made.
I'm not really sure what the best solution is... it seems hard to have a good workflow story without either being entirely text-based, supporting bidirectionality, or forcing a lot of repetitive manual rework when edits are made.
I also find them limiting if I want to diagram something from my brain. However I found them splendid for drawing logs, the internal state of my software, or other data. Sometimes it's great to just printf() stuff in a format that can be drawn.
Same here. My problem is that I consider these diagrams to be low value documentation gimmick. They are nice but not really worth spending a lot of time on.
The promise of text driven diagrams is that you don't spend a lot of time on them. Which is nice. But of course then you run in a brick wall when it's not that nice to look at and you want to fix it and it turns out that there are a lot of things that you just can't do with them.
And of course the real problem is that if it's simple, it probably doesn't need a diagram at all (or it will just state the bleeding obvious). And if it's not simple, the diagram is probably going to be a PITA to get right no matter what tool you use. Especially if you are not sure what the diagram is going to be exactly. These tools are almost universally horrible for sketching stuff out quickly because you get sucked into doing a depth first let's specify everything and the kitchen sink mode. And then you get it wrong and it's a pain to change everything. My brain just works a couple of orders of magnitude faster than most of these tools and I get frustrated with just spending ages on the stuff I already understand (i.e. the stuff that I already know the design for) vs. the stuff I'm still unsure about (i.e. the hard to diagram stuff). As a design tool these are horrible tools. As a documentation tool they are mostly redundant.
I default to just skip diagramming it entirely. I don't enjoy it. I don't believe in it. I usually have better things to do. I find the output is write only: nobody ever looks at it or appreciates it beyond a "ah cool, we have stuff". I've found extremely few counter examples in my decades long career of diagrams that actually add value and are widely appreciated. It's mostly just endless nonsense of trivial amounts of boxes and arrows connected in mostly unsurprising and obvious ways.
If I need something quick and dirty, whiteboards are much nicer. And you can just take a photo and call it a day. And in my experience, nobody ever looks at those either. Those photos have very little value. You draw something on a whiteboard, you use it as a talking point, and then you wipe the whiteboard. Photo optional. Do it if it makes you feel good. You could spend a lot of time translating those into a pretty diagrams. But that sounds like the kind of monkey work that somebody should automate and that you shouldn't be spending time on.
Mermaid.js is pretty great, but I agree you usually get to something that doesn't express nicely. I was hoping to find a graph language I might be able to tweak into a DSL. Mermaid is easy to onboard and get things done with but then it didn't quite cover what I wanted to achieve.
I'm not against learning things, I'm against learning how to fiddle with css to make a diagram. that is not the right tool for the job imo, i want something i can use to knock out diagrams with quickly and easily. canva & excel are already passable
> In mathematics and physics, Penrose graphical notation or tensor diagram notation is a (usually handwritten) visual depiction of multilinear functions or tensors proposed by Roger Penrose in 1971.[1] A diagram in the notation consists of several shapes linked together by lines.
Penrose graphical notation (tensor diagram notation) of a matrix product state of five particles
The notation widely appears in modern quantum theory, particularly in matrix product states and quantum circuits. In particular, Categorical quantum mechanics which includes ZX-calculus is a fully comprehensive reformulation of quantum theory in terms of Penrose diagrams, and is now widely used in quantum industry.
> The notation has been studied extensively by Predrag Cvitanović, who used it, along with Feynman's diagrams and other related notations in developing "birdtracks", a group-theoretical diagram to classify the classical Lie groups.[2] Penrose's notation has also been generalized using representation theory to spin networks in physics, and with the presence of matrix groups to trace diagrams in linear algebra.
This feels like the LaTeX version of Mermaid.js [0]. I can do anything with it, but I gotta learn a lot of new syntax. So, really cool! Gonna have to dig into this.
Is this actually affiliated with Roger Penrose? Seems extraordinarily rude to use his name otherwise. Was his permission sought? In fact, this may be seen as "passing off" in English law.
Not affiliated with Roger Penrose; we often hear this question about our project name: https://news.ycombinator.com/item?id=36749211 As Nimo mentioned in a response to that linked thread, we're open to suggestions for alternate names if a different one would better suit the project!
At first I thought that he actually had something to do with it!
To simply borrow his name is indeed, I think, in pretty poor taste. The trend of naming unrelated products after scientists and inventors (from "Tesla" and "Nikola," to Theranos' "Edison," to "Ada Lovelace," and so forth,) has become unbelievably low-effort and cringe.
Yes, but his name is the obvious one. If I say "Dyson" and you're in the UK, you think of vacuums, "Penrose" and you think of Mathematical Physics.
I doubt this would come to court. The main problem is the temerity of using the name of a living person in this way. But, they could have sought permission, in which case, all is well.
I'm sufficiently nerdy to think "Sphere" whenever the name Dyson comes up, but I'm sure that to most normal people even "Dyson sphere" will mean one of these rather than a K2 civilisation: https://www.dyson.co.uk/vacuum-cleaners/uprights/ball-animal...
Neither Ada Lovelace nor Haskell Curry is still alive. And Python is in a different category.
It's one thing to use the name of a historical figure, quite another to use the recognisable mark of a living person.
Of course, it could all be being done with endorsement, in which case, my comment is invalid, but otherwise it's incredibly rude and a borderline civil tort.
I also believe that passing off requires a demonstration of a substantial amount of probable damage in the future. The mere existence of a graphical software named Penrose can't do much harm. (If you name a malware after Penrose, that may be the case though.)
Generating diagrams with plain text notation is a game-changer! The simplicity of using text on cmu.edu to create diagrams enhances accessibility and collaboration. It streamlines the process, making visual representation effortless. A fantastic tool for those who want efficiency without compromising on clarity and precision in diagram creation.
I feel like a lot of people are not aware of the tools that are available and they keep building the same thing over and over... or, the other amazing thing missing a feature and this thing now has this feature but lacks completeness of other etc, etc...
Which means we are doing two things bad: composability and informing us.
My MetaPost-ed head hurts a bit while looking at three different files to generate one drawing - can't help it, MetaPost feels like writing in prose. Can't tell if they share the same syntax, but it's interesting that most of it looks like CSS with superpowers
True! Splitting every single diagram into three files feels quite heavy. For Penrose version 4.0, we're planning to combine all our DSLs into one so that they can be mixed together in one file.
I did take a look at the gallery. Penrose is no alternative for the majority of diagrams I can do with mermaid or D2, right? It's more about "mathematical" diagrams instead of ER, UML or EPKs right?
Pic is wonderful! I think what's lacking the most is modern tool integration. It more or less requires troff which is itself somewhat deprecated. I've always thought that extracting pic as standalone tool with ~modern output objects would be a nice project for once I quit being lazy :)
You can do animations with PGF/tikz, the problem is you can do everything with PGF/tikz and so the whole thing is a bit of a chaotic mess. The diagrams are beautiful but the code makes me very sad.
Yeah, this is unfortunately a big pain point right now. Every time you click "compile" we allocate a new Wasm memory to use for running the optimizer. But garbage collectors in current browsers get confused when there are lots of these large Wasm memories floating around; I'm not entirely sure why, but I think it's because the GC engine doesn't correctly conceptualize how big the Wasm memories actually are, so they don't try to collect them as aggressively as they should. We're currently seeing if we can alleviate this issue by reusing the Wasm memory from compile to compile, but that's a bit tricky in the presence of concurrency (we're also trying to move computation from the main thread into a web worker). In future versions, we might try to sidestep this issue by just using the new Wasm GC that landed in Chrome recently, but for that we'd probably have to wait a bit longer until it's also supported in, e.g., mobile Safari.
Yeah :( To be honest, I think we got a bit overeager about this one, since none of us on the project are chemistry experts. At least for the front page, we should probably replace that with a different diagram from our registry.
I think this is actually a fairly deep issue with our approach where we try to express everything in terms of numerical optimization, pairwise energies on shapes, etc. Especially since Style is not a Turing-complete programming language and also doesn't support calling out to existing libraries written in, e.g., JavaScript, there isn't a way to do actually-correct layout of the caffeine molecule, so instead we do the "lazy" thing and just try to make the atoms not overlap. To anyone who actually knows what a caffeine molecule looks like, obviously this looks ridiculous.
In the same vein as the other HN comment about separation of substance and style, I think we could do a much better job on chemistry diagrams by actually placing the atoms where they should be in 3D space, then projecting onto a 2D SVG diagram. To illustrate what I mean, consider this other diagram in our registry, showing a methane combustion reaction: https://penrose.cs.cmu.edu/try/?examples=structural-formula/...
The combustion diagram does look nicer, since it doesn't contain complex overlaps of bonds. However, it's still physically inaccurate. The carbon dioxide molecule should be linear, for example. Molecules have atoms arranged following very specific rules arising from quantum mechanics and the theory of molecular orbitals, you can't solve this with a graph optimization algorithm.
Could you clarify what you mean when you say "it's still physically inaccurate" and "The carbon dioxide molecule should be linear"? In my post I was specifically contrasting the diagram in the Penrose registry (in which the carbon dioxide molecule is incorrect as you point out) with another version of that diagram which I generated using Python (in which the carbon dioxide molecule is correct). Did you only look at the one and not the other, perhaps?
It's completely, utterly wrong. To point out just one problem, the two central rings should be planar. Good thing they picked this one to show in the landing page carousel. That example was enough for me to close the page again.
Set A, B, C
IsSubset(B, A)
IsSubset(C, A)
That same substance can then be rendered in many different styles, e.g. as a Venn diagram or as a tree diagram (substance vs. style is a lot like HTML vs. CSS). Importantly, Penrose's vision is that experts will author libraries of domains and styles, and end-users need only express the substance of their diagrams (i.e. the three lines of code above).
The second beautiful idea in Penrose is that diagram generation is expressed as a constrained optimization problem. This lets you easily experiment with layouts by writing constraints and sampling a variety of potential diagrams via stochastic search.
These two ideas set Penrose apart from most other diagram software out there. I really hope it gains wider adoption. Give it a try!