phao

Maybe this is one of those things like cold reading.

IMO, the text may be seen as a piece of advertising for a fictional "de-programming" (like they call it) treatment from a cult. However, it's written for an abstract general kind of cult, described only in terms of what is common about several cults. It's not specific about anything. Just like well done cold reading: it's right, but unspecific.

I believe the idea is that you identify some of the things you're doing in your life as a cult (guided by the general features given in the text) and pay more attention to them. The text, however, is vague enough to classify a lot of things as cults, even though you/I/we may believe these aren't.

I've just spent the last 30min-1h looking this up. I think I might have a form of this... Mostly, I can't really picture stuff. I thought that was just everyone.

Gotta find out more about this!

He is mostly talking about computational linear algebra problems of a large scale type due to large matrices: the "computational intensity" comes from having really large matrices (kxk for k = 100's, 1 000's, 10 000's, 100 000's, 1 000 000's, ...).

In computer graphics, the situation is often different. Usually, you have small matrices (kxk for k=2,3,4); a huge number of vectors; and you want to apply your matrix to all of those vectors. Very often, these matrices have very well known forms and also known well behaved inverses. There isn't really a significant computational cost in computing the inverse (you'll very often write down its formula by hand), and conditioning is usually not an issue (consider a rotation matrix for example or undoing translations with homogeneous coordinates).

With Newton's method, you'll be solving Hx=g (H = hessian of f, g = gradient of f) at each iteration. For large number of variables N, building H is of order N^2 and solving Hx = g is of order N^3 with an usual solver. N^2 and N^3 are really large for an already large N. I believe the reason is as simple as that. It isn't that it is tedious and difficult to write down the formulas or the code to compute H. It's just too costly, computationally speaking. There is also an increased memory cost (possibly having to store H).

When people do have ways to go around this problem, they do use Newton's method for large scale problems.

By the way... which font is being used in the readme screenshot?

https://github.com/helix-editor/helix/blob/master/screenshot...

Directly, I believe this has more to do with people interested in the language seeing it being used in actual projects.

Indirectly (a lot indirectly), sure. Maybe the software should perform better or maybe have fewer bugs because programming language X or Y is understood to help with those things. Maybe it showcases a more flexible architectural design, which leads to more potential features in future versions, etc.

Very sincerely, you must read just about zero tech news.

Not 0, but really not much, that is true.

I remember the shutdown of google reader. I tried it once, but let go of it before it was shut down.

But I really didn't know google had this kind of reputation.

Super sincere question.

Google's reputation for not supporting things long term

I didn't know Google had such a reputation. I mostly use drive and gmail, so it was fine to me.

Does google really have such a reputation? Any place I can read more on this?

In my view, because pi crops up unavoidably in math, if you concoct a "unit" to get rid of pi in one place, it will simply crop up somewhere else, perhaps in a denominator.

That doesn't mean you shouldn't try to put it in a convenient place.

One way to think of the post is: where you want pi to come up?

With arc length parametrization f(r) = (cos(r), sin(r)), it comes up in the parameter space (one turn: 0 <= r <= 2 pi). If you had the whole thing in terms of turns, you'd instead have (as a primitive) some kind of function g(t); with one full round for 0 <= t <= 1. It'd then have to be true that

f(2 pi t) = g(t) = (cos(2 pi t), sin(2 pi t)).

Pi would come up in the velocity:

f'(r) = (-sin(r), cos(r)) = if

(i u means rotate the vector u by 90 degrees counter-clockwise)

g'(t) = 2 pi f'(2 pi t) = 2 pi (i f(2 pi t)) = 2 pi (i g(t))

Before, you had |f'| = 1. Now you have |g'| = 2 pi.

For classical physics (kinematics and dynamics) applications and classical geometrical applications (curvature, etc), it's really convenient to have that speed term (|f'|) being 1. This is one of the major motivations for arc length parametrization.

By the way, this can't be understated. It really simplifies kinematics, dynamics, geometry, etc, having |f'| = 1 throughout. It's not just for circles. This can be done for an extremely large class of curves and it makes the related math much more understandable and easier to deal with.

For a lot of computer graphics (I believe this is where Casey comes from), you care less about tradicional mathematics for physics and geometry. So you'd rather (maybe) take this pi appearing in the parameter space and push it to the velocity.

