davidgrenier

I think he's talking about company enshittification because of marke pressure, and not direct fraud though I haven't read the book.

Yeah I guess two companies who would otherwise be considered going for bankruptcy have models too expensive to run. As they don't see themselves making money any time soon, they have to turn every future model into a weird fascination.

I wonder how gracefully redgrep handles this. This tool hasn't been talked about since the year of its release. If I recall correctly, it doesn't handle some obstruse regexes the way conventional tools do however.

https://github.com/google/redgrep

There's only one "other side" in this, it's the American people.

v4l2-ctl on linux allows me to change such settings on a global level, maybe that might work if a version can be found on his OS.

I think the author is generous in granting that Caro-Cult programming works.

I haven't looked at Hardy's but the presentation in Spivak is also Dedekind cuts. Perhaps Hardy uses a different approach and OP misnamed it? Rudin's chapter 1 annex also use Dedekind's cuts.

Where we define the real numbers as the least upper bounds of special sets. There is a bijection between these sets and the set of real numbers which we commonly think of and that bijection is the least upper bound of such sets.

Your very last example kinda supports the thesis up there, considering how it's been going.

Correct me if I'm wrong but (log n)^O(n) sounds like atrocious complexity?

LP or ILP? There is a significant difference since for non-discrete problem Linear Programming is shockingly efficient and in no way can be considered a brute force technique.

edit: What would be a technique you consider non-brute force in discrete problems?

I was speculating two oscillators with periods p and q could be composed (as long as there was no way for them to interact) to create an oscillator of period p*q/gcd(p,q) but wondering why large primes wouldn't be a problem.

I guess this is my answer.

I think his argument was restricted to a human-produced mathematical result being ported to a Lean program where one would be just as likely to commit a mistake. However I disagree as well, I recall the difficulty of expressing what I wanted to Coq being a barrier to expressing it incorrectly.

Good teacher, his Number Theory book felt really good though I have no comparable in Number Theory. I must say Number Theory and Combinatorics are the most difficult topics I got acquainted with in undergrad.

Bouty makes excellent chair. Looking at their website I'm thinking Arista/Kadera/Fira. The model of chair I have doesn't seem front page but it is the Sity 9002.

The piston gave after 10+ years of service. Contacted them, warranty is for life, they had someone show up and replace it for free.

It isn't though: https://github.com/mrLSD/riscv-fs/blob/fa039b123ded9fa0c05d0...

I think this qualifies?

https://en.wikipedia.org/wiki/MMIX#Simulators_and_assembler

My understanding of this is that it is an emulator that is meant to be very clear to read.

Someone mentionned in the Mastodon thread that they have an Android phone with nothing-from-google on it. I speculate his installation is even more responsive than whatever default the product came with and I'd like to do that.

I have a terrible Vankyo Z1 table that is very slow. Where do I start?

Note that lightweight threads (even in CSP style concurrency model) can be even lighter and faster. F#'s Hopac library seems to meet such expectations with this simple program:

   #r "nuget:hopac"

   open Hopac
   open Hopac.Infixes
   open Hopac.Extensions

   seq{1..1000000}
   |> Seq.Con.iterJobIgnore (fun _ -> timeOutMillis 1000)
   |> run

10M threads sleeping 10 seconds taxes this machine to:

22s real, 4m user, 0.506s system @ 140 bytes/thread.

But isn't what makes numpy efficient written in C?

Will double check both systems I have access to, thanks.

This looks brutal, for a lot of people John Reppy's book Concurrent Programming in ML (as in SML not Machine Learning) is going to be much more accessible. Pick the CSP-style library in the programming language of your choice.

Go with goroutines and channels

Clojure with core.async

F# with Hopac

It would be a very interesting project to roll your own in C# using Microsoft Robotics Studio's CCR (Coordination and Concurrency Runtime) (though I speculate those are buffered channels by default).

Pro-tip, F# has an extremely efficient CSP-style concurrency library called Hopac.

F# is extremely expressive, has algebraic datatypes and just about everything C# has to offer. It has a REPL so you can write your code interactively and make fast and safe progress. .net is practically first class on Linux now.

Start your .fsx script with: #!/usr/bin/dotnet fsi

When startup time becomes a problem you can compile the file to an assembly instead.

Yes, maintaining your proficient in QWERTY is only a matter of not stopping to use it altogether when switching to a new layout. It'll just be a matter of time spent to become fluent in both. I recommend Colemak however.

I personally didn't maintaing typing on QWERTY, interestingly my brain still has the QWERTY mapping for tablets.

I had never heard of the concept of closest average neigbor before. When I read it, I assumed it meant: draw a straight line between the two bodies, that is the current distance between the two bodies, now average it over a couple of years of motion of these two bodies in space.

Yes, this is what Ur/Web does albeit this is limited to Web Server requests. I'd argue all programs could be short lived and memory management becomes a matter of sizing program's scope/role to the amount of memory you can greedily consume. Certainly many sorting program (for e.g.) can leak until they terminate. Then, cheap instantiation and communication between programs.

    "Since we know that infinite densities cannot actually happen in the universe"

Oh another thing, I'm not a fan of the premise:

"As a general-purpose memory allocator, though, we can't get away with having no free implementation."

I have a belief that the future of software are short-lived programs that never free memory. Programs allocate and terminate. Short-lived program communicate with each other via blocking CSP-style channels (see Reppy's Concurrent Programming in ML).

If you could also educate me on why this is a bad idea I would appreciate.