lheck | 11 months ago | on: Solving a “Layton Puzzle” with Prolog
lheck's comments
lheck | 11 months ago | on: Coq-of-rust: Formal verification tool for Rust
lheck | 2 years ago | on: My Grandpa Was a Nazi
lheck | 2 years ago | on: Formally modeled Dreidel for no good reason
lheck | 2 years ago | on: Formally modeled Dreidel for no good reason
lheck | 2 years ago | on: Julia as a unifying end-to-end workflow language on the Frontier exascale system
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: The night train revolution has been hailed as an alternative to airplanes
lheck | 2 years ago | on: Casio fx-CG50 calculator comes with Python built-in
lheck | 2 years ago | on: Austria rail operator OeBB unveils new night trains
lheck | 2 years ago | on: Austria rail operator OeBB unveils new night trains
lheck | 3 years ago | on: DIY 1,500W solar power electric bike (2022)
lheck | 3 years ago | on: DIY 1,500W solar power electric bike (2022)
lheck | 3 years ago | on: DIY 1,500W solar power electric bike (2022)
> 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
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
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.