lopsidedBrain

Yes. x86 processors translate instructions to internal micro opcodes before scheduling or running them. Those look nothing like the x86 instructions.

It is partly historical notoriety. It allows one to prove certain statements that seem counter-intuitive. So proofs that employ it can often be viewed with some skepticism.

Moreover, this axiom is _independent_ of the other axioms in ZFC. It is in fact possible to have entirely self-consistent "worlds" of mathematics, ones where axiom of choice is true, and ones where it is false.

More details and examples of alternate axioms are in the Wikipedia article: https://en.wikipedia.org/wiki/Axiom_of_choice

If it seems weird that math can give you contradictory results, remember that the difference only shows up when you deal with some form of infinity (e.g. when performing an operation on an infinitely large set). For any usage of math in the real world, the truth or falsity of this axiom won't give you contradictory results.

One of my highest-cited papers didn't pass peer-review. But that's okay. The citations (of the pre-print version) speak for themselves. If papers like these are good enough that new students entering the field use it as a ramp-up resource, they won't hesitate to cite it over and over again when they submit something for peer-review.

So journal publication is not the only means of recognition.

Speaking of which, computer science is a bit weird in that conference papers tend to have higher visibility than journals, even though the latter still has some of its grandfathered glory. Not all conferences are equal, obviously. Some have a more rigorous submission process than others. But our field definitely carries a bit of skepticism about the value added by journal publishers.

I couldn't actually figure out how to opt out of third-party tracking. They say I have to visit my wireless account, but not sure where to from there.

Huh, for some reason I had just assumed that it must be open based on the buzz around it. Cool.

For the uninitiated, WTH does semi-public mean? Did GPT-3 only provide an API but not the model?

Hmm. You're right, not if we are restricting ourselves to rectangles. But if we make A u-shaped, with B nestled in it, we'll be in business!

If they have customers who need that kind of database, I'm sure they will be willing to help out with the testing. The setup doesn't have to be too crazy. Storage appliances with 20-30 hard drives are fairly common, actually. Even for individual humans, not just corporations. LVM allows you to easily create a logical volume out of multiple physical volumes, e.g. https://www.redhat.com/sysadmin/creating-logical-volumes.

You might find it interesting to look at the actual sqlite source commits where this change was introduced: https://sqlite.org/src/timeline?r=larger-databases It turns out the number comes from having a max of 2^32 pages in their database. Their default page being 4 kB each: https://www.sqlite.org/pgszchng2016.html

Working backwards, they must have raised it to 64kb: `python -c 'print(1024 * 64 * 232)'` produces 281,474,976,710,656.

https://sqlite.org/limits.html

SQLite was originally designed with a policy of avoiding arbitrary limits. [...] Unfortunately, the no-limits policy has been shown to create problems. Because the upper bounds were not well defined, they were not tested, and bugs were often found when pushing SQLite to extremes.

It does, in that it's much easier for me sign up with a throwaway username. It's also part of the reason HN doesn't require these SSO integrations.

The material nature of hardware is barely any higher than that of software. Yes, you cannot just copy bits around, but you can take the same design and fabricate millions of chips for pennies. The cost of production for any given chip of Silicon has almost nothing to do with its material cost. It has everything to do with the amount of design work that went into it, just like software. None of that appreciably changes the benefits of cooperation vs competition.

To an extent. I'm actually curious about its angular resolution.

I haven't looked at your past blogs, but it certainly sounds like you are making perfection the enemy of good. Your blogs don't have to be perfect, it just needs to be better than the current state, while not causing unanticipated regressions. Your blogs do not have to be prescriptive either. All you have to say is: I've tried x, y, and z, and it turned out better than a, b, and c in this-and-that manner. Provide your argument, and let readers judge whether your advice applies to their situation.

That said, if you do not have actual data or experience to back up what you are preaching, I definitely welcome the call for caution. It is not useful to insist that "everyone should learn a certain skillset" unless you found those skills relevant in practice in some situation.

It sounds like you've been compiling an interesting collection of stories, ones that might be interesting to a lot of folks here.

People generally expect equality to produce either true or false. Not a tri-value pair.

That interpretation makes sense to me when I read the docs, but is way too easy to miss when I'm actually doing comparisons.

The comparison is fair because it tries to automate expertise.

I'm sure you know exactly how much of which filter to apply for similar results. Laymen like ourselves will need a lot more trial and error. Their contribution here is to provide a push-button, automated mechanism.

I would have probably also tried something simple and given up due to the noise. So this is definitely interesting.

