It still can panic/abort and deadlock/wait infinitely long on most fp languages because that's typically implied. And there isn't actually a way around that because computation almost always can fail or block indefinitely - and if you have a total language you can implement waits for billions of years, which for all practical purposes is "infinitely" long on human time scales.

Thanks for pointing that out, haven't tried that.

🐟

Why?

Not only for audio, but everything that doesn't have to be an exact base 10 representation (like money). Anything that represents something "analog" or "measured" is perfectly fine to store in a float. Temperature, humidity, windspeed, car velocity, rocket acceleration, etc. Calculations with floats are perfectly accurate and given the same bit length are as accurate as decimal types. The only thing they can't do is exactly(!) represent base 10 decimals but for a very large amount of applications that doesn't matter.

That's not really true and it depends on what you mean. If your decimal datatype has the same number of bits it's not more accurate than base 2 floats. This is often hidden because many decimal implementations aren't 64 bit but 128 bit or more. But what it can do is exactly represent base 10 numbers which is not a requirement for a lot of applications.

You can use floats everywhere where you don't need numbers to be base 10. With base 2 floats the operations couldn't be more accurate given the limit of 64 bits. But if you write f64 x = 0.1; and one assumes that the computer somehow stored 0.1 inside x they already made a wrong assumption. 0.1 can't be converted into a float because it's a periodic in base 2. A very very pedantic compiler wouldn't even let you compile that and force you to pick a value that actually can be represented.

Down the rabbit hole: https://zeta.one/floats-are-not-inaccurate/

"recently", they are the standard for almost 25 years now.

Just saw the image you posted and it's awesome :-) I'm part of the group that can't solve it, because I don't know the 🌭 function from the top of my head. I also found the choice of symbols interesting that 🌭 is analytical continuation of 🍔 and not the other way round 🤣

Chat GPT's answer for me:

Certainly! The expression 6/2(1+2) is ambiguous due to the implicit multiplication. Let's solve it in both ways:

1. Implicit multiplication with higher priority:

[ \frac{6}{2}(1+2) ]

First, solve the parentheses:

[ \frac{6}{2}(3) ]

Now, perform the division:

[ 3 \times 3 = 9 ]

2. Implicit multiplication with the same priority as division:

[ \frac{6}{2(1+2)} ]

Again, solve the parentheses:

[ \frac{6}{2(3)} ]

Now, perform the multiplication first:

[ \frac{6}{6} = 1 ]

So, depending on the interpretation of implicit multiplication, you can get different results: 9 or 1.

I think it's funny that ChatGPT figured out 1 and 9 but has the steps completely backwards. First it points out what has high priority and then does the exact opposite, both times 🤣

Exactly a/b*c equals (a/b)*c but I'd instantly reconsider my position if you can show me a single calculator that would handle that diffently (credible calculator, not the once that some students program for homework assignments).

Even though one shouldn't treat calculators as some kind of authority but if all calculators handle it that way (all calculators of the five major manufacturers, Google, MathCad, Mathematics, various open source CAS) it's probably a very good indictator that it's not ambiguous.

What I also mentioned in the article is that standards and guidelines are typically stricter than most conventions in the name of clarity. So some of them even forbid things like "a / b * c" even if practically everybody agrees how this should be interpreted, just to be "extra-safe"

Regarding the parenthesis the C# static code analyzer can be set to remove unnecessary parentheses.

https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/style-rules/ide0047-ide0048

IDE0047 is the static analyzer rule for "Remove unnecessary parentheses"

The default for those rules is to enforce parentheses on binary operations (because most people aren't as familiar with the binary operator priorities as they are with regular math operator priorities) and remove unnecessary ones in other mathematical expressions.

Besides that I can't remember that I saw a standard that states to only use parentheses if needed but I think it's reasonable ro assume that most people would do that anyway. Writing ((((5+3)))*2) is obviously stupid even though I can't think of any style guide that would explicitly state not doing that.

What many style guides actually state is to use proper fractions (horizontal bar) where ever possible.

Regarding the ambiguity with the implicit multiplication and division. The division is indeed required to make it ambiguous but actually only some kind of trigger

Let's take 6(1+2)/2. Even though the priorities with weak and strong juxtaposition are not the same with respect to the implicit multiplication the answer would be the same but if you would think about the problem like a computer the way to get to the answer would be different (for example the calculators I mentioned in the article would do different things internally)

Strong juxtaposition: you solve the implicit multiplication first because it has higher priority than the division. After that you do the division. Answer is 9.

Weak juxtaposition: implicit multiplication has the same priority as division. You do them left to right and actually end up with the same result even when following different conventions.

So the implicit multiplication is the reason why there are two conflicting conventions (which are necessary for the ambiguity because if there would be only one widespread convention it wouldn't be ambiguous) and the division is required to trigger the ambiguity (show where the two conventions differ).

The LTR thing is actually a very wide spread convention. I'm not familiar will all cultures on earth but my guess is of you use Arabic numerals and + and - you will work left to right for multiplication/division and addition/subtraction.

If one has a bit of math experience you can actually solve multiplication/division and subtraction/addition in any order (if you know what you are doing) like I described here: https://programming.dev/comment/5661037

It depends on what you mean by global agreement as there is no single source of truth but the left-to-right rule is pretty much default for multiplications/divisions and additions/subtractions. If you however have inline power notations with "^" symbol they are evaluated right-to-left. There are exceptions but those are typically well known in the industry. For example MathCad also evaluates powers from left to right, which is fairly untypical.

It's not wrong if you make clear what you are doing. You can for example in a diagram call the axis a and b, not really wrong but pretty untypical if everybody else uses x and y, so you should have at least good reasons when doing it differently.