Should old Henry catch a herring trawling off America or Sir Olivers horse came ambling home to Olivers aunt.
'Surprisingly' (to me) low PF of gadgets
- Thread starter JohnW2
- Start date
And if you believe in BODMAS then watch this for a mind blower
If the desired order of operations is not completely and explicitly defined within the expression (by use of adequate parentheses), then there is no alternative other than to rely on some strict and consistent convention such as BODMAS.
There may well be exceptions of which I'm not aware (and I'm not counting languages which require Reverse Polish notation for expressions), but I am not personally aware of any computer language which would not give the (present-day) BODMAS-correct result (9) for the expression discussed in that video - even though that is probably not the result that many people who 'sloppily' wrote the expression like that would expect.
In other words, if one intends 6 / (2*{1+2}), then that's what one should write
Kind Regards, John
Possibly APL - can't remember how that deals (if it does) with parentheses. If it ignores them the answer would be 5.
They wouldn't have parentheses.
6 2 ÷ 1 2 + x
I've got a calculator which uses RPN - it never goes well lending it to someone.
Indeed.
The first computer I built, around 1980, used RPN, because it used an available RPN calculator chip as a 'maths co-processor' (to avoid me having to try to programme all the maths functionality, in machine code, within an 8 kB memory limit
), so I got quite used to it.Kind Regards, John
Ah yes, RPN - wonderful stuff and you can so things that look a bit like entries for an obfuscated C contest 
I imagine it's also much easier to program an interpreter for since the order of operations is completely explicit and execution is "just" a matter of popping things on/off a stack. It's used by RRD Tools which (from queries on the mailing list) seems to confuse a few people.
I imagine it's also much easier to program an interpreter for since the order of operations is completely explicit and execution is "just" a matter of popping things on/off a stack. It's used by RRD Tools which (from queries on the mailing list) seems to confuse a few people.
My obfuscated memory tells me that infix notation can be converted in one pass to postfix by pushing/popping the operators, not the operands, so it's not a massive computational task to do that first.
That's certainly always been my understanding as to how/why RPN arose.Ah yes, RPN - wonderful stuff and you can so things that look a bit like entries for an obfuscated C contest
As you say, the main advantage is that the instructions are totally explicit - i.e. "what you type is what you get" - without any possible ambiguities or uncertainties about 'interpretation'. In most senses, it's really just a matter as the human being have done all 'interpreting' (of however he/she might otherwise write the expression) before talking to the machine.
Kind Regards, John
6 2 1 2 + x ÷
It's a long time since I last had to think about this, but doesn't that mean:
(1+2) x 2 ÷ 6 (= 1)
... which is not the same (per BODMAS) as 6 ÷ 2(1+2)
Kind Regards, John
No - it means 6 ÷ (2 x (1 + 2)).
It's the "other answer" to the expression in the video, as described in it, according to the conventions of 100 years ago. And if the commentary is right, and the problem has had millions of comments on social media, how some people say it should be evaluated today, it being unlikely to have attracted that many comments if nobody disagreed with (6÷2) x (1+2).
I posted what you'd get as input to your RPN engine if the human being doing the conversion to RPN interpreted 6÷2(1+2) the "other way". RPN may have no ambiguities or uncertainties about interpretation but that doesn't mean that there aren't potentially some in the pre-RPN stage.
Ah, there clearly is more dust in my memory than I thought! As you will realise, I was thinking that when one put several operators after several operands in that fashion, that the operands would be dealt with in reverse order.
Yes, once one has corrected my faulty memory as above, that all makes sense.
Kind Regards, John
I've just dug out some extremely dusty notes I made (longer ago than I care to think about) regarding APL.
As you half-suggested, it seems that it doesn't 'deal with' parentheses within expressions at all - but I'm not sure whether their presence is ignored or generates an error. That means that there is not really any way that one could test how it would deal with an (intended) "(6 / 2) * (1+2)" [ the 'modern BODMAS' meaning of "6 ÷ 2(1+2)" ], since the user would have to translate it into something else, on the basis of their belief as to what translation was required. It seems that APL generally worked from right to left, taking combinations of operands and operators (as we would call them) as it finds them (but, to confuse things, uses "operator" to refer to something other than what you and I understand by the term!)
On the basis of a very quick look at my notes, I think that the following might (but no promises!) achieve "(6 / 2) * (1+2)" in APL ...
6 x 2 ÷ 1 + 2
Kind Regards, John
How about 6÷2(1+2) expanded becomes 6÷2+4 which then becomes (under BODMAS) 3+4 = 7 
DIYnot Local
Staff member
If you need to find a tradesperson to get your job done, please try our local search below, or if you are doing it yourself you can find suppliers local to you.
Select the supplier or trade you require, enter your location to begin your search.
Are you a trade or supplier? You can create your listing free at DIYnot Local
