16 * 1024 * 1024 / 1920 / 1080 = 8.0909, so you have enough VRAM for double-buffered 24-bit 1080p, with a bit to spare. For pure software rendering, that's good enough!
14,749 karma · joined March 3, 2013
Like this: https://svs.gsfc.nasa.gov/5477/
Incidentally — I spent an inordinate amount of time searching for USB3.2 cables on Amazon, and the vast majority of cables were actually just USB2.0 cables with PD support, and not actual Full-Featured cables.
Rust has two behaviours around overflow. In debug builds, it panics, in release builds it wraps.
IMO wrapping is a reasonable-enough behaviour to avoid UB in release builds, and panicking in debug is definitely the correct behaviour, because you're only avoiding UB by defaulting to something, but that's not nearly enough. In most applications where overflow is a risk you should make sure to choose what behaviour you consider correct.
Thankfully Rust has a pretty robust story around this:
fn add_behaviour() {
let small: i32 = 123;
let big: i32 = i32::MAX;
assert_eq!(small.wrapping_add(big), i32::MIN + 122);
assert_eq!(small.overflowing_add(big), (i32::MIN + 122, true));
assert_eq!(small.overflowing_add(small), (246, false));
assert_eq!(small.saturating_add(big), i32::MAX);
assert_panics!(a.strict_add(b)); // (nb: Not a real assertion)
}
impl Add for u32 {
type Output = u32;
fn add(self, rhs: u32) -> u32 {
#[cfg(debug_assertions)]
{
self.strict_add(rhs)
}
#[cfg(not(debug_assertions))]
{
self.wrapping_add(rhs)
}
}
}Likewise, coding is easy. It's just writing, and any child can learn it. Coding is not programming, and the hard part of the job lives in that distinction.
The law of demand frames demand as a function of price and utility — demand is monotonically non-decreasing with utility (the more useful it is, the more people want it), and monotonically non-increasing with price (the pricier it is, the less people want it), but e.g. Giffen goods and Veblen goods break the "monotonically non-increasing with price" assumption of the law of demand.
You can add efficiency to that equation — demand is a function of price, utility and efficiency, and it is also monotonically non-increasing efficiency (The less of it you need, the less people want it). If you could get twice as much saltiness from table salt, you'd cut down demand by 50%.
The Jevons paradox is about the cases where demand isn't non-increasing with efficiency, because utility is itself a function of efficiency. Increased efficiency directly lowers demand, but, because it increases utility, it also increases demand indirectly.
The paradox is usually framed as more efficiency -> more demand (because of the intermediate "more utility" step), but the author is framing it in the opposite direction, as less efficiency -> less demand (because of the intermediate "less utility"). I would argue it's just that the paradox works both ways, rather than calling it a "reverse", but that's me.
The general rule is that, in base b, you have finite positional ("decimal") representations of numbers p/q where q is a divisor of bˆn for some n. So e.g. 1/10 doesn't have a finite binary representation because 10 = 2 * 5, and that factor 5 ensures 10 is never a divisor of a power of 2. Likewise, 3 is coprime with 10, so you can't represent 1/3 in decimal.
Different paradigms come with different pathological cases. I've had to deal with Scala programmers whose notion of FP is making everything generic on the Monad it abstracts over, even when it'll only ever be instantiated on the one effect system the team uses. Nonsensical levels of generality is one of the classic OOP pathologies, and is the reason why we have aberrations like the AbstractSingletonProxyFactoryBean[0].
0. https://docs.spring.io/spring-framework/docs/current/javadoc...
Of course, you absolutely can build a No True Scotsman argument on top of that distinction, but I don't think that's what GP was doing.
The whole point is that these APUs present a pretty unique value proposition (lowish performance GPUs with massive amounts of RAM attached), and framework is afaik the only vendor shipping them on standard mini-ITX boards
"Famous mathematician uses ChatGPT to solve famous math problem" is equally technically impressive, but now you're telling those very same knowledge workers "that famous mathematician could've been you". It puts you in the driver's seat, and provides a clear path forward — subscribe, use our product, and reap the rewards.
Oh hell no. That's not where the value lies.
You can't send an AI CEO as part of a trade delegation. Sending an AI to close the deal doesn't tell the other party that you're there to make sure the deal happens. That's the sort of thing a human CEO does that an AI can't.
There's another aspect to it, though — parent was in a navy ship, surrounded by sailors. That's a very specific population, in a very specific situation, and it's not necessarily true that that's the right crowd or situation to care (though it baffles me how a sailor at sea might look up at the stars without being in awe of the thought "damn, my predecessors navigated based on those")
A common pattern in the readme is the use of "em um" ("in/on a" in English), which is idiomatic in Brazilian, but not in European Portuguese, where the contraction "num" would be standard. It's one of the cases that could be attributed to overly stiff academic writing, though.
0. https://en.wikipedia.org/wiki/Portuguese-Language_Orthograph...
Funnily enough, it took me a while to determine it was definitely Brazilian Portuguese, given I'm a native Portuguese speaker, because the whole thing is written in a stiff academic-ish style that hides some the differences between European and Brazilian Portuguese.