Hi thanks!
Sure, certainly!
I also want to eventually add some physics-based levels for fun, with like a box2D sim interacting with the circuits (with N circuit ticks = 1 box2D "tick"), or even little games on top of the circuit, but I need these tutorial campaigns first otherwise the step curve is way too high.
Unfortunately not really, but we've found (and used in production for a year) that Claude 3.5 is perfectly capable of identifying anomalies or other points of interests in very large sets of time series data.
Think of 100-200K worth of tokens formatted like this:
<Entity1>-<Entity2> <Dimension2> <ISO 8601 time +1> <value>
The only pre-filtering we do is eliminate "obviously non relevant" data, such as series where the value is completely flat the whole time, but this was done to add more data to the context, not because Claude struggled with it (it doesn't).
There could be a few benefits to what is proposed in the article, here are my semi-educated guesses.
1. Less dependent on local geology. Geothermal wells are well suited for hot, non-pourous (?) geology.
2. Might be cheaper. It can take years to drill the wells for a closed loop system (e.g. Eavor), less for a fracked geothermal well (e.g. Fervo). I imagine drilling a single borehole for this is way simpler.
3. Less water loss. Fracked geothermal well wells can be pretty lossy (20%?). If water supply is an issue your options may be limited.
200W at 300g is realistic for a modern BLDC motor. The article states that Maxon was the motor supplier so they likely used the EC-4pole series, I'm guessing it's one of these.
It's 30mm diameter to fit in a down-tube, 200W, and 300g. But just because it's 200W doesn't mean you have to run it at maximum capacity, there's no reason you couldn't run it at 5-50W.
'var' is JavaScript's older variable declaration construct. Variables created this way are live from the beginning of the function that contains them (or globally if there isn't one). So a block with braces (such as you'd use for a for or while loop body) doesn't actually restrict the scope of var `v` below:
console.log(v); // <-- v is a variable here, we can access its value even though it is only declared below
// prints 'undefined'
{
var v = 1;
console.log(v); // prints 1
}
console.log(v); // prints 1
You used to (and might still) see a workaround to recover more restrictive scoping, known as the "IIFE" (Immediately Evaluated Function Expression): (function () { var v; ... code using v here ... })() creates a function (and thus a more restrictive scope for v to live in) and evaluates it once; this is a sort of poor man's block scoping.
`let` and `const` were created to fill this gap. They have block scope and are special-cased in for loops (well, `let` is; you can't reassign to a `const` variable so nontrivial for loops won't work):
console.log(l); // <-- throws ReferenceError: l is not defined
{
// pretend the console.log line above is commented out, so we can reach this line
let l = 1;
console.log(l); // prints 1, as expected
}
console.log(l); // throws ReferenceError: l is not defined
// ^^ l was only in scope for the block above
Fun(?) fact: it's not technically true that const can't be used in for loops:
for (const i = 0; i > 0; ) {
console.log('this is stupid');
}
let ran = false;
for (const i = 0; !ran; ran = true) {
console.log('this is also stupid');
}
Has anyone tried a controller for cooling that is dependent on processor current consumption? Temperature measurements lag, but the current used by the processor is instantaneous and directly converted to heat (P = VI). In theory, it should be possible to reduce temperature spikes.
Any plans to add more advanced campaigns, say, to build up to a simple processor?
reply