Free Software should rename to Liberty Software. Instead, advocates loaned Spanish "libre" in the ugly FLOSS acronym (Free/Libre Open Source Software). If only we used "liberty" then we could stop quibbling over the multiple meanings of "free" and just talk about software liberty.

"Free as in bonus" vs "free as in liberty".

later, ... there are 14 competing jargon files.

"Free software" is a fine descriptor. It's needlessly confusing to repeat that "beer as in slurred speech" thing, though. Free software can be free "as in beer"[0], but the way it gets said makes it sound like it zero cost software is an anti-goal, rather than pointing out that it's not the true goal. Then the "free as in speech" thing is kind of pointless because you can just say "free as in freedom".

Free software is about fundamental computer freedom -- freedom to own your computer, inspect and modify, etc. -- we already have this word.

[0] where who why free beer ever? 0% relatable, 0/10 would still like a free beer though

Newcomers keep tripping on Free Software vs Freeware, therefore "Free Software" doesn't describe well. We could call it Freedom Software. (There now exist 15 competing jargon files.)

>In my failing democracy

Which nation, may I ask?

Lee Drutman advocates for ranked choice voting, but implementations in the USA still degenerated to 2 parties. RCV still has a spoiler effect. https://realrcv.equal.vote/alaska22 https://www.youtube.com/watch?v=yhO6jfHPFQU

Instead, we need approval voting, or even STAR voting. https://www.equal.vote/

