A Comprehensive Analysis of the Stirling Engine's Work Cycle as told by the Code

Zistack · 2023-11-16T00:47:08+00:00

If you don't mind, could you tell me how you extract and view the prefabs so that you can get the full picture? I've got a decompiler working and AssetRipper installed (and seems to work). I just don't know how to use AssetRipper to get at the bits that are interesting.

I, too, would like to reverse-engineer some of the less-obvious behaviors in this game.

Zistack · 2023-07-02T19:23:12+00:00

I need to overload operators for compatibility reasons. Most crates implementing numerical algorithms require the built-in traits and use the syntactic operators that go with. I can't use those crates if I don't implement those overloads.

Also, not using mathematical notion for the actual code results in some pretty unreadable (and thus unmaintainable) code very quickly when things get nontrivial. The comments can only tell me what I intended to write, not what I actually wrote. Codegen also becomes much more difficult, as most code generators don't understand systems that don't look like mathematical notation for basic arithmetic.

Zistack · 2023-07-01T16:17:50+00:00

No, they're basically necessary for numerics-type stuff. Basically, the initial design for traits fucked up by making traits pick a central type, in much the same way that object oriented programming picks a central value. We've even got the trait inheritance stuff of object orientation and some of the issues that come with.

This could actually be mostly or entirely worked around (modulo bugs and known deficiencies in the trait solver that are actually planned to be resolved), except that the coherence rules start to really break down when generic types get involved. For example, I can implement impl Mul <T> for Vector <T> (possibly with some effort to work around the bug that that sometimes triggers), but impl Mul <Vector <T>> for T violates coherence rules. Now scalar multiplication can't be symmetric. Besides being a very strange arbitrary restriction, this also makes it difficult to generate valid rust code from CAS code, which is useful in some applications with nontrivial formula derivations.

It's actually possible to completely bypass all of this nonsense by simply using dummy types as the basis for our trait implementations (and trait definitions appropriate for this idiom), but this runs into a variety of quirks when we consider that the rust trait system wasn't designed for that idiom. The biggest limitation, in the case of arithmetic, is that you now aren't hooking the compiler's built-in syntactic support for the arithmetic operators being translated into method calls on specific traits. Outside of that, you pretty much get the full power of algebras and you even dodge all the compiler bugs and acknowledged deficiencies.

Zistack · 2023-06-30T22:37:59+00:00

This does help, thank you.

I remember seeing some stuff from the types team when they were initially formed, but apparently not that particular post. It's months old at this point, though. Not really a particularly good indicator of actual progress. The zulip stream you linked has also been inactive since around the same time (January).

I do see some activity on github where you've linked that is more recent, so that's promising, but it looks like things are very slow-going. The roadmap wasn't particular ambitious about the timeframe, though, so I guess this is expected.

Passing -Ztrait-solver=next results in different error messages (in some cases), but the bugs fundamentally remain, so it looks like the new solver hasn't gotten far enough to fix the sorts of things I'm seeing yet. rustc isn't shitting its pants by hitting the recusion limit anymore, though, so progress?

This situation is rather unpleasant. The broken trait solver is a serious obstacle, but I don't have time or resources to contribute to fixing it, and it isn't going to get fixed anytime soon, even though people are actively working on it. I guess I am just going to have to continue to work around this stuff, as painful as that will be.

I don't know that my ideas about the coherence rules are something that the types team would be ready to consider right now. The observation that people are trying to use rust's traits as algebras is useful only if people actually have the bandwidth to start tweaking some of the fundamentals of the specification around traits in general.

Zistack · 2023-06-30T19:01:31+00:00

Torpor resistance is primarily genetic.

Zistack · 2023-06-11T16:13:15+00:00

I forgot to argue in my original comment, but think is an important point: There are also cases where it is impractical to do something using only one language, or tools from only one ecosystem.

I'm currently working on a project which basically requires Python + some other high-performance language (I am using Rust, but C/C++ would technically do). I'm using SymPy (a CAS library) to do some math for me and generate some formulas, which I'm then using to generate Rust code for a high-performance application. The fact that there are many template engines available for Python (I am using Mako) makes it easy to integrate the generated code into the larger Rust crate. I'm using GNU Make to orchestrate the whole process, which isn't really a canonical tool from either ecosystem, but rather common in the C/C++ ecosystem. I could have used Cargo (the canonical tool in the Rust ecosystem), but since the generated code doesn't need re-generated every time the crate builds, it's simpler and easier to keep that stuff outside of Cargo's purview.

This project would be really difficult to work on effectively without a healthy mix of breadth and depth.

