lheck's comments

lheck | 11 months ago | on: Solving a “Layton Puzzle” with Prolog

almost-one-liner (though it will give you the full model):

    import z3; z3.solve([z3.Sum([ord(a) == z3.Int(f"k{i}") for i, a in enumerate(r[0])]) == r[1] for r in [("bbababbabb", 7), ("baaababaaa", 5), ("baaabbbaba", 3), ("bbaaabbaaa", z3.Int("x"))]])

lheck | 2 years ago | on: My Grandpa Was a Nazi

The AfD had a large secret meeting with right extremists discussing "re-migration" policy this last November, and many members have close ties to Neo-Nazis.

lheck | 2 years ago | on: Formally modeled Dreidel for no good reason

Hi lou, I'm a contributor to Storm and will continue to work on it in my upcoming PhD position. The bottom line is that there are some things you can only do in PRISM and there are more things you can only do in Storm, but if you can do it in both, Storm is usually much faster (see QComp: https://qcomp.org/). PRISM has better documentation. Storm has recently recieved a grant that will help improve its user interface and applicabilty. I would like to hear from you what ideas and applications you have for using PMC! :)

lheck | 2 years ago | on: Julia as a unifying end-to-end workflow language on the Frontier exascale system

> Another common theme is that while Julia is great at composition, it's not clear what's expected to work and what isn't, because the interfaces are informal and not checked.

This is THE huge issue when combined with the other variables:

- you often have hundreds of depedencies that interlock

- you often have dependencies that work with multiple packages, and they will often pull them all into your tree (there are sometimes "bridge packages" written, but that is O(n^2) in the number of packages)

- many maintainers do not care about good versioning practices, because they are not enforced, and it is not their problem when they break a bajillion other packages

- many people writing Julia code are not software developers. this is great! but they usually don't look at what their testing coverage looks like. often the CI always fails on a package and it's ignored.

Would Julia only allow multiple dispatch as a link between those packages, the situation would look a little better. But often the packages also talk through simple accesses of values like `X.someproperty`. I've seen situations where maintainers would add and remove these properties and break their own other libraries. Better "enforcement" of these types of things - however that would look like - would be a huge improvement for the time sink that is maintaining a Julia package.

lheck | 2 years ago | on: Casio fx-CG50 calculator comes with Python built-in

The reason is admission of calculators to exams in schools and universities. Casio and Texas Instruments basically have a cartel that dominates this market. Often one of these calculators is required.

lheck | 3 years ago | on: DIY 1,500W solar power electric bike (2022)

Let's forget about the solar cells (there's not that many on this bike) - e-bikes really are extremely eco-friendly. Your points are not correct and I want to point out why:

> It's expensive

It's cheap. An e-bike like this costs as much as some of the extras on a car.

> it's not going to do much good for your health

This is just incorrect - if you have an e-bike, you are way more likely to use it compared to a muscle powered bike, and you are going to ride longer distances with it. In sum, the positive health effects of using an e-bike regularily are larger than using a muscle-powered one.

> compare it to a reasonably light "ordinary" bike, driven by muscle power, this is nowhere near "eco"

if you count calories, and are on an average omnivore diet, e-bikes are actually more efficient than muscle-powered bikes. it's eco.

> leave the pedals out and be honest about it

?? not sure what you mean with honest?

> in a few years when it's out of fashion

opinion: e-bikes are not a fashion, but here to stay. it's far less trash than a car.

The gasoline-electro argument is kind of true for cars though, electric cars are not eco, just slightly better than gas cars.

lheck | 3 years ago | on: An intutive counterexample to the axiom of choice

> Is this only a problem for infinite sets (of sets to pick from)?

I've edited this a lot, but it might still depend on the AoC if you can construct such a function in general, my ideas didn't work (e.g. two complex infinite sets per set are already hard)

> Is it trivial to construct a function that picks a single element from an arbitrary set that’s not ordered numbers (say, the real endomorphisms)?

With no constraints on the function this is the AoC.

lheck | 3 years ago | on: An intutive counterexample to the axiom of choice

True. It's always good to see someone thinking about math concepts in critical ways to understand them. But this post doesn't really have a place here on hacker news as it's just born of faulty premises and of misunderstanding what the Axiom of Choice states.

The actual HARD PART about the axiom of choice is that the thing f that picks from the collection of sets to its elements that has to exist must be a function. The axiom of choice does not have any reference to f being "described using any finite collection of symbols", or "computable". f must not be computable or graspable or describable, these are not constraints put onto f by the Axiom of Choice. But it must be a function!

Why is "being a function" a constraint for f at all? Not everything that goes from set A to set B is a function. Functions have to be able to be described in terms of sets, and not every collection of items is a set. The notion that every collection is a set is called naive set theory, and it does not work (see Russel's paradox). This is the hard part about the axiom of choice.

So if someone invokes some argument over complex concepts about computability, or being stateable, that's not even true of stuff outside of the Axiom of Choice and definitely not why specifically the AoC is hard.

page 1