I worked in that field doing numerical many-body simulations of electron dynamics interacting with their environment in solid state devices like quantum dots, graphene, photonic waveguides & cavities , etc.
You would start from a Lagrangian formulation of the classical interaction, let's say Light-Matter, that would yield for example the Schrodinger and Maxwell equations. Following a Legendre transformation (there a post on the HN front page the other day on that) you end up with a so-called Hamilton operator from which you can derive a (huge) set of coupled differential equations which you then solve.
Here, if you wanted to increase temporal accuracy, it typically leads simply to longer calculation times.
We also tried a different approach using Feynman's path integrals and boy did that explode numerically. We optimized our programs to the point where everything was reduced to work on bits, but to no avail it was numerically unstable and the memory consumption when through the roof the longer or more accurate you wanted to make the simulation.
So, I would argue that NO, Feynman does not make it easier per se.
However, other groups made it work somehow.
As a starting point you can check that paper and it's references from the introduction section.
That's quite the leap you made there to get dramatic about LLMs takin' our jerbs. It seems to be a trend...
Support is not likely it, it's not the type of app that requires a lot of human support in the first place, tbh, I'd be surprised if you can even talk to a live person. Even if it was support, those would probably be the lowest-paid employees and not help much in cost cutting.
Not sure what a LLM would even provide for Spotify support that a static FAQ couldn't.
For writing documentation: AsciiDoc [1] as fileformat.
For publishing documentation / to build the web site: Antora [2].
AsciiDoc has a bit more features compared to Markdown which allows for a richer and more pleasant presentation of the docs.
Antora allows you to have the project documentation in the actual project repositories. It then pulls the docs from all the different repos together to build the site. This also allows you to have the released product versions go in-synch with the docs versions. Antora builds each version of the product as part of one site. The reader can explore different product versions or navigate between pages across versions.
IBM did research back in the 90s on perceptually-based colormaps and how to best represent various types of data within the color dimensions of luminescence, saturation and hue [1]. For example, they found that,
(1) Hue was not a good dimension for encoding magnitude information, i.e. rainbow color maps are bad.
(2) The mechanisms in human vision responsible for high spatial frequency information processing are luminance channels. If the data to be represented have high spatial frequency, use a color map which has a strong luminance variation across the data range.
(3) For interval and ratio data, both luminance- and saturation-varying color maps should produce the effect of having equal steps in data value correspond to equal perceptual steps, but the first will be most effective for high spatial frequency data variations and the second will be most effective for low spatial frequency variations.
===
[1] the original link got removed from IBMs website. Back in the day it was under
> (1) Hue was not a good dimension for encoding magnitude information, i.e. rainbow color maps are bad.
This is very good advice. Generally, hue expresses difference in kind whilst lightness and saturation expresses difference in degree. This is beautifully demonstrated in Nault's study of how children read maps.
Nault, W.H.: Children’s Map Reading Abilities. Geographic Society of Chicago, Newsletter, III (1967)
Is there any online fulltext link to that? It's pretty weird you used the exact same reference with the exact same format as your own earlier comment in this 2021 submission https://news.ycombinator.com/item?id=26489887
I looked for one but could not find. This is unusual for me as I prefer to have the full text of anything I cite.
For me (someone who has an interest in computational aesthetics) the value of such studies is that they confirm what we already know. I explain the key difference between lightness and hue/saturation to my student in this way:
==> Lightness evolved as a matter of necessity. Any light-dwelling creature without it will quickly become food. This accounts for the co-evolution of so many eye-types (fly, mammal, octopus' etc... all structurally distinct).
==> In primates, Hue/lightness vision evolved in response to the rare treat of fruit-sourced carbohydrates.
In other words: lightness is a requisite of survival, hue/saturation is a pleasurable elaboration. It is likely for this reason that in a traditional art school education, you are taught lightness before colour.
I had completely forgotten that I had referenced this before. Likely the similarity in format is a result of my having copy/pasted from my co-authored book 'Computational Approaches in the Transfer of Aesthetic Values from Paintings to Photographs'. In this book I address similar subject to the ones raise by the OP.
https://www.australiangeographic.com.au/news/2024/08/high-co...