ReDress

>I'm absolutely stuck on your comment that trees are the wrong approach, or that trees are somehow incompatible with precedence. They encode the precedence more explicitly and unambiguously than the original string itself. Trees being incompatible with precedence is like parentheses being incompatible with precedence.

IMO, trees are not incompatible with precedence but I just prefer a more barebones approach to this fairly simple problem.

>The code to create the tree should not complex, so yes, AI could be used, but most competent coders should be able to create a basic version and test it in an afternoon.

I generally tend to find the idea of 'competent' coders misleading. For the most part, I have been developing or writing code in a certain language for while, then it turns out that I am competent coder? Because, yeah, I've been using C or Python for a while and can easily solve a lot of "complex" problems in C but with all due respect, I am obviously not a competent coder. It's like a situation where you frequent a certain part of town that you're very familiar with it and the people living there but then at the same time you don't live there - lol.

Anyways, for this problem I would parse this statement but definitely not into a tree. I'd assign the integrals to objects. I would then parse or go through the statement again executing the operands.

Well...

Thank you!

Turns you have a fairly, if not a very complicated tree for a simple problem. But, fair, enough, you can always get AI to write the code for this and probably, the code will be reused over and over.

But, is it just me or does someone else think that having to rebalance or re-order the tree might be a good breaking point for the camels back?

:-)

I'm not sure whether someone else has commented on this. I am yet to read the comments. Maybe I will read them soon enough.

Anyways and however, speaking in strict mathetical sense, the model of a tree actually breaks the classical mathematical model of operator precedence.

1 + 1 + 1 evaluates to:

     (+)
     / \
   (+) (1)
   / \
 (1) (1)

The above will be correct, mathematically, but will break once you involve multiple mathematical operators in the statement. Because, mathematically, operators have precedence.

The operators are essentially ordered based on their depth into the right of the question / statement but unless I am terribly wrong, this is not the case in mathematics and some operators have higher precedence regardless of their position in the statement.

Any comments on this?

More like old habits go hard - heh

Really I wonder how this turns out to be diskless while you're clearly accessing a disk/drive over the network. Shouldn't we refer to this as network boot?

Andrew has a few videos about waste and the waste industry in countries such as India, Indonesia and Bangladesh.

For instance, in Delhi https://www.youtube.com/watch?v=4Fojw7yviYU

I've been playing around with io_uring for a while.

Still, I am yet to come across a some tests that simulate typical real life application workload.

I heard of fio but are yet to check how exactly it works and whether it might be possible to simulate real life application workload with it.

> Silly job interview questions in Haskell.

Well, it's not clear to me why we're terming these as silly. They mostly seem simple, instead, to me.