(Drutman appears to have somewhat changed his views on RCV, but I don't think his "fusion voting" idea will catch on until we have multiple parties in the first place. https://www.newamerica.org/political-reform/blog/how-i-updat... )

We need to change the voting system in order to dissolve the two party system, per Duverger's law. Ranked choice voting will not work. Approval voting or STAR voting would work.

https://www.equal.vote/

Totally agree. I haven't looked into that before, but taking a look now. Thank you for including that link.

You're welcome. Here's also a video on simulating plurality, RCV, and approval voting. https://www.youtube.com/watch?v=yhO6jfHPFQU

I thought the same, so I programmed the examples into Desmos 3D (click the show/hide buttons on the left).

https://www.desmos.com/3d/3divdux6jh

Dropping the absolute value makes a better visualization. The 3D graph for Example 4 Shadow Line has an established name, a hyperbolic paraboloid. The color graph for Example 5 Phi Equation doesn't capture the odd symmetry F(x,y)=-F(-x,y). The color graph for Example 6 Underwater Islands looks far inferior to the 3D surface.

Interesting. I didn't know you could plot like this in Desmos. Thanks for doing the work to plug them in.

No problem. While fuzzy graphing has existed for a long time as contour plots, I'd still like to encourage you to experiment more. The colors look pretty. :)

I have a suggestion. Calculate z=left-right without absolute value, and try mapping [negative limit, 0, positive limit] to [black, red, white], or possibly [negative limit, 0, positive limit, outside of limits] to [red, white, blue, black]. And of course, do variations and have fun!

I'm not sure I've tried that - might good idea. I've actually been playing with all kind so of visualizations - I've done most of my art as stand-alone Python scripts. Here's an open-source starting point for doing this kind of math art in Python: https://github.com/calebmadrigal/truthygraph.py. You might want to try your idea yourself :)

That trades "min <= max" with "min + interval <= MAXINTEGER":

  if(number < min) return min;
  else if(number < min + interval) return number; // "if(number < max)"
  else return min + interval; // "return max"

You implicitly used an axiom to ignore the differences between the apples. Someone else could use different axioms to talk about the sizes of the apples (1 large + 1 small = ?), or the color of the apples (1 red + 1 green = ?), or the taste of the apples (1 sweet + 1 sour = ?).

People "axiom" their way out of 1+1=2 in this way: by changing the axioms, they change the topic, so they change the conclusion. I observe this pattern in disagreements very often.

I have used appropriate axioms, not arbitrary axioms. If you want to talk about size or color or taste, you would use “axioms” appropriate for you case.

Some other definition fun: Should we define 0 both positive and negative, or neither positive and negative? Does monotonically increasing mean x<y -> f(y)<f(x) or x≤y -> f(x)≤f(y)? Should we deny the law of excluded middle and use constructive math? Does infinity exist? If infinity exists, is it actual (as an object) or potential (as a function)? Is the axiom of choice true? Or, is the axiom of determinacy true?

Should we use a space-time manifold, or separate space and time dimensions? Do future objects exist, and do past objects exist? Do statements about the future have a definite truth value? Does Searle's Chinese Room think? Which Ship of Theseus is the original: the slowly replaced ship, or the ship rebuilt from the original parts?

I find that so many philosophy debates actually argue over definitions rather than practical matters, because definitions do matter. Well, add your own fun definition questions!

What's worse, French typically uses positif to mean "greater than or equal to 0", so some people will act confused if you use English 'positive' instead of 'strictly positive' to mean "greater than 0".

I think that you can omit the call to malloc, as realloc(NULL, size) does the same thing as malloc(size), and free(NULL) does nothing.

  void *sane_realloc(void *ptr, size_t size)
  {
     if (size == 0) {
       free(ptr);
       return 0;
     } else {
       return realloc(ptr, size);
     }
  }

Unfortunately, when shrinking an array down to 0, you run into a complication. Detecting allocation failure now requires checking both size > 0 and sane_realloc returning 0. To simplify this further, just always allocate a non-zero size.

  void *saner_realloc(void *ptr, size_t size)
  {
     if (size == 0) {
       size = 1;
     }
     return realloc(ptr, size);
  }

But the second sane_realloc now never frees. That's a problem shared by by the ISO C realloc.

According to ISO C, size zero can behave like this:

  free(old)
  return malloc(0)

and if malloc(0) allocates something, we have not achieved freeing.

There are ways to implement malloc(0) such that it returns unique pointers, without allocating memory. Or at least not very much memory. For instance we can use the 64 bit space to have some range of (unmapped) virtual addresses where we allocate bytes, and use a compact bitmask (actually allocated somewhere) to keep track of them.

Such a scheme was described by Tim Rentsch in the Usenet newsgroup comp.lang.c.

If an implementation does such a thing, adjusting the size to 1 will defeat it; allocations of size 1 need real memory.

(I can't fathom the requirement why we need malloc(0) to be a source of unique values, and why someone would implement that as efficiently as possible, when it's implementation-defined behavior that portable programs cannot rely on. Why wouldn't you use some library module for unique, space-efficient pointers.)

I would never rely malloc(0) to obtain unique pointers at all, let alone pray that it is efficient for that purpose.

I'd be happy with a malloc(0) which returns, for instance, ((void *) -1) which can be hidden behind some #define symbol.

saner_realloc isn't realloc; it is our API, and we can make it do this:

   #define SANE_REALLOC_EMPTY ((void *) -1)

   void *sane_realloc(void *ptr, size_t size)
   {
     if (ptr == 0 || ptr == SANE_REALLOC_EMPTY) {
       return size ? malloc(size) : SANE_REALLOC_EMPTY;
     } else if (size == 0) {
       free(ptr);
       return SANE_REALLOC_EMPTY;
     } else {
       return realloc(ptr, size);
     }
   }

Now, a null return always means failure. The shrink to zero, or allocate zero cases give us SANE_REALLOC_EMPTY which tests unequal to null, and we accept that value for growing or freeing.

The caller can also pass in something returned by malloc(0) that is not equal to null or SANE_REALLOC_EMPTY.

I forgot to mention my own opinion. I think that malloc(0) ought to return a 0-sized object, and likewise realloc(ptr, 0) ought to resize the object to 0. Malloc and realloc always allocating feels more consistent to me. For a practical example, I have some code that reads an entire FILE stream into memory. This requires realloc with doubling the size every time. After finishing, I'd like to resize the buffer down to the total bytes read. If it reads 0 bytes, I'd like it to resize the buffer to 0.

I think my sane_realloc never freeing has much simpler behavior. As much as I hate the needless waste of 1 byte, if my code allocates thousands of 0-sized objects, I'd rather fix that before adding complexity to my sane_realloc.

With yours solving the 1 byte problem, it still interests me. We can simplify your code slightly.

  #define SANE_REALLOC_EMPTY ((void *) -1)

  void *sane_realloc(void *ptr, size_t size)
  {
    if (ptr == SANE_REALLOC_EMPTY) {
      ptr = 0;
    }
    if (size == 0) {
      free(ptr);
      return SANE_REALLOC_EMPTY;
    } else {
      return realloc(ptr, size);
    }
  }

A zero-sized object is immutable, since it has no bits to mutate. The pointer cannot be dereferenced. It may be compared to other pointers. So the question is: do you want to obtain unique zero-sized objects, or are you okay with there being one representative instance of all of them? If you're okay with one, you can just call SANE_REALLOC_EMPTY that object. I called it EMPTY on purpose; it represents an empty object with no bits.

If you want unique zero-sized objects, you can always simulate them with objects of size 1. The allocator API doesn't have to make that choice internally for you.

Like you, I have no idea what use the unique 0-sized pointers would provide. SANE_REALLOC_EMPTY is certainly adequate for me. Thank you!

In a Lisp implementation, I could use unique, zero sized objects to implement symbols. The gensym function would create a new one.

Zero-sized distinguishable objects can have properties attached to them via hashes. At the API level, you cannot tell how a property (e.g. symbol-name) is attached to an object.

Properties, like the symbol name, would be attached to these objects via hashes.

It's not an ideal representation for symbols when all symbols have a certain property, like name.

If you have objects such that they have certain properties, but the properties are rare (only a few objects have a value of the property that requires storing space, and for the rest it is some "undefined" value, you can achieve a sparse representation by making the objects as small as possible, attaching the properties externally.

>unsigned is trivial (just test `a+b < b`)

Nitpicking, the test itself should avoid overflowing. Instead, test "a <= UINT_MAX - b" to prove no overflow occurs.

For signed integers, we need to prove the following without overflowing in the test: "a+b <= INT_MAX && a+b >= INT_MIN". The algorithm follows: test "b >= 0", which implies "INT_MAX-b <= INT_MAX && a+b >= INT_MIN", so then test "a <= INT_MAX-b". Otherwise, "b < 0", which implies "INT_MIN-b >= INT_MIN && a+b <= INT_MAX", so then test "a >= INT_MIN-b".

> Nitpicking, the test itself should avoid overflowing.

Why? Overflowing is well defined for unsigned.

Personal preference, hence nitpicking. It forms a special case of the signed integer algorithm, which feels nice.