Sure! The core of the concept is just building up a library of differentiable constraints you might like to apply to a graph and then mixing and matching (including higher/lower weights on some of the constraints) according to the human intuition you have about the graph you'd like to display.

- Suppose you want the graph to roughly fit on a page, being neither too big nor too small. This is the basic force-directed graph constraint (edges pull nodes together, all pairs of nodes push each other apart). It's often sub-par by itself because it doesn't explicitly do anything interesting with labels or edges and because it tends to emphasize local clusters while letting the rest of the graph remain fairly busy. If you _want_ to spot clusters and don't care much about other edges (maybe in disease tracking for example), that might not be a bad final result, but it's more useful as a building block onto which you can tack on other behaviors.

- Suppose the graph has meaningful topology you want to highlight. E.g., you've done a topological level sort on a DAG and want nodes in the same level to be closer to each other than nodes in other levels. Add an error term pulling nodes in the same level together. The above force-directed constraint will then handle the rest of the layout.

- Laying out nodes is a bit different from laying out edges. If you model your edges as something curvy and differentiable (splines aren't a bad choice, though perhaps add a term minimizing wiggliness too), you can add an error term penalizing too much "busyness" in the graph, e.g. by saying that it's good if you have large regions of whitespace (add up the squared areas of all the connected regions created by your edges and the edges of your bounding box, then negate that to get an error term). This will tend to coalesce edges into meaningful clusters.

- You might want to add a "confusion" term to your edges. One I like is maximizing the _average_ (not total, otherwise you'll encourage crossings) cosine distance at edge crossings.

- Force directed layouts naturally minimize edge crossings, but you might want to add an explicit term for that if we're adding in other competing constraints.

- If you have any human intuition as to what's important in the graph (apologies, "social system architecture" isn't parsing in my brain as a cohesive concept, so I can't provide any concrete examples) then you can tag nodes (and/or edges) with an "importance" factor. The error term you'll likely want is some combination of higher repulsive forces between those nodes and the nodes in the rest of the graph (making the important information distinct), and weaker repulsive forces between the nodes in the other part of the graph (so they take up less space relative to the important structure). A fairly clean way to handle that is a repulsive force proportional to the largest importance squared divided by the smallest importance (or some monotonic function on the constituent large/small parts).

- Labels are something else you might want to handle well. As with the rest of this, there are lots of error terms you might choose. An easy one is adding a repulsive force from the edges of the label to the other nodes, an attractive force to the parts of the graph the labels should be labeling, and a repulsive force from the edges of the label to the graph edges.

- An important point is that you can represent basically all of the other interesting graph layouts as just some projected [0] gradient constraint being optimized. E.g., to get a hive plot [1] you impose a radial constraint on nodes according to their assigned groups and just use rules minimizing edge crossings, minimizing confusion at the existing crossings, and maximizing large chunks of whitespace in the graph to meaningfully cluster the edges (also something minimizing wiggliness if your edge description is complicated).

- And so on. This is quite long. Maybe a good general principle is that if you don't like something about a given layout, if you can quantify what you don't like then you can add that as an explicit error term and get a better graph.

[0] If you have "hard" constraints which can't be violated, replace gradient descent with projected gradient descent. Take a step according to the gradient, then "project" the parameter vector being optimized to the nearest location not violating those constraints (or, more simply, just project each node/edge/... individually, though convergence will likely be a bit slower).

[1] https://ggraph.data-imaginist.com/articles/Layouts.html#hive...

Differentiable Programming from Scratch

https://thenumb.at/Autodiff/

Not really. I can find or write one if you're very interested.

- Gradients (slopes) are incredibly powerful computationally. If you can compute a function, you can compute its slope with almost no overhead. Relating to physical objects, imagine walking at the top of an igloo (where it's pretty flat and you won't lose your balance) vs the sides of an igloo (where it's vertical, and you'll fall over or otherwise break something). For real-world functions. you can ask where you are (top, bottom, middle, ... of the igloo) _and also_ what the slope is (flat, steep, ...) with the second step happening nearly for free.

- The whole "technique" is that when the things you want aren't being found, walk in the direction of least badness. Gradients define that direction, and since they're nearly free computationally you can abuse them as much as you want.

- The rest of the "technique" is figuring out how to describe ordinary comp-sci data structures as differentiable entities. E.g., the simplest way to differentiate most discrete objects (like database insertions) is to insert them probabilistically and apply your derivatives/slopes to the likelihood of the insertion succeeding.

> They also don't tend to respond to regulation requirements which may be 'hard line' or 'guideline' depending on the place.

Not sure if you read much of the ones I posted, but they (and the latest version of that work stream in the author’s dissertation) definitely deal with accessibility requirements and so on.

That’s pretty much the entire point of tools like these - it’s trivially easy to subdivide a polygon, but non-trivially easy to do so while maintaining various constraints, like clearance sizes, connectivity, daylighting requirements, structural requirements, etc etc.

> rich tapestry

certainly, let's dive into the rich tapestry of floor plans X-D

For sure. Read the author’s dissertation (should be posted on MIT DSpace by now or in the coming weeks) - it’s excellent. He just started teaching at Berkeley - definitely worth following his work. (Disclosure: I wrote all the Python API/web app/infra stuff in the repo above but not any of the underlying algorithms).

Both are used. Hence, any good design should explicitly state what the goals are (ie. what we are optimizing for) before embarking on the design process.

Commercial real estate generally optimizes for profit, which means, floor space, however this may be subject to regulation and particularly significant cost constraints (eg. maximum height before alternate structural features required, maximum height of available raw materials, HVAC/insulation, site aspect, site topography).

High end residential real estate is perhaps the most interesting, because good residential architecture facilitates aesthetic concern and draws from the full palette of commercial architecture in addition to traditional methods while not being constrained by finance. Hence, very interesting results can sometimes be obtained from good architects who will consider factors such as foliage, natural audio, etc. which are often ~ignored or afterthoughts in commercial/industrial.

IMHO good and original design in adequately resourced contexts tends to be iterative and to consider all paths toward a solution, not only a preconceived approach and a waterfall solution.

I was thinking the same thing, albeit if someone is remodeling a residential house that has a main floor with a limited space, but the family would like a bigger kitchen, or a smaller living room? I'm wondering if it could be applicable in that scenario, or would be way more overkill than necessary? Taking into account of course of external walls, headers and other necessary limitations that might rule out using something like this?

I kind of feel like its overkill, but I'm curious what it would come up with if given a pretty strict boundaries in terms of space and dimensions even on a very large, multi-million dollar house. What's the threshold for when it could be applicable, versus "Yeah, we don't need something this insane to do this."

I do agree, it would be completely applicable in large sprawling buildings are being renovated, but are looking at how they can utilize existing space better.

You generally want your rooms to be not just rectilinear, but rectangular after you fill in all built-in storage spaces. And storage spaces have to be sized appropriately to their intended purpose: you don't want three-foot-deep shelves. Another thing this optimizer doesn't take into account is corridors. It has the notion of room connections and area ratios, but area ratios are the wrong way to think about corridors: you want them to be as small as possible while still having at least a certain width.

If you just look at the plans in the initial diagram. Plan C is the only one that makes marginally useful spaces, avoiding excesive corners and awkward leftover space that ends up without use. It also happens to be the more obvious solution to the problem.

I could see the value in generating a bunch of rooms roughly accounting for the space requirements, but that's usually done in a more abstract way before taking into consideration things like privacy, thoroughfares, building conventions, spans, noise and light access, wind patterns, and things of that nature.

Game called 'Due Process' has procedurally generated levels, but they are based on tilesets - I think rooms generated the OP way wouldn't make sense and would be very disorienting.