The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
In APL, all operators have equal precedence. To a certain degree, I can understand the arguments for it.
For the very basic operators, it is easy to follow: Do multiplications before additions. But advanced programming languages (APL not the least) has so many operators for which there is no obvious or "natural" precendece. If you want to minimize the number of parentheses, you must have a list of operator precedence available at all times.
I guess that you can trust Visual Studio graying down "unneccessary" parentheses, and remove those. But when you read such minimal-parentheses code, you need that precedence list to see what is happening. You see lots of programmers adding "unneccessary" parentheses so that their C code looks halfway like Lisp , "just to be sure", and in a hardcopy output you have a terrible job finding the matching parenthesis. As a general rule: If your program code to any significant degree depends on operator precedence, or multiple levels of parentheses to override the defaults, then you need to break down your expressions into simpler sub-expressions. The compiler will anyway assign a memory location to hold the value of each subexpression, so you might as well do it yourself, and give a descriptive name to it!
In languages like APL there is one single rule: Left-to-right. Any parenthesis indicates a deviation from this rule: Watch out! So APL programs are never Lisp-like (well, that is one of the reasons ). I sort of like it. Even though I grew up with "multiplications before additions", I cannot off hand tell whether a logical XOR is done before or after a logical shift or an equality test. Which operators have higher precedence tahan preincrement but lower than postincrement? I don't know. I can't list those lower than preincrement, and can't tell just why bitwise negation goes before casting, while logical OR goes after. APL never gives you problems like this.
But, idea behind calculator is: in Standard mode any new operation it calculates as x += 1 or x *= 2, so new operation is applied to result of all previous operations. Which, personally, i don't like, because this can be achieved by pressing "=" button after every operation, but i can understand.
Anyway, problem to me is not this Standard vs Scientific (although using 2 different design algorithms in 1 program is usually really bad thing to do), but that History contains wrong equation. Which means that if you didn't check in which mode you are, result that you used can be wrong. Which can induce different set of problems.
48 is correct, as per natural [germanic based] language which is expressed left to right. same way you read a sentence, in the order presented.
it's 24 if it's "bodmas", but seeing as bodmas is younger than natural language it's absolutely not new math rules,
in fact it's the original and oldest math rules.
and btw: any accountant
1. will tell you 4 X 3 + 4 X 3 = 48, anything else and the auditors will have your skin.
2. in accounting brackets BRACES mean something completely different than others suggest,
.... i.e. 4 X 3 + (4 X 3) = 0 ... 4 X 3 + (4) X (3) = 48 ... 4 X (3 + 4) X 3 = -84
so those old rules are:
- still very much alive
- very important to the person that provisions the money for your pay/salary.
The simple calculator chains together what you are entering following the natural reading order. This has been known as the Arithmetic Order of Operations.
The Algebraic Order of Operations (FOIL, PEMDAS, et al) is followed by the scientific calculator; and is like "compiled" programming, in which you can declare an object anywhere within the class, before or after it is called.
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
I want to be somewhat near my family, at least for easy weekend trips. I don't think Kosovo qualifies...but the company doing the contract work is the same company doing contract work in Romania, so maybe it would give me an "in" for a position there when one opens.
The tax-excluded aspect of it is a big plus, of course.
We won't sit down.
We won't shut up.
We won't go quietly away.