TL;DR: Try rerolling attributes for a character only if the geometric mean is too different from that of the standard array.

I gather that lots of people like to randomly generate their player character's attributes ("roll for stats"). As most players/DMs have probably realized, this can cause problems:

• One or more players might roll lower than the rest. Either they're stuck with an underpowered character or they'll want to reroll until they like the results. The latter kind of defeats the purpose of rolling for stats.
• One or more players might roll higher than the rest. The resulting characters can outshine the rest.
• The average randomly generated array makes for more competent characters than the standard array. Players who prefer the standard array might not like this.

Folks on r/onednd have described a number of solutions, including rolling one array of attributes for the whole table and rolling a whole bunch of arrays and letting players pick from those.

I suggest an approach that's a bit mathier, for those who like that kind of thing. If you take the geometric mean of an array of numbers, you'll get an average that isn't sensitive to outliers. For six attributes, you multiply them all together and raise the product to the power of ⅙. The standard array's geometric mean is this:

(15×14×13×12×10×8)^(1÷6) = 11.74

When randomly generating a character's attributes, try taking the geometric mean of the result. If it's too high or too low (say, greater or less than 11.74±0.5), reroll. This should keep arrays pretty similar on average while allowing for some decent variety. It also lets people use the standard array or point cost methods without being left behind.

Here's an example of some randomly generated attributes for a party of four:

Character 1: 16 14 13 12 10  9
Character 2: 14 13 12 11 10  9
Character 3: 15 13 13 12 11  8
Character 4: 16 16 14 13  9  5

You can do this with some six-sided dice and a calculator, but I also slapped together an R script that does this and put it on Codeberg if you're interested. I can write instructions on how to use it if anyone asks for it, but right now it's just a bit of code and a free software license.

The Storypath system is descended from the systems used in Vampire: the Masquerade, World of Darkness and other stuff from White Wolf publishing. There's already games published by Onyx Path that implement Storypath (such as Trinity Contiuum & Scion), but this is a generic version with example settings included.

This finalized version actually came out over a week ago, but today I noticed that despite the apparent interest in Storypath on Backerkit, nobody on r/rpg or here had posted about the announcement. I haven't played it yet myself; does anyone here have experience with or interest in Storypath?

Note: While the PDF is available now, it'll be some months before the hardcover ships.

There are some bus widths that are used in full discrete GPU dies and some that I've only ever seen in cut-down GPUs. Full-die GPU memory bus widths seem to always be:
64-bit × 2^n^ × (1 or 0.75)
where n is a whole number. Cut-down models can feature pretty much any multiple of 32 bits.

Examples:

• 128-bit bus: common in entry-level GPUs (RTX 4060, RX 6600 XT)
• 160-bit bus: occasionally shows up in cut-down designs (Arc B570)
• 192-bit bus: common in midrange & entry-level GPUs (RTX 5070, Arc B580)
• 256-bit bus: common in midrange GPUs (RX 9070 XT, RTX 3070 Ti)
• 320-bit bus: occasionally shows up in cut-down designs (RX 7900 XT, RTX 3080)
• 352-bit bus: Appeared in the RTX 2080 Ti, which was cut down
• 384-bit bus: common in upper-midrange & high-end GPUs (RX 7900 XTX, RTX 4090)

Any insights into why this is? As a layperson, it seems like having a full die with perhaps a 160-bit bus for the entry level or a 224-bit bus for the midrange would at least occasionally make sense.

If you think GPUs are big today, you ain't seen nothing yet. This baby (theoretically) scales all the way up to a 300mm wafer.

Abstract

This paper introduces the Photonic Network-on-Wafer (NoW) GPU architecture to overcome fundamental limitations in electrical interconnect scaling by implementing the inter-GPU network in a wafer- scale optical interposer. We argue that the photonic-NoW GPU is a scalable architecture, delivering significant performance benefits in a power-efficient manner.

Edit: Fixed link to PDF.

I see that there are already posts here about RDNA4 today, but I figured I'd link the actual announcement for general discussion about the launch.

The University of Pennsylvania offers a free series of books called Software Foundations with the following description:

The Software Foundations series is a broad introduction to the mathematical underpinnings of reliable software.

The principal novelty of the series is that every detail is one hundred percent formalized and machine-checked: the entire text of each volume, including the exercises, is literally a "proof script" for the Coq proof assistant.

The series includes Verifiable C, which seems very appealing as a way to avoid some of C's infamous "footguns." I haven't read the series myself, but I might in the future because I like math, logic & programs that do what they're supposed to do.

Are there any materials that would be good as alternatives or complements to this series?

Edit: Adding the Vercors Wiki to the resources in this thread

solution by @[email protected]

Hi,

I'm new to both using Helix and terminal multiplexers in general, so I'd appreciate some help with this. When I launch Helix without tmux, I see the default theme with a purple background, which I like:

But when I launch it using tmux, even with the -2 flag, Helix does not display the same color scheme:

I have tried making a config.toml file with an [editor] section and set true-color to true, but that didn't appear to help. How can I use the default theme with tmux? I'm using GNOME 47 with wayland on Fedora, in case that matters.

Any post I've seen involving Helix, tmux & colors seem to be with custom themes, so I don't know which threads are relevant to this, if any.___