The major motivation for radians is arc length parametrization, really. Meaning that in a circle of radius 1 unit (in whatever measurement unit you've chosen), an arc formed by a k-rad angle measures k units. There is an intentional coincidence of angles and arc measurements.

I see it in a lot of matlab code as well.

performance tends to be a major objective

My comment is about the thinking behind making this decision, C++ or not. It wasn't "is it speculative that GC will add a cost?" or something like that.

I wonder how much of the thinking that leads one to conclude "I need so much performance here that I can't afford a managed language", for example, is real carefully thought vs. speculative.

I wonder how much of (2) is speculative and how much of it is a real need in actual projects.

For numerical and scientific (high performance) jobs, possibly not that much harder than C++. For other jobs, I doubt it and would stick to C++.

The issue is that, for example, you might be getting people with poor software engineering training per se. You risk hiring some very smart phd that writes code that works and runs really fast, but isn't that readable, extendable, maintainable, testable, etc.

Where could one go to read more about the mathematics behind the format, its compression techniques, etc? I remember reading that jpeg 2000 is based on wavelets. Is this the case for jpeg xl?

This, I believe, touches upon the accidental versus essential complexity theme.

I believe people, in general, agree C is too simple of a programming language to actually deal with all the essential complexity of modern software development in various cases.

The actual complaint people have about C++ is that it has too much extra unnecessary accidental complexity due to weird ways features interact.

The analogy of the Surgeon I believe should be adjusted having these two points in mind. Generally speaking, surgeons would agree that "scalpel and whiskey" are too simple of a tool set for doing modern surgery. However, if you take modern surgeon tools and add a bunch of weirdness to them, then surgeons would reject them on the grounds of being more complicated than needed.

A bad surgeon could also be overwhelmed by the amount of modern tools and use the wrong one.

When this is contrasted with the C++ situation, I believe the comparison would be fair only if all the modern features in C++ had to do with the inherent essential complexity of software development. That is not the case (at all). Expert developers have been talking about how C++ is unnecessarily complicated for ages (before C++03 even; back when things were simpler in terms of weird language feature interactions).

One of the thing that isn't obvious to me that seems to be for many people is the decision to maximize expected value instead of best worst case scenario. In this situation, given how exceptional the 100%1M vs. 50%50M situation is and how the 1M will definitely kill your financial problems, it really does seem like you'd like to pick the strategy that maximizes your worst case scenario (if choice=red, worst-case=1M; if choice=green, worst-case=0). I understand the reasoning behind expected values, I guess, it's just that it's not clear to me it is of any use here.

To me, the choice looks like "solve your financial issues with the red button; 100% chance" vs. "solve your financial issues and get extra money you won't really need, but with 50% chance through the green button".

I'd have a hard time choosing the green button.

It's curious because I'm a mathematician. I feel like I should know this better, but I've never really studied probability, much less statistics or economics.

(edit)

Another issue is what would it mean, in practice, that "50%" statement? I guess it means that if you'd play the game long enough, 50M would come out roughly half the times (by counting). This could mean a system in which the first 10 always fails, the second 10 always succeed, and the ones after that have their results based on a fair dice (1,2,3->50M; 4,5,6->0). This would certainly fit the frequency "definition". In practice, these probabilities don't mean a clean neat thing very often. Another issue is that the definition of that 50% means if you played that game long enough, you'd observe the half-half split, but you'll play it only once. Again, there is a statement about a limit (a statement about a_n, for n large), but you're only looking at a_1 (it often seems to me that people believe that information about EV transfers to information about a_1 -- it really does not). Even though I can mostly think of artificial examples (stuff like the one above), I'm not sure it'd be clear [in an actual situation] what is the meaning of that '50%'.

The investor's situation, I believe, is very much different from the common person's. The investor put him or herself in the position of doing tons and tons of financial transactions and investments, etc, like that. He or she put him or herself in a situation such that EV-reasoning makes sense. It seems to be that this isn't the situation for the common person.

But I agree... If you are an investor, or maybe a professional poker player, then you'd have put yourself in a position that favors reasoning guided by EV.

There are other ones as well, non-money related. For example, in sports. I believe basketball players probably try to do this. There are so many shots. They're probably using EV to guide their strategy and practice.

I think I get it, but I'm not so sure I'm convinced. Those examples, however, don't resonate with me (don't have a car, nor a license to drive one; nor I own a house; I've been inside an airplane only once).

However, I believe I've done similar things with used electronics. I tend to favor buying a really cheap used ones for [sometimes] 1/5 of the price instead of a new one. It could break or be of low quality, but chances of that are small and thus (over time -- making an EV-ish calculation), I spend less money on electronics.

I also believe I do this in buying new products. In many situations, I can pay extra for an extra year or two of 'guarantee' (not sure if the right term is 'guarantee' or 'insurance'). However, very often, the first 6 months or 1 year of guarantee is given and has its cost embedded in the price of the product. The question becomes: how likely it is for the product to fail given it hasn't failed for the first year. I believe the chances are small so I don't buy it. I guess it's also an EV kind of calculation (just like you gave as an example).

However, those don't seem that common, really. Maybe it's just the kind of life that I live.

Is the situation 100%1M vs. 50%50M supposed to exemplify these ones? These not-so-frequent ones for small amount of money?

Another thing is that expected value has to do with a limit in this situation:

(1/n) x SUM [j = 1 to n] outcome(j) -> E for n -> oo

(there is an ergodicity assumption going on here -- which doesn't always hold in practice). That limit can be E while the first idk how many hundreds of values of outcome(j) be very distinct from E.

How many times will things like that happen in your lifetime? Some dozen? What if you separate away the large-scale ones (like the 100%1M vs 50%50M)? The small-scale ones will be more frequent and you just blindly follow the EV approach to them. The large scale ones will be extremely rare, and maybe another approach is better. No?

I suspected that much (that it was an analogy for some kind of actual situation).

But what situation? How is it that a person's life has many of these chances in large enough volumes to make expected values worth it?

your life will have plenty of such games

What are you talking about? Which life will have plenty of such games? In what way is that true?

I wonder how relevant operator overloading can be without things like RAII and move semantics (thinking in comparison to C++), or without some kind of managed environment.

Would this be useful only for simpler and smaller objects?

I'm not really familiar with more modern C. So maybe C11 (or possibly later versions) introduced a way to handle this. I'm not sure.

About drafts...

Iirc, the last draft before final publication is free and it's just as good.

As another user replied, there is more going on in the post than what is specified, guaranteed, etc, by the standard.

The practice of C programming in an actual system using non-standard things is important. Also, the C language does have its problems, even within the standard. However, pinning to C problems of a not-so-helpful implementation, library, system, etc, is unfair and unhelpful I believe.

Right, but is he relying on the standard (the C language specification is an ISO standard, btw) behavior guaranteed by the language? Or is it talking about some implementation specific behavior that also happens to fall into the name of fopen, fread, etc?

For C programmers, talking about "standard" implies a quite particular meaning.

Using FILE*, fread, fgets, fscanf, ...

Yep... The "slightly better C" seems pretty universal as far as I've seen. A lot of people just want that it seems. It's not clear what that would look like though. It's a shame.

Have you seen Terra? http://terralang.org/

C allows more than 1 representation for integers. I know at least 3 possible ones: two's complement, ones' complement and signed magnitude.

The "natural wrap up" is not the same in all of the representations.

When the integer is unsigned, C gives you more guarantees, but for signed types, you're out of luck, and get to undefined bahvior land.

Check this out: http://web.torek.net/torek/c/numbers.html

And as an after note...

The maximum int may be less than 2^31-1. Maybe your C implementation decides that your int type will be a 16bits object with values ranging from -2^15 to 2^15-1. In that case, that integer literal would not be an int, and is likely to be a long, and maybe, in this same implementation, a long is a 61bit object ranging from -2^63 to 2^63-1. In that case, that assertion is just plain false. That's not the system exposed in the article though. But it could happen in some other system.

This can be true even on a 32bit system.

Very interesting! But I'd say this is too dangerous because of the misleading conclusions that it'd "make" you realize.

Relying on what is printed out of printing a pointer value (which is not what the author is doing) is also misleading. Concluding stuff like "the size of an int is 4" or "size of double is 8" is also misleading. Again, it's not the conclusions the author is realizing, but for someone doing exploratory programming, it may be the case since the point of exploratory programming is learning by seeing how the system responds to the things you're doing.

And maybe I am wrong, but even the author got mislead by it.

"I'm going to ignore why 2147483648 == -2147483648; the point is that even arithmetic can be tricky in C, and gdb understands C arithmetic."

That's actually the result of undefined behavior, and not so much a result or "how C integer arithmetic works".

I really liked the idea. I just think it may be misleading if the tool you're using is GDB.

It'd be interesting a tool which allowed that sort of exploratory programming, but taking into consideration undefined behavior, unspecified things and implementation defined behavior.

23% female?!!!!!!!!!!!!!

It seems that way.

I am enjoying it. I will see how far I can go.