namibj

What proofs are good for is decoupling implementation and semantic definition of software (and application specific circuits).

Like, proving that in the absence of hardware faults, some optimizer for JavaScript can never result in arbitrary memory accesses.

Or that some database doesn't violate data semantics under ANY condition.

Or that as long as not too many sensors fail, a plane autopilot will not go and do anything that would lead the plane to exceed safe speeds and forces/accelerations. (Won't just go crash the plane or drop it from the sky in one or more pieces just because some few sensors froze or caught lightning or something.)

Because rail is quite non line of sight and quite infrastructure defined pathing.

The automatic coordination system hit a fail condition; they neglected the fallback protocols that had rules for spacing determined to work reliably without the computer keeping real time supervision; they crashed.

This is in the way more like the Washington D.C. helicopter plane mid-air where some normalization of deviance got people to ignore automated protection systems.

If most involved had known the fallback protocols they would have refused to move/continue while the protocols were utterly neglected. At least with a robust safety culture active, ofc.

Closed loop control is very effective (where it's available). Of course that's not always usable and thus some tasks do necessitate the stage to provide such positioning precision as absolute accuracy not merely precision.

Does anyone have a link to a 6DOF version of what this does? Like, the design principle would easily function for a hexapod (swap the dual-rod linkages for single-rod and manage to pre-load the result; add 3 more motors, change how the actuators are arranged relative to the platform they manipulate), but it'd be great to see at least predicted work volume and/or translated stiffness/precision numbers that e.g. adjust from this project using the different kinematic equations, before I'm investing a bunch of R&D into figuring out how best to orient things and whether I may want that to rely on AppliedScience's diy vacuum preloaded spherical air bearings that could probably take care of the necessary pre-loading of the mechanism; machining a graphite block into a hexapod movement stage side "platform triangle" (the floating part that moves) doesn't really need force after all, just sufficient control over where the milling tool/drill is, and obligatory effective dust collection lest the workshop gets a strong dusting of graphite powder. Attaching ball bearings balls to the rod ends would probably be one of the hardest machining part of the entire idea.

But this 3d printed rubber band preloaded journal bearing concept is also intriguing for it's simplicity, even if it's probably more limited in usable range of motion.

The UI is a ring laser gyroscope, right?

I want to remind that natural gas fired heat pumps operating with central European winter temperatures on the cold side and toasty warm indoors living room "by the fire place/any clothes are too warm just sitting not even exercising at all" are well established technology.

They're just usually deployed for frozen warehouses, factories that actively freeze large amounts of (usually food), and AFAIK the occasional ice(hockey) rink.

Shitty types that don't even bother with any decent controls/pumps (those 90% boilers use a water loop circulation pump and a combustion air blower together with a bunch of sensors and valves) run propane-fired in many camper vans to do the fridge. But at the scale of an apartment building fit for 50+ residents, a natural gas fired central heat pump can be _quite_ efficient and economical.

Thermodynamically they're a heat engine with high combustion/flame temperature that uses the warm side as the heat sink, mated to a heat pump that consumes the produced "mechanical/electrical grade" power to pump heat from the cold side to _also_ the warm side. You save the turbine! Also the electrics but they're probably not even that expensive relative to the rest of the 200MW-class combined cycle natural gas power plant.

I'm pretty sure the barrier to the lead-gold mass parity is that due to nuclear stuff they're gonna not trade equal proton/neutron count and while of you flip the ratio you are merely dealing with an energy deficit/excess incurred as you're rearranging the protons and neutrons to transmute between gold and lead which by e=mc² is equivalent to mass... You're gonna run head first into the problem that we with our current proven understanding of atomic nucleus quantum physics, expect the energy excess to need to be turned into an equal split of matter *and antimatter*, which will foul your plans.

We're suspecting there to be some symmetry breakage to explain why we don't really see any globs of antimatter with our telescopes (at least none that show any evidence of being antimatter), but so far no (real) luck.

As for the "0.13€ vs. 1€": you're not gonna get much solar yield in peak winter at least in Central Europe, especially it's gonna be that your PV is going to charge <100hour electricity storage when the sun shows up on those winter days and the heat pump (at least the part that spends a little electricity to lift a lot of heat energy from outside temps to indoor temps) runs approximately continuously.

You might have some kind of e.g. water/water heat pump with salted (not table salt though) water deliberately thawing during daytime (by turning on the circulation between it and outside air) to freeze at much warmer than night air temperatures to buffer those "only mildly freezing" temperatures to improve the efficiency (and at that point, likely also the thermal output power) of the heat pump.

The radiators inside and potential fans for them would also go up in flow to make up for the increased losses through the walls/window-glass.

A big reason why at least in e.g. Germany heat pumps are not at all irrelevant vs. electric resistance "space heaters" is that they're also very efficient at handling spring/autumn (lower thermal delta to lift against; referencing to a resistance heater for scale/reference purposes but clearly not expecting that to be a benchmark) while easily offering summer cooling (with relatively minor incremental complexity).

I don't really know how inherently expensive it is to keep around at least for parts of each city, but existing natural gas central heating boilers are very useful to not just trash before they're broken just because one uogrades to a heat pump, specifically because they are already there (sunk cost/little scrap value) and have basically zero issue delivering extremely spiky power during unannounced winter days (well, takes maybe a day of notice to actually get crew in to the storage&distribution facilities, but weather forecasts easily cope).

Sure, it's not _efficient,_ but we could just divert some synthetic methane during summer to refill the caverns: we kinda want that (at least for hydrogen but methane works too at least for storage) anyways for chemical synthesis factories if we're not just gonna feed them crude oil/natural gas, so other than that chemical factories probably/largely prefer direct hydrogen, continuing to use our existing seasonal storage even if it's not getting refilled from NordStream2 but from local summer-only electrolysis plants and with more hydrogen than methane where the geology allows, seems to me just frugal dealings with nature (reduce, Reuse, recycle).

Start by using wet Roomba tech to clean the port prior to opening the seal/door and doing the plugging? Assuming it's accessed from below.

Sorry about the writing :(

We have beaten it but only for an output that's approximately "green smoothie".

We're already better than just LED grow lights for e.g. lettuce, though, from how I recall the linked paper.

Unsure how you conclude that cold outdoors necessitate more meat though; aside from some micronutrients vegan diet works just fine so reverting back to "meat only on Sundays" 1910 style household dinner menu structures would work fine...

Most people could, for example, do with replacing the caloric intake from half the portion of any non-vegan food they consume, with potato.

If outdoor farming breaks from climate meat will get more expensive...

Vertical solar panels mounted like fence panels between fence posts high enough to not get covered by snowdrifts will produce electricity year-round; and we only need around 3x as much solar farm currently to power sealed grow "basements" than the same plant output would need if just farmed on an open field (assuming climate is matched and weather is average). The benefit of it is just that the panels can be other places (like noise barrier walls next to an urban highway) than the plants and the climate can be freely picked. Also no unlucky correlated dry spell weather events that can cut 100 million people's worth of harvest yield down to half or worse.

Grow houses won't fail collectively as much as farming weather is correlated across a region. Pretty much just need to keep measures around to prevent the plants from freezing just because the electric grid falls over for 3 days in winter.

You can just render to the 1bpp text/4bpp images monochrome 300dpi target; perhaps some tone mapping due to the limited contrast ratio of the eink vs. your OLED should be done at rasterization time.

Then just map the resulting 16 brightness levels according to the contrast ratios/progression they have on your eink. Use phone camera and adjust whole image contrast/brightness/black-intensity sliders holding them side by side until the grayscale matches.

Then just pick pixel RGBs from a gray-bars test image you have opened on the remarkable before you took the picture with your pixel 7 pro. Might not easily be done on the phone but can let a python using AI grab those for you. (If it's wrong it'll be obvious or so harmless it doesn't matter anyways.)

Then you take that rasterized-to-1/4-bpp-djvu apply the color palette you just built yourself, and zoom to 300dpi.

Other than the screen backlight which you've taken care of when you held both devices side-by-side and played with the sliders, there's no substantial difference left. Should be pretty representative. Don't look with too much of a magnifying glass though the phone doesn't have exactly the same dpi so there are resampling artifacts your eyes resolve if you're too close to it.

The big thing that was learned all the way back with UT and it's follow up SUT was that semantic nesting structure often incentivizes models that can deploy the very same learned structural parsing intelligence independent of how many layers of nesting had to be unwrapped for this structural pattern to surface.

Think how a reverse polish notation calculator with reasonably limited data stack depth could run efficiently with a plain vanilla transformer.

But if you input classic grade school parenthesized infix with a few levels of operator precedence, you are no longer able to just evaluate the expression during transformer prefill. Even if you add a stack depth bound worth it reasoning tokens between any two input tokens as they're processed.

UTs can, at least if run with encoder (unmasked) attention, resolve the task through technically-flexible iteration count that can and will follow the evaluation order of the infix operator tokens of the input expression.

While masked attention unfortunately limits it's powers, the fundamental benefit of separating task-specific-intelligence (an individual expert of an MoE) from the notion of which transformer layer has it pre-digested just right for that task/processing to be done to it, allows for massive reduction in model parameter count. Note this comes at a penalty of parameter activations (inference will take more compute).

It's just that at some point you can't afford to just train more parameters, without suffering overfitting issues/failures-to-generalize.

The architecture decoupling learned weights from when they're activated also helps with generalization to out-of-distribution structures. Think resilience against yoda-speak and such.

For fast updates / high frame rate, especially also smooth fade from previous to next page, those displays only do black/white. They can typically modulate about 14 levels of gray in-between but reliably (without really bad ghosting, due to strong temperature sensitivity of the pixel's transition response and the display being static so all gray has to be done by carefully interrupting a transition part way through) only from a nice flash-to-black -> flash-to-white -> fade-to-target-greyscale (sometimes one or two alternating full contrast flashes prepended to more intensely equalize the pixels/erase ghosting, but should only be needed every couple dozen page flips in grayscale mode).

I think the nice b/w no-flicker fade transitions chop the transitioning of all changing pixels into small burst/chunks and interleave/alternate the chunks of white-to-black with the chunks of black-to-white, so it's perceptually simultaneous. Or it's actually pulling off some kind of tri-state driving leaving unchanging pixels alone and pulling those that change to either plus or minus polarity depending on what transition direction they are supposed to go in... Sadly IIRC all quite proprietary-gated :(

What that means for djvu is that at least for text-only content on those readers that manage the 300 dpi "threshold" you'd just rasterize to pure 300dpi black/white (1 bit per pixel) comparable to a 300dpi "don't skimp on toner but don't you dare take half a second longer than you must in order to make the text crisp enough for $reader to have no good reason to whine about it being not crisp enough" laser printer job.

Djvu is particularly for displays with more than about 5bits of grayscale as well as for lossy compression of grayscale/color scans. And maybe also some efficiency gains on 1-bit-per-pixel quantized scans, but those aren't usually the target content for these readers, IMO. Might want to try for them, though!

I think back in the days before office workers that happened to do their work on a computer had access to the ancient relatives of "Microsoft Word"/"Libreoffice Writer", it was pretty normal for printers to take care of plain text files, with about as much fidelity as manual operation of a classic purely mechanical Typewriter.

Since then printers progressively forgot how to cope with such "documents", though IIRC good-old HP "PCL" should only require about a bare minimum of framing/job control to get a modern printer to handle ASCII plain text.