So now we are talking about my algorithm, so I created a plan for you to choose from. No matter what you choose. Thank you. Really, thank you @cameron

Plan A
I will try to apply the things I learned from the discussions and rewrite the code. which I assume will take weeks or months.

Plan B
I will use icecream to explain the algorithm of the calculator in an implicit way? mix with comments to try to be explicit.

Plan C
I really do respect you and am grateful for all the wisdom you shared with me, but I feel like I bothered you for far too long. I really respect and understand if we were going to end it here.

So I made a little progress, and now I’m starting to try to apply what I learned in this discussion, but I have one question.

What do you mean by “another change”?

Do you mean I should add nested brackets like your example (3.0 * (4 + 7))?

I assume you didn’t run my code for security reasons. And I understand that, but my basic calculator algorithm is correct math-wise from my perspective because I tested it several times.

So I made a little progress, and now I’m starting to try to apply what
I learned in this discussion, but I have one question.

What do you mean by “another change”?

I meant this:

The change I’m thinking of suggesting is to progressively reduce the
expression until there is a single number left, or a syntax error (no
matches). If you do that you don’t need to count brackets or anything -
just consume them in their innermost pairs until you can’t.

So your order of evaluation precedence is something like:

( number op number )

number * number

number / number

number + number

number - number

Do you mean I should add nested brackets like your example (3.0 * (4 + 7))?

No, i meant to treat the task as a symbol manipulation problem, not a
“math” problem. Which you’re kind of doing already. But by selecting the
“most tightly bound” expressions from the entire string, one at a
time, you can reduce the string in steps. At the end you either have a
result, or you have a syntax error. And you don’t need to write very
complex regexps to do it.

I assume you didn’t run my code for security reasons.

You code seemed benign - that wasn’t it. I was just looking at it
semanticly instead of “running” it.

And I understand that, but my basic calculator algorithm is correct
math-wise from my perspective because I tested it several times.

The operations are. I was less convinced that the high level precedence
(MDAS) stuff was, because of the way your regexp tests were written.

I will try to change the algorithm without using regex.

That is what my algorithm does, e.g., 47 + 478 * 7, which will get the second priority in this case, 478 * 7. Then it will calculate it, which equals 3346. The last step is to replace the string with the result, which is equal to 47 + 3346, then repeat. The result is 3393.

But. Yeah, I can solve this without using regex, which I originally used with arrays when I tried to create the algorithm; that’s why I said I couldn’t remember how many times I changed the algorithm, and it feels like it was a month before I used regex. Probably because I did not try using while loops to calculate each one one by one, this may be the reason I have had a lot of problems in the past.

The usual method of parsing expressions, and programming languages in general, is by “recursive descent”. Even regexes are parsed by recursive descent.

That seems too complex for me. I’m just going to try to use arrays or lists to solve my problem. But thank you @MRAB for the information. much appriciated.

@cameron
Just an update: I’ve already done, if not almost done, the calculator algorithm without using regex. I just have to clean it up. but I’m not going to post it yet! I still want to apply what I learned here to my whole code, but I can’t wait to post it and learn more!