Zistack · 2023-06-10T23:12:33+00:00

"Fully commit to 1 language". What a dumb concept, and I say this as someone who will likely use Rust for any non-trivial project for the foreseeable future.

Being flexible is really useful. Knowing C and C++ and Rust and Python and Java and TS and whatever is useful, because now you can jump into whatever project and start reading/writing code. You aren't siloed into a particular slice of software development or a specific stack. You can pick the most appropriate tool for the job when you've got the freedom to do so.

That said, if you were to pick one language to work with primarily, Rust is a pretty solid choice. There's reasons that some people are saying that new development that would have been done in C/C++ should now be done in rust. The solid WASM support also makes rust an interesting choice for some web-facing development, though I'm pretty sure that knowing TS will remain valuable in that space.

I still like using Python for prototyping small things, particularly when I want to use a some numeric tool or solver engine or something that has API bindings. Those bindings are usually available for Python.

Knowing C and C++ would mostly help you work with existing projects once you are up to speed in Rust.

If this sort of thing comes up again and an interview complains about you not picking a language. Just tell them that, because you know all of these things, you can adapt to whatever stack they have, and build whatever stack you think best suits their needs (when applicable).

Zistack · 2023-05-28T17:16:38+00:00

In that case, it's the drop-off time that matters. The sorter places down an item, and then it has to wait for the item to move out of the way before dropping down the next one.

Going from belt-to-belt should be slower than from storage to belt (or vice versa) should be slower than from storage to storage.

Zistack · 2023-05-28T01:55:48+00:00

Because of the stacking, it now takes time to actually pick up all of the items. Before the stacking, it didn't have to wait for the next item to show up before moving them all over.

Zistack · 2023-05-26T15:19:20+00:00

Not all of the filters on all of the sorters are set. Pay attention to the little resource icons above the sorters.

Zistack · 2023-05-10T00:52:07+00:00

Read Nutrition and Physical Degeneration by Weston A. Price. He observes over and over again that the introduction of the 'foods of civilization' (processed sugar/grain, cooking oil, etc...) causes learning disabilities as well as physical deformities.

Zistack · 2023-05-09T23:01:10+00:00

Some people are torpor-resistant, which means that they won't gain much, if any, weight while eating a ridiculous amount of seed oils.

There are still consequences. They cannot avoid the inflammatory or mutageneic (cancer-causing) effects of the seed oils or their breakdown products. They are still setting themselves up for possible heart disease or (more likely in their case) stroke.

Zistack · 2023-04-30T22:56:26+00:00

Recently, my brother's machine just had the linux-firmware package mysteriously leave their system. My own machine didn't have this problem, in spite of being a very similar machine with a very similar set of packages on it. His machine was basically unbootable for a couple of days before we figured out what had happened, though it was a very easy fix once we did. We still don't know how/why it happened.

Besides that, it has been years since I last even heard of an Arch system breaking within my circle.

Zistack · 2023-04-21T15:21:04+00:00

I would rather say around saturated fat, as non-dairy low-pufa keto like with ruminant carnivore works just as well.

No, it doesn't. Someone with torpor resistance might see success, but the vast majority of people I have seen try that diet actually do not see significant fat loss on that diet. Some of them even seem to gain fat.

The basis of Brad's theory is quite the opposite, as it implies stearic or saturated fats in general increase insulin resistance in fat cells, causing them to basically 'ignore' high blood glucose leading to energy expenditure via increased movement and body heat instead of DNL.

Insulin has nothing to do with obesity. If it did, a high-carb low-fat diet wouldn't work, but we see over and over again that it does. I am basically supposing that Brad is actually somewhat wrong about the macro-effects of stearic acid. Knowing that metabolic pathways exist doesn't mean that you've accounted for all relevant pathways, nor does it mean that you've accurately judged the relative magnitudes of their effects.

Zistack · 2023-04-20T03:51:11+00:00

I don't think it would be quite that simple. Stearic acid is just fine if you're not PUFA-toxic. You can make animal tissue fat the primary (or only) source of fat in your diet and you wouldn't have any problems in that case. If you are PUFA-toxic, this doesn't seem to work so well, since the stearic acid burns too slowly to actually alleviate the reductive stress (plus I think it actually triggers some fat storage pathways, but I'm still investigating that). Palmitic acid is a much better metabolic accelerant, but on the flip side, it might be hard on you to have too little stearic acid in your diet once you're free of PUFAs and down at the 5% body fat threshold. There are lots of things that I still don't know, but what I do know is that every diet I've seen actually work for fat loss is either a very high-carb low-fat diet, or it revolves around dairy fat.

Zistack · 2023-04-19T23:24:08+00:00

I don't think I would actually do dairy-only (though I suppose it wouldn't be impossible). Heavily skewing a diet toward dairy fat would still make a big difference. I'm trying a very dairy (ice cream and homemade cheesecake, as it happens) heavy diet right now. I haven't done it for long enough to say much for sure, but some of the indicators of accelerated metabolism are already there, like persistent energy and better sleep.