I work in exactly two modes of `gcc` usage. I either accept `./a.out` as the name I deserve, or I write a `CMakeLists.txt`.

There nothing in between.

My trick has always been to rely on tab auto-completion.

    mv foo-<tab>
    mv foo-bar-baz foo-<tab>
    mv foo-bar-baz foo-bar-baz

Downside: you have to at least type `foo-` twice.

Upside: command line history still has the full command.

Why is storage necessary?

Have you ever tried wiring any non-trivial logic without flip-flops? Say, a simple signal routing layer. Even the most basic bits of logic becomes much less efficient to downright impossible without storage.

That is sounds more appropriate for either terminating the program or resumable exceptions like division by zero. In languages with a try-catch construct (specially C++), the complexity of implementing exceptions has to do with stack unwinding. This is where you don't want to restart in an outer context, but want to guarantee cleanup for the call frames you are abandoning.

http://maxima.sourceforge.net/ is closer to Mathematica, and is open source.

Pretty much every successful open source project that people pay attention to is one that has had long-term support behind it. Linux, Mozilla, gcc, clang, git. Almost always, that support begins with the original author.

Protects that don't do that are therefore unlikely to remain interesting for long.

Press release: http://www.academyofathens.gr/en/announcements/press-release...

I can't speak for the toolchain maintainers. But with appropriate flags to force or skip those passes, yes I can see something like this being merged in.

GCC does this too fwiw. Whether or not it is considered a bug, it doesn't have one particular root cause. Several common optimization passes assume small function body. Since functions are typically small, many optimizations use this as a window for heavyweight passes.

In other words, intraprocedural optimisation has always been more aggressive than interprocedural optimisation. If you try inlining every function ever into one giant function, you'll be forced to scale back optimization levels.

TL;DR: Don't autogenerate a large monolithic function. Generate many small functions instead.

The paper: https://arxiv.org/abs/2001.04383

I didn't read the book yet, but I'll take a crack with a couple of examples:

Unix file systems, and its philosophy of "everything is a file". It wasn't common before Unix to interact with devices through a filesystem. Somebody noticed that simple tasks like "listing with ls" and "hex-dumping with xxd" doesn't need separate utilities for files vs devices, and thus made the abstractions converge. If you ask me, this is the kind of abstraction I wouldn't normally think of. It's useful to know what kind of things to be on the lookout for.

The second example is fuzzing. At least today, it's still kind of painful to have to manually write fuzz-tests for everything we care about. Manually coming up with good test cases is also hard. But remember those Monad laws in Haskell? https://wiki.haskell.org/Monad_laws these are essentially free fuzzing code. If I implement something as a Monad, at least in theory I should be able to reuse existing fuzz-drivers to test my new code as well. I probably would not have had the patience to come up with good tests myself. Similarly for other categories. Again, it's good to know what general interfaces already exist.

The part you quoted does not talk about buggy code. Bugs will always exist, the idea is to prepare for them. Migrate systems incrementally, run versions in parallel, have tested rollback strategies at every step, so on and so forth. Not cut corners on backups and contingency plans. Don't rush to launch.

Buggy code is not the problem, but a buggy process is.

I think I'll disagree, and I'm someone with a native Asian language. A character doesn't mean anything in Asian languages, and any attempt to use a fixed-length encoding is pointless. The concepts you want instead are either a code point or a glyph. The concept of a code point is useful as a part (and not the whole) of Unicode-validating, encoding, and decoding. A glyph is useful mostly in rendering engines (i.e. webkit-internals and UI rendering frameworks). Okay, maybe they are also kind of useful for sorting and collating. But fixed-width character encodings are almost never useful, and invite programmer to make assumptions about how strings can be sliced.

Most server-side applications should never have to know what these concepts even are. Or any library that is not user-facing. They get bytes from the UI layer, and they can keep them as opaque bytes. For user-facing apps, you can ask your renderer library for a pixel-width or similar for a string, and let them handle how to parse it. Very little code ever needs to know about unicode.

Any kind of input-sanitization is vastly simplified in utf8, and that makes it worth it for me. For me the really troubling trends are conventions like Rust Utf8Error, where they can cause what I'd consider a UI-related exception in code that had no business even interpreting what those bytes are. Unfortunately, every API uses strings, so they are kind of hard to avoid. It introduces what I'd consider a software layering problem.

Maybe others here with more experience with internationalization can chime in and tell me I'm wrong.

Huh, you're right. I guess I shouldn't be reading this on mobile.