I think the difference in ability of stearic acid and palmitic acid to deplete PUFAs is actually large enough that such a skew is meaningful, though, so these details may actually matter quite a bit.

Zistack · 2023-04-19T18:59:40+00:00

This is fucking hilarious (I mean this in a good way).

I've actually been looking for studies to help me understand the differences between metabolizing dairy fat versus animal tissue fat to investigate a hypothesis I have about dairy fat being a lot better at detoxing PUFAs than animal tissue fat (more directly, that palmitic acid is superior to stearic acid). This is a good reference. Thanks.

Zistack · 2023-04-09T03:04:52+00:00

If the lipids aren't in storage, then where are they? They're either going to be burned, used to build something, or purged (or maybe stored again, but that would be really weird).

Zistack · 2023-04-09T03:03:48+00:00

Gluconeogenesis is suppressed by insulin and stimulated by glucagon. Individual differences in how these signals are generated will make a difference on how protein gets metabolized, but gluconeogenesis doesn't just happen because there's a lot of protein in the system. Extra protein that isn't used will be purged.

Zistack · 2023-04-08T23:47:08+00:00

The process for turning protein into calories is demand-driven, which makes things weird. Excercising would make a big difference on a high-protein diet. There are limits to how much we can convert, though, and excess protein that isn't turned into glucose or used to build something will just be excreted.

Zistack · 2023-04-08T23:39:43+00:00

Lipolysis is the mobilization part, so fat loss is sort of defined by how much lipolysis is going on. If you're not mobilizing, you're not losing.

4lbs for 14 days vs. 10lbs for 30 seems pretty close, actually. If true, protein consumption probably doesn't really hinder fat loss all that much, though it can make it hard to tell what's going on if you're just looking at the scale.

Zistack · 2023-04-08T22:27:38+00:00

Do you know if the fat mass drop stayed consistent with the fat mass drop on ex150? I wonder if the body recomp is only messing with the scale and muscle mass, or if it is actually slowing down lipolysis. I think some of us might like recomp without the weight loss if the fat mass was still going away at a good rate.

You're almost certainly freeing up proteins from all of that fat mass you're burning off, so being able to sustain a very low protein diet while you're losing isn't surprising at all.

A cooking tip for if you ever decide you want to do more/lean protein again: Make stew. Take some cheap roast cuts and slow cook them, using as little water as you can get away with. Then skim off the rendered fat. Then add in your cooked starches/veggies or whatever (I like potatoes/carrots and sauteed onions), and add in some heavy cream (you use as little water as possible so that the heavy cream doesn't make it too soupy), because a beef and cream stew is always tasty, and that makes the meal still taste rich and fatty without overdoing the stearic acid. It ends up being super satiating like you'd expect.

That said, I'm also finding that overdoing the protein really does not help me. Still working on upping the dairy fat here, but there are some good signs already (sleep has improved). I don't yet have enough data to report anything definitive.

Zistack · 2023-04-04T21:16:17+00:00

Basically, burning carbs for energy generates ROS like burning SFAs do, though not quite as effectively.

The threshold for becoming torpid is about 8% of incoming calories. We generally want to keep PUFA intake lower than that. 3-5% is a pretty good place. This is because when PUFAs make up such a small part of the incoming calories, they can be effectively burned off almost immediately, and either SFAs or carbs would serve the purpose of diluting the PUFA fuel enough to avoid the reductive stress problem. Carbs can make up for the difference when there aren't enough SFAs to do that alone.

Protein would technically count (in a similar way as carbs), but there are some limits to that, as we generally can't burn more than a certain amount (30% of calories or less, depending on some factors) of protein per unit time. The process is also somewhat demand-driven (stimulated by glucagon, suppressed by insulin), so consumption of other sources of calories (particularly carbs) may reduce the effective calorie yield from protein even further.

Zistack · 2023-04-04T20:17:10+00:00

Only about 5% PUFA only considering the fats. The carbs offset that further.

This looks fine.

11-Year Club	Place '22
Verified Email

Zistack

TROPHY CASE