Using, head, as many different calculators that you have to hand (especially if you have an iPhone or Windows calc) what result do you get from the following sum.
At 02:02 PM 3/10/2012, cdb wrote:
> I saw this on an RISCOS enthusiast website.
>
>Using, head, as many different calculators that you have to hand
>(especially if you have an iPhone or Windows calc) what result do you get
>from the following sum.
>
>6/2(1+2)
>
>Type it in exactly as above.
My HP calculators are RPN, so they come up with the same answer that I got by doing it in my head: 1
Same with my PC-based calculators - they are all also RPN.
That's based on doing: 6 [Enter] 2 [Enter] 1 [Enter] 2 [Enter] [plus] [multiply] [divide].
However, it seems logical that one could also get an answer of 9, by using the logic that multiply and divide operations are supposed to be position-independent. By that, I mean that it shouldn't matter in which order one does multiply or divide functions.
Regardless, I fall upon the old mnemonic phrase for order of math operations that my Maths teacher gave to me way back in grade school: BOMDAS = Brackets, then Odd_Functions, then Multiply, then Divide, then Add, then Subtract.
My cellphone calculator doesn't have brackets (its a dumb phone).
> I saw this on an RISCOS enthusiast website.
>
> Using, head, as many different calculators that you have to hand
> (especially if you have an iPhone or Windows calc) what result do you get
> from the following sum.
>
> 6/2(1+2)
>
> Type it in exactly as above.
>
> My trusty Casio fx5000f let me down, sort of.
>
> Colin
> --
> cdb, on 11/03/2012
>
Any of the calculators I have with any sort of algebraic ordering come up with the result of 9.
The RPN calculators agree with Dwayne with a result of 1.
On Sat, 10 Mar 2012 18:22:31 -0500 (EST), Jamie Lawson wrote:
:: Any of the calculators I have with any sort of algebraic ordering
:: come up with the result of 9.
Yes my phone 'he say' 9, BBC Basic says 9, my Casio states 1, my head stated 1, Windows Cals thinks 2.
All agree though if an explicit * is entered between the 2 and the brackets.
' When I use a word ' said Humpty Dumpty scornfully, ' it means whatever I want it to mean ' (Alice in wonderland, Rev. Charles Dodgson).
I tried it in Realcalc on Android in RPN mode using the same method as
Dwayne and got ZERO as the result, switching to Algebraic mode it gives 9.
Now I have lost faith in my favorite calculator, I get the wrong answer
either way.
> Windows Calc informs me that the answer is 2, which is definitely
> unexpected.
>
> My mobile (Android) gives a different answer to my Casio. The phone gives
> the same answer as an Acorn Archimedes running BBC Basic.
>
> Colin
> --
> cdb, EraseMEcolinspam_OUTTakeThisOuTbtech-online.co.uk on 11/03/2012
>
> Web presence: http://www.btech-online.co.uk
>
> Hosted by: http://www.justhost.com.au
>
>
> This email is to be considered private if addressed to a named individual
> or Personnel Department, and public if addressed to a blog, forum or news
> article.
>
>
>
>
I just tried it again in RPN mode on realcalc and if I leave out the final
ENTER from Dwayne's example I get one.
It makes sense as the 2 is in the X register and pressing enter will push a
copy into the stack.
Just to confirm I dug out my HP16C and tried both methods.
Dwayne's gives 0.5 but without the final ENTER it gives 1.
Is there a difference in RPN implementations at play here
> On Sun, 11 Mar 2012 01:41:41 +0200, Chris Roper wrote:
> :: Now I have lost faith in my favorite calculator, I get the wrong
> :: answer either way.
>
> Well I suppose it all depends on whether brackets take precedence over
> operators.
>
> Colin
> --
> cdb, KILLspamcolinKILLspambtech-online.co.uk on 11/03/2012
>
> Web presence: http://www.btech-online.co.uk
>
> Hosted by: http://www.justhost.com.au
>
>
> This email is to be considered private if addressed to a named individual
> or Personnel Department, and public if addressed to a blog, forum or news
> article.
>
>
>
>
>
>
Em 10/3/2012 20:22, Jamie Lawson escreveu: {Quote hidden}
> On Sun, 11 Mar 2012, cdb wrote:
>
>> I saw this on an RISCOS enthusiast website.
>>
>> Using, head, as many different calculators that you have to hand
>> (especially if you have an iPhone or Windows calc) what result do you get
>> from the following sum.
>>
>> 6/2(1+2)
>>
>> Type it in exactly as above.
>>
>> My trusty Casio fx5000f let me down, sort of.
>>
>> Colin
>> --
>> cdb, on 11/03/2012
>>
> Any of the calculators I have with any sort of algebraic ordering come up
> with the result of 9.
>
> The RPN calculators agree with Dwayne with a result of 1.
>
> I have "several" calculators.......
>
> Jamie
Using Windows XP calculator if I click 6 / 2 * ( 1 + 2 ) =, I get 9.
If I enter exactly how the OP wrote (without the * ), then I get 2.
It seems a bug in the parser, that ignores an error (lack of an
operator) and gives a nonsensical result.
BUT if I press = again, I get 0.666666...67, which means that the
calculator thinks its last executed operation was a divide by 3.
>>
>> If so, does'nt this mean the calculator leaves precedence
>> decisions to you?
>>
>
> Yes it does and hence my concern.
> Dwayne was getting the correct answer with:
> 6 [Enter] 2 [Enter] 1 [Enter] 2 [Enter] [plus] [multiply] [divide].
>
> I am getting it with:
> 6 [Enter] 2 [Enter] 1 [Enter] 2 [plus] [multiply] [divide].
>
> So there seams to be a difference in RPN implementation.
....I wasn't specifically thinking about RPN when I typed that.
Does'nt that explain the discrepancies? The notation is imprecise,
thus the differing interpretations by operators <and> the Deus Ex
Machina who programmed the calculator.
The more I think about it, the more "Syntax Error" seems the correct
answer. I've rarely seen recommendations for other than explicit ex-
pressions in pgming manuals - Other than C, of course... :)
> ...I wasn't specifically thinking about RPN when I typed that.
>
> Does'nt that explain the discrepancies? The notation is imprecise,
> thus the differing interpretations by operators <and> the Deus Ex
> Machina who programmed the calculator.
>
> The more I think about it, the more "Syntax Error" seems the correct
> answer. I've rarely seen recommendations for other than explicit ex-
> pressions in pgming manuals - Other than C, of course... :)
>
> Jack
> --
At 04:41 PM 3/10/2012, Chris Roper wrote:
>I tried it in Realcalc on Android in RPN mode using the same method as
>Dwayne and got ZERO as the result, switching to Algebraic mode it gives 9.
>Now I have lost faith in my favorite calculator, I get the wrong answer
>either way.
How many levels of stack does Realcalc allow? You may have run out of stack space.
>Dwayne was getting the correct answer with:
>6 [Enter] 2 [Enter] 1 [Enter] 2 [Enter] [plus] [multiply] [divide].
>
>I am getting it with:
>6 [Enter] 2 [Enter] 1 [Enter] 2 [plus] [multiply] [divide].
I am using eCalc and just now tried both key sequences above.
In eCalc, both of the above sequences result in an answer of 1
However, the second method (without the extra [Enter] is probably more correct and is what I would have used with my old HP-45 if it still worked. That's because the old HP calculators have only 4 levels of stack.
However, in a calculator that has more than 4 levels of stack (like eCalc), both sequences are valid RPN.
> Using, head, as many different calculators that you have to hand
> (especially if you have an iPhone or Windows calc) what result do you get
> from the following sum.
>
> 6/2(1+2)
Note - in the following, unless specified otherwise) I'll assume a
multiplication operator between he 2 and the ( as this is well
understood to be implied and is not part of the central issue.
OK. I'm "on a hiding to nothing here."
I won't even sneak away and see what Wikipedia and other authoritative
[tm] beguiling & incorrect sources say about operator precedence.
I'll just blurt it out :-).
The emperor has no clothes on.
Everybody or almost everybody who has indicated a "correct"* solution
so far is wrong.
The only correct answer is 9.
< flame shields u..... too lat ...
Reverse the order of the two indivisible* portions.
A = (1 + 2) * 6 / 2
Few would get other than "9" as an answer.
This is entirely consistent with the basic rule of mathematics that B
* C = C * B
You can even extend that to Z = A * B / C = B * A / C = A / C * B = B / C * A
As long as you agree with the implicit / C means / C = 1 / C
you can as validly write Z = A * B / C = / C * A * B = / C * B * A
The above should be convincing enough to allow people to go back and
assess what is wrong with what most people have been assuming about
the original methods of solution that lead to an incorrect answer.
This is, that he "scope" of the / operator is only a single number or
bracketed expression - an implied preceding brackets is not presumed
when an operator of equal precedence is encountered.
The RPN solution is wrong because the method used to evaluate it
removes information from the RPN process.
Consider - in very complex expressions withe limited stack size is
available an RPN evaluation should commence inside the most deeply
nested bracket and work out. If that is correct for a complex
expression it shold prodice a correct result for a simple one.
So 1 ^ 2+6^2/* = 9
or 1 ^ 2+6*2/ = 9
The calculator that gave a zero result with the original expression is
more correct than those which gave answers other than 9.
Consider - how should 6/2z(1+2) evaluate. The "z" is clearly an
illegal character and should ideally give an error message or, failing
that, zero the result.
So too 2( is an illegal sequence and should either be "corrected" to
the generally understood 2 * ( or declared as an error.
On Sun, 11 Mar 2012 15:45:05 +1300, RussellMc wrote:
:: Reverse the order of the two indivisible* portions.
:: A = (1 + 2) * 6 / 2
Yes, but,ignoring RPN for a moment, surely the 'convention' is that a bracketed sum is performed first and then depending on the incarnation (of compiler) the next sequence would be to read the remaining operators with the same precedence in left to right order.
In which case as my trusty Casio states, the answer is 1, only if the division is performed first does the result come to 9 as per other algorithms.
part 1 1386 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)
Dwayne Reid <EraseMEdwaynerplanet.eon.net> writes:
> Regardless, I fall upon the old mnemonic phrase for order of math > operations that my Maths teacher gave to me way back in grade school: > BOMDAS = Brackets, then Odd_Functions, then Multiply, then Divide, > then Add, then Subtract.
This is amusing to read. In the UK, at least, school students are taught
"BODMAS" (where "O" stands for "Other", if I recall correctly). Of
course, since division is just multiplication combined with a (tighter
binding) reciprocal, it shouldn't matter.
The problem is that it's hard to know how to make sense of
1/2/3
(as a pair of quotients, rather than a date, which has its own
problems!)
This doesn't come from problems of operator precedence, but rather from
the fact that "/" isn't associative. Fortunately, people make things
much more obvious when scribbling on paper.
I should say, my immediate interpretation of the above is (1/2)/3, but
I've spent a significant fraction of my life able to program in C, so I
suspect that C/Algol/whatever's heritage has more influence on me than
anything mathematical.
Similar problems arise with 1 - 2 - 3, of course. But (since subtraction
is always written in one dimension?), the (1-2)-3 interpretation seems
pretty much universal.
Rupert
part 2 181 bytes content-type:text/plain; name="ATT00001.txt" (decoded base64)
-- http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
The problem is that it's hard to know how to make sense of
>
> 1/2/3
>
> (as a pair of quotients, rather than a date, which has its own
> problems!)
>
> This doesn't come from problems of operator precedence, but rather from
> the fact that "/" isn't associative. Fortunately, people make things
> much more obvious when scribbling on paper.
>
> I should say, my immediate interpretation of the above is (1/2)/3, but
> I've spent a significant fraction of my life able to program in C, so I
> suspect that C/Algol/whatever's heritage has more influence on me than
> anything mathematical.
I would have interpreted it as 1/(2/3) or the reciprocal of 2/3 but that is
probably from my electronics background at collage where 1/(function) is
common
> Dwayne Reid <RemoveMEdwaynerspam_OUTKILLspamplanet.eon.net> writes:
>> Regardless, I fall upon the old mnemonic phrase for order of math
>> operations that my Maths teacher gave to me way back in grade school:
>> BOMDAS = Brackets, then Odd_Functions, then Multiply, then Divide,
>> then Add, then Subtract.
>
> This is amusing to read. In the UK, at least, school students are taught
> "BODMAS" (where "O" stands for "Other", if I recall correctly). Of
> course, since division is just multiplication combined with a (tighter
> binding) reciprocal, it shouldn't matter.
>
> The problem is that it's hard to know how to make sense of
>
> 1/2/3
>
> (as a pair of quotients, rather than a date, which has its own
> problems!)
>
> This doesn't come from problems of operator precedence, but rather from
> the fact that "/" isn't associative. Fortunately, people make things
> much more obvious when scribbling on paper.
>
> I should say, my immediate interpretation of the above is (1/2)/3, but
> I've spent a significant fraction of my life able to program in C, so I
> suspect that C/Algol/whatever's heritage has more influence on me than
> anything mathematical.
>
> Similar problems arise with 1 - 2 - 3, of course. But (since subtraction
> is always written in one dimension?), the (1-2)-3 interpretation seems
> pretty much universal.
>
>
> Rupert
>
> In elementary school (US) I was taught: PEMDAS = Please Excuse My Dear
> Aunt Sally
>
> or
>
> Parentheses
> Exponents
> Multiplication
> Division
> Addition
> Subtraction
>
> Although, I think this is misleading at best. For example, it suggests
> that addition should precede subtraction, as in:
>
> 3-2+4 would be 3-(2+4) rather than (3-2)+4. As others have pointed
> out, this has to do with association and not order of operations.
>
> Sean
I was taught the same, however my math teacher pointed out that
addition and subtraction have the same priority.
-- Martin K
> On Sun, 11 Mar 2012 15:45:05 +1300, RussellMc wrote:
> :: Reverse the order of the two indivisible* portions.
> :: A = (1 + 2) * 6 / 2
>
> Yes, but,ignoring RPN for a moment, surely the 'convention' is that a
> bracketed sum is performed first and then depending on the incarnation (of
> compiler) the next sequence would be to read the remaining operators with
> the same precedence in left to right order.
>
> In which case as my trusty Casio states, the answer is 1, only if the
> division is performed first does the result come to 9 as per other
> algorithms.
>
> Colin
> --
> cdb, EraseMEcolinspamspamBeGonebtech-online.co.uk on 11/03/2012
>
> Web presence: http://www.btech-online.co.uk
>
> Hosted by: http://www.justhost.com.au
>
>
> This email is to be considered private if addressed to a named individual
> or Personnel Department, and public if addressed to a blog, forum or news
> article.
>
>
>
>
>
>
-- John Ferrell W8CCW
Few things are harder to put up with than the annoyance of a good example.
Mark Twain (1835 - 1910), Pudd'nhead Wilson (1894)
I hate how GCC "suggests" adding parenthesis around mixed operators with
"ambiguous" precedence, and also for ambiguous if/else.
It turns out that there's nothing ambiguous in the operator precedence
or if/else in C.
For instance:
if( a )
if( b )
...
else
...
It's obvious that the "else" belongs to the second "if", but GCC issues
a warning. Annoying.
And:
if( expr1 && expr2 || expr3 && expr4 )
...
Also gives a warning.
Perhaps the compiler developers fear they may have made some mistake and
ask the programmers to add parenthesis to avoid exposing a bug in the
compiler?
Isaac
Em 11/3/2012 21:54, John Ferrell escreveu: {Quote hidden}
> Whenever I use a calculator (or a compiler) I sprinkle brackets
> everywhere. It usually annoys someone but it saves me in the long run.
>
> On 3/10/2012 10:42 PM, cdb wrote:
>> On Sun, 11 Mar 2012 15:45:05 +1300, RussellMc wrote:
>> :: Reverse the order of the two indivisible* portions.
>> :: A = (1 + 2) * 6 / 2
>>
>> Yes, but,ignoring RPN for a moment, surely the 'convention' is that a
>> bracketed sum is performed first and then depending on the incarnation (of
>> compiler) the next sequence would be to read the remaining operators with
>> the same precedence in left to right order.
>>
>> In which case as my trusty Casio states, the answer is 1, only if the
>> division is performed first does the result come to 9 as per other
>> algorithms.
>>
>> Colin
>> --
>> cdb, RemoveMEcolinKILLspambtech-online.co.uk on 11/03/2012
>>
>> Web presence: http://www.btech-online.co.uk
>>
>> Hosted by: http://www.justhost.com.au
>>
>>
>> This email is to be considered private if addressed to a named individual
>> or Personnel Department, and public if addressed to a blog, forum or news
>> article.
>>
>>
>>
>>
>>
> I hate how GCC "suggests" adding parenthesis around mixed operators with
> "ambiguous" precedence, and also for ambiguous if/else.
> It turns out that there's nothing ambiguous in the operator precedence
> or if/else in C.
>
> For instance:
>
> if( a )
> if( b )
> ...
> else
> ...
>
> It's obvious that the "else" belongs to the second "if", but GCC issues
> a warning. Annoying.
>
> And:
>
> if( expr1 && expr2 || expr3 && expr4 )
> ...
>
> Also gives a warning.
>
>
> Perhaps the compiler developers fear they may have made some mistake and
> ask the programmers to add parenthesis to avoid exposing a bug in the
> compiler?
>
>
> Isaac
>
Isn't that just what warnings are for? It compiles OK but it might not be what you wanted. Just like:
if (A=B){
...
I have learned that the clearer code I write the more easy it is to maintain in the long run. It might take you a week to write the initial code but it might need to be maintained for another 10 years (updates, changes - not bugfixing). And the one maintaining it might not be the one who wrote it in the first place.
I generally sprinkle paranthesis and curly braces all over the code to make it very clear what I wanted (besides I never remember precedence anyway so I try not to rely on it). I also try not to use too elaborate one-line C-code. Instead I split the code in several steps and let the compiler optimize it for me. Besides it is also often more easy to debug.
If I was handed code like the above, I would have to go through the rest of the code in more detail to be sure that it is what is written that is actually what is intended. Especially if it is some sort of error handling that normally is never executed and might never have been tested. All this can take a lot of time. Of course you can comment the code but I have seen a lot of code (my own included) that has an original set of comments and then something in the code was changed but the comments have never been updated, which is almost worse than no comments at all.
Bottom line is that the clearer and simpler the code is the easier it is to come back to it sometime in the future, which almost always happens.
/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388 rubenSTOPspamspam_OUTpp.sbbs.se
==============================
Let me try that again , as all except one seem to have not commented,
and he but laterally (as is acceptable), as is his wont ... :-)
All answers that are not "9" are wrong !!!
People are welcome to disagree, but please address both the
commutative requirement below and slightly more general points raised
in my prior email.
See my prior post for the detailed reasons why.
Short version:
Reverse the order of the two indivisible* portions and compare with original.
Does anyone DISAGREE that the answer *SHOULD* be the same when we do as follows:
If anyone does disagree, please explain why.
Original = Transposed version
A = 6 / 2 * (1 + 2) A = (1 + 2) * 6 / 2
Does any one NOT get "9" for the second version.?
Can you see WHY the first version does not = "9" if it doesn't.
It's because the scope of the "/" operator does not extend beyond the
following number (here = 2) whereas all solutions that obtain "1" as
an answer do not meet this requirement.
> I've just tried it in Python 3.1 - has to have the explicit multiplication
> inserted otherwise it sulks, it confidently tells me the answer is 9.
It's good to know that Python 3.1 is correct in its figurings, unlike
most other systems, it seems.
This is all rather disturbing.
While use of brackets would explicitly steer the system to the correct
expression, this should not be required in this age of algorithmically
biased calculators. At least RPN allows you to make your own
mistakes.
> Can you see WHY the first version does not = "9" if it doesn't.
> It's because the scope of the "/" operator does not extend beyond the
> following number (here = 2) whereas all solutions that obtain "1" as
> an answer do not meet this requirement.
>
The OP was about not to type the multiplication sign it
6 / 2 ( 1 + 2 )
This should be 'syntax error' as someone suggested, but instead in many
calculator the '2' before the bracket is ignored it seems (at least on the
iPhone). Therefore 6 / (1 + 2 ) interpreted only giving a result of 2. If
you type the '*' in between the '2' and the bracket then of course you get
'9' on iPhone.
I agree with your colleague.
I use several compilers and several "C Type" languages, not all of them
will give a warning but all will generate the error.
> I have a colleague who insists on using this reverse syntax
>
> if(0 == x) {
> ...do stuff
> }
>
> which I find odd to read at the best of times...
>
> We're using embedded C, (Hitech), and whilst
> if(x =0) doesn't throw an error, it does throw a warning.
>
> oh well.
>
> -Jim
>
>
> >
> >
> >
> > Isn't that just what warnings are for? It compiles OK but it might not be
> > what you wanted. Just like:
> >
> > if (A=B){
> > ...
> >
>
>
>
>
> I agree with your colleague.
> I use several compilers and several "C Type" languages, not all of them
> will give a warning but all will generate the error.
>
>
> On 12 March 2012 10:03, Jim <@spam@jimf@spam@spam_OUTwebstudios.co.uk> wrote:
>
> > I have a colleague who insists on using this reverse syntax
> >
> > if(0 == x) {
> > ...do stuff
> > }
> >
> > which I find odd to read at the best of times...
> >
> > We're using embedded C, (Hitech), and whilst
> > if(x =0) doesn't throw an error, it does throw a warning.
> >
> > oh well.
> >
> > -Jim
> >
> >
> > >
> > >
> > >
> > > Isn't that just what warnings are for? It compiles OK but it might not
> be
> > > what you wanted. Just like:
> > >
> > > if (A=B){
> > > ...
> > >
> >
> >
> >
> >
> The OP was about not to type the multiplication sign it
>
> 6 / 2 ( 1 + 2 )
I agree that was a significant part of the original problem, but I am
largely concerned with the evaluation of
6 / 2 *( 1 + 2 )
which the very large majority of posters so far seem to suggest = "1"
, both when using various languages and calculators.
And opinion seems generally to have been that = "9" is an error.
Which it isn't.
>If you type the '*' in between the '2' and the bracket then of course you get
> '9' on iPhone.
I'm glad you say "of course" and I'm intrigued that the iPhone gets it
right when so many other systems seem to get it wrong.
So far nobody seems to want to either support or resile from the = "1"
answer as correct, after I said it wasn't.
Which seems strange
if(iBlock_Size = 0)
{
return 0;
}
gives this:- Warning [758] C:\Source\UI_Test\dongle.c; 107. constant conditional branch: possible use of "=" instead of "=="
BUT still builds ok..
obviously the syntax should be
if(iBlock_Size == 0)
{
return 0;
}
but my colleague uses if(0 == iBlock_Size)
{
return 0;
}
Which although syntactically correct, just doesn't feel right.
He uses it for ALL ifs so if(127 < iBlock_Size)
{
return 0;
}
Which is counter intuitive in my mind. Perhaps I am just getting old?
They should ALL produce an error with if(0 = iBlock_Size)
{
return 0;
}
as you cannot assign to the 0 on the left side
Error [202] C:\Source\UI_Test\dongle.c; 107.19 only lvalues may be assigned to or modified
> On 12 March 2012 09:20, Chris Roper caroper@gma
> il.com> wrote:
> > I agree with your colleague.
> > I use several compilers and several "C Type"
> languages, not all of them> will give a warning but all will generate the
> error.>
>
> You mean if you write:
>
> if ( 0 = x ) ...
>
> then not all C compiler will generate an error?
>
> Tamas
>
>
>
>
> >
> > On 12 March 2012 10:03, Jim jimf@we
> bstudios.co.uk> wrote:>
> > > I have a colleague who insists on using this
> reverse syntax> >
> > > if(0 == x) {
> > > ...do stuff
> > > }
> > >
> > > which I find odd to read at the best of
> times...> >
> > > We're using embedded C, (Hitech), and
> whilst> > if(x =0) doesn't throw an error, it does throw
> a warning.> >
> > > oh well.
> > >
> > > -Jim
> > >
> > >
> > > >
> > > >
> > > >
> > > > Isn't that just what warnings are for? It
> compiles OK but it might not> be
> > > > what you wanted. Just like:
> > > >
> > > > if (A=B){
> > > > ...
> > > >
> > >
> > >
> > >
> > >
> > > --
Perhaps your colleague uses this reversed order specifically BECAUSE
it inherently prevents the single equals sign mistake. It converts it
from a warning to an error.
> Using this example:-
>
> if(iBlock_Size = 0)
> {
> return 0;
> }
> gives this:-
> Warning [758] C:\Source\UI_Test\dongle.c; 107. constant conditional branch: possible use of "=" instead of "=="
>
> BUT still builds ok..
>
> obviously the syntax should be
>
> if(iBlock_Size == 0)
> {
> return 0;
> }
>
> but my colleague uses
> if(0 == iBlock_Size)
> {
> return 0;
> }
>
> Which although syntactically correct, just doesn't feel right.
> He uses it for ALL ifs so
> if(127 < iBlock_Size)
> {
> return 0;
> }
>
> Which is counter intuitive in my mind. Perhaps I am just getting old?
>
> They should ALL produce an error with
> if(0 = iBlock_Size)
> {
> return 0;
> }
> as you cannot assign to the 0 on the left side
> Error [202] C:\Source\UI_Test\dongle.c; 107.19 only lvalues may be assigned to or modified
>
>
>
>
> On Mon 12/03/12 10:18 AM , Tamas Rudnai TakeThisOuTtamas.rudnai.....TakeThisOuTgmail.com sent:
>> On 12 March 2012 09:20, Chris Roper caroper@gma
>> il.com> wrote:
>> > I agree with your colleague.
>> > I use several compilers and several "C Type"
>> languages, not all of them> will give a warning but all will generate the
>> error.>
>>
>> You mean if you write:
>>
>> if ( 0 = x ) ...
>>
>> then not all C compiler will generate an error?
>>
>> Tamas
>>
>>
>>
>>
>> >
>> > On 12 March 2012 10:03, Jim jimf@we
>> bstudios.co.uk> wrote:>
>> > > I have a colleague who insists on using this
>> reverse syntax> >
>> > > if(0 == x) {
>> > > ...do stuff
>> > > }
>> > >
>> > > which I find odd to read at the best of
>> times...> >
>> > > We're using embedded C, (Hitech), and
>> whilst> > if(x =0) doesn't throw an error, it does throw
>> a warning.> >
>> > > oh well.
>> > >
>> > > -Jim
>> > >
>> > >
>> > > >
>> > > >
>> > > >
>> > > > Isn't that just what warnings are for? It
>> compiles OK but it might not> be
>> > > > what you wanted. Just like:
>> > > >
>> > > > if (A=B){
>> > > > ...
>> > > >
>> > >
>> > >
>> > >
>> > >
>> > > --
> So far nobody seems to want to either support or resile from the = "1"
> answer as correct, after I said it wasn't.
> Which seems strange
>
I am still having a trouble to remember what I have learned in school (as
opposed to what I am applying nowadays), but all my braincells tells me
that division and multiplication has the very same priority and should be
handled from left to right.
Therefore 6 / 2 * (1 + 2 ) should be
6
-- * (1+2) = 9
2
and not:
6
--------- = 1
2 * (1+2)
But I might be wrong. In most programming languages this is the case at
least.
NO, I said ALL would generate an error but not all would generate a warning..
I also said "C Type", referring to scripting languages as well as compilers..
> On 12 March 2012 09:20, Chris Roper <RemoveMEcaroperspamBeGonegmail.com> wrote:
>
> > I agree with your colleague.
> > I use several compilers and several "C Type" languages, not all of them
> > will give a warning but all will generate the error.
> >
>
> You mean if you write:
>
> if ( 0 = x ) ...
>
> then not all C compiler will generate an error?
>
> Tamas
>
>
>
>
> >
> > On 12 March 2012 10:03, Jim <spamBeGonejimf@spam@spam_OUTwebstudios.co.uk> wrote:
> >
> > > I have a colleague who insists on using this reverse syntax
> > >
> > > if(0 == x) {
> > > ...do stuff
> > > }
> > >
> > > which I find odd to read at the best of times...
> > >
> > > We're using embedded C, (Hitech), and whilst
> > > if(x =0) doesn't throw an error, it does throw a warning.
> > >
> > > oh well.
> > >
> > > -Jim
> > >
> > >
> > > >
> > > >
> > > >
> > > > Isn't that just what warnings are for? It compiles OK but it might
> not
> > be
> > > > what you wanted. Just like:
> > > >
> > > > if (A=B){
> > > > ...
> > > >
> > >
> > >
> > >
> > >
> > > --
Em 12/3/2012 06:15, Tamas Rudnai escreveu:
> On 12 March 2012 07:50, RussellMc <TakeThisOuTapptechnzspamgmail.com> wrote:
>
>> Can you see WHY the first version does not = "9" if it doesn't.
>> It's because the scope of the "/" operator does not extend beyond the
>> following number (here = 2) whereas all solutions that obtain "1" as
>> an answer do not meet this requirement.
>>
> The OP was about not to type the multiplication sign it
>
> 6 / 2 ( 1 + 2 )
>
> This should be 'syntax error' as someone suggested, but instead in many
> calculator the '2' before the bracket is ignored it seems (at least on the
> iPhone). Therefore 6 / (1 + 2 ) interpreted only giving a result of 2. If
> you type the '*' in between the '2' and the bracket then of course you get
> '9' on iPhone.
>
> Tamas
As I commented before, if I press = again after receiving the wrong
answer (1) in Windows Calc, to repeat the last operation, the result is
0.6666...67.
That means that the calculator thinks the last operation it executed was
a divide by 3.
I have a theory that the input of "(1+2)" without an operator replaces
the working register (or whatever the programmer calls it) without
replacing or invalidating the active operator. When someone presses
=,the calculator simply does the operation it thinks that is outstanding.
Let's say the calculator has three internal variables X, Y and Op. Y
holds the value of previous calculations, X holds the value just entered
and Op holds the operation.
When = is pressed, it simply does the calculation and replaces the Y
register with the result. You can press = how many times you like and
the same last operation and value of X are uses again.
Perhaps when the "(1+2)" is input, the calculator replaces X with its
result, leaving Op untouched.
> Reverse the order of the two indivisible* portions and compare with original.
> Does anyone DISAGREE that the answer *SHOULD* be the same when we do as follows:
> If anyone does disagree, please explain why.
> Original = Transposed version
> A = 6 / 2 * (1 + 2) A = (1 + 2) * 6 / 2
This interchange is only correct if the intention of the original equation is A = (6/2)*(1+2).
If the intention of the original equation is A = 6/(2 * (1 + 2)) then Russells interchange does not work, and this could well be the intention of the original equation, as someone else noted a hand written version would have made this a lot clearer.
-- Scanned by iCritical.
> I have a colleague who insists on using this reverse syntax
>
> if(0 == x) {
> ...do stuff
> }
>
> which I find odd to read at the best of times...
>
> We're using embedded C, (Hitech), and whilst
> if(x =0) doesn't throw an error, it does throw a warning.
>
> oh well.
The reason for using the
If (0 == x) {...
is to throw an error if one of the = signs is accidently left out giving an assignment instead of an equality.
It may well be that if (x = 0) {...
is meant to be correct code (unlikely) but is more of a problem if the code is supposed to be if (x = b) {...
i.e. you mean to do the assignment, but the if() statement is looking at the value of b to see if the statement should be executed - obfuscated code forever ...
-- Scanned by iCritical.
On Mon, Mar 12, 2012 at 8:05 AM, <alan.b.pearceEraseMEstfc.ac.uk> wrote:
>> Reverse the order of the two indivisible* portions and compare with original.
>> Does anyone DISAGREE that the answer *SHOULD* be the same when we do as follows:
>> If anyone does disagree, please explain why.
>> Original            =        Transposed version
>> A = 6 / 2 * (1 + 2) Â Â Â Â Â Â Â Â Â Â Â Â Â A = (1 + 2) * 6 / 2
>
> This interchange is only correct if the intention of the original equation is A = (6/2)*(1+2).
>
> If the intention of the original equation is A = 6/(2 * (1 + 2)) then Russells interchange does not work, and this could well be the intention of the original equation, as someone else noted a hand written version would have made this a lot clearer.
This seems to be a good example of why GCC complains about parenthesis
being needed where ambiguous operations are present.
It's still a confusing format.
But then, to be fair, we have inherited a large chunk of code 8000 lines+ with hardly any indentation, and lots of "strange" coding techniques. I guess we all have our own idiosyncrasies.
> > I have a colleague who insists on using this
> reverse syntax>
> > if(0 == x) {
> > ...do stuff
> > }
> >
> > which I find odd to read at the best of
> times...>
> > We're using embedded C, (Hitech), and
> whilst> if(x =0) doesn't throw an error, it does throw a
> warning.>
> > oh well.
>
> The reason for using the
>
> If (0 == x) {...
>
> is to throw an error if one of the = signs is accidently left out giving an
> assignment instead of an equality.
> It may well be that
> if (x = 0) {...
> is meant to be correct code (unlikely) but is more of a problem if the code
> is supposed to be if (x = b) {...
>
> i.e. you mean to do the assignment, but the if() statement is looking at
> the value of b to see if the statement should be executed - obfuscated code
> forever ...--
> Scanned by iCritical.
>
>> If anyone does disagree, please explain why.
>> Original = Transposed version
>> A = 6 / 2 * (1 + 2) A = (1 + 2) * 6 / 2
> This interchange is only correct if the intention of the original equation is A = (6/2)*(1+2).
>
> If the intention of the original equation is A = 6/(2 * (1 + 2)) then Russells interchange does not work, and this could well be the intention of the original equation, as someone else noted a hand written version would have made this a lot clearer.
Intentions are of no consequence in determining mathematical truth :-)
I argued that multiplication is commutative - as it is in our
universally accepted mathematical system. .
To "intend" that an equation breaks this rule is to utilise "the new
mathematics".
I think the problem with the original question is that it's not valid! :-)
People seem to forget that a typed equation on a computer isn't the same as a mathematical equation - it's part of a programming language.
A mathematical equation (as written on a blackboard by Charlie Epps) isn't constrained by having to be typed on a keyboard, so the "/" would be a horizontal line with items above and below it, so no ambiguity.
The question as typed was a hybrid (polite term!) of a mathematical equation, where the "multiply" is implied by putting two items adjacent, and a computer programming language, which deals with typed characters and so has rules about how they're handled (PEDMAS then left-to-right).
As such it's not valid to type "2(" as part of a program, including into a calculator, because the syntax of this type of algorithm is built from:
operator operand OR operand operator (operand) and "(" isn't this type of operator in any language I'm familiar with, but resolves its contents into an operand, so 2(1+2) resolves to 2 3 which isn't a valid part of a computer-language equation.
As it was given, Foxpro gives "Syntax error", but with the implied "*" added it gives 9, as it should.
On 12/03/2012 11.41, Tamas Rudnai wrote:
>
> I am still having a trouble to remember what I have learned in school (as
> opposed to what I am applying nowadays), but all my braincells tells me
> that division and multiplication has the very same priority and should be
> handled from left to right.
>
> Therefore 6 / 2 * (1 + 2 ) should be
>
> 6
> -- * (1+2) = 9
> 2
I remember very well what lerned at school and this is the only right interpretation.
And is simple and smart!
When writing by hand it's correct to omit the * because this is in The Rule..
With any programming language we must see The Rule on operator precedence but I think that if it came out with something different it can be wrong (may exists a contest in which...).
I have sent a message to this thread attaching a screenshot of the Linux
Calculator app -- did it gone through? Just asking because I thought it did
but then I got a rejected message from Piclist as the picture was bigger
than 40k.
>
>
> On 12/03/2012 11.41, Tamas Rudnai wrote:
> >
> > I am still having a trouble to remember what I have learned in school (as
> > opposed to what I am applying nowadays), but all my braincells tells me
> > that division and multiplication has the very same priority and should be
> > handled from left to right.
> >
> > Therefore 6 / 2 * (1 + 2 ) should be
> >
> > 6
> > -- * (1+2) = 9
> > 2
> I remember very well what lerned at school and this is the only right
> interpretation.
> And is simple and smart!
> When writing by hand it's correct to omit the * because this is in The
> Rule.
>
> With any programming language we must see The Rule on operator precedence
> but I
> think that if it came out with something different it can be wrong (may
> exists a
> contest in which...).
>
>
>
> I think the problem with the original question is that it's not valid! :-)
Once the "2(" is corrected to the implied "2*(", which nobody (I
think) questions the validity of, the answer should be, and is, "9".
Many systems seem to have trouble with that.
> Once the "2(" is corrected to the implied "2*(", which nobody (I
> think) questions the validity of, the answer should be, and is, "9".
> Many systems seem to have trouble with that.
Nonsense, the answer should be according to the rules of the system at hand! If a system does not adhere to its own rules it is wrong, but when it has strange rules it is just strange.
APL, just to mention a programming language: evaluation is strictly from right to left.
I don't think there is universal agreement on the order of + versus - (+ first, or left to right?) in writing.
> the answer should be according to the rules of the system at
> hand! If a system does not adhere to its own rules it is wrong, but when
> it has strange rules it is just strange.
I am saying that the answer to
6/2 * (1+2)
as written, and based on the "proper" [tm] rules of mathematics = 9.
I am saying that "1" is an incorrect answer.
Do you disagree in either case?
If you do disagree, do you hold that " * " is not commutative?
Or ... ?
> I am saying that the answer to
>
> 6/2 * (1+2)
>
> as written, and based on the "proper" [tm] rules of mathematics = 9.
For a certain value of '"proper" [tm] rules of mathematics' that is certainly true. The trouble is in deciding that rules.
AFAIK in my 'basic' school (6-12y) I was told that multiplication has precedence over division. In high school (12-18y) I recall them having equal precedence, and to evaluate left-to-right. And the wiser of te teachers discouraged writing anything that could be interpreted differently depending on whether multiplication was to have precedence (over division) or not, for instance by using the horizontal bar instead of the /.
>I am saying that the answer to
>
> 6/2 * (1+2)
>
>as written, and based on the "proper" [tm] rules of mathematics = 9.
>I am saying that "1" is an incorrect answer.
>Do you disagree in either case?
Based upon what I remember from being taught in grade school, 1 is the correct answer because, if there are both multiplication and division operations in close proximity to each other, multiplication is done first. BOMDAS (see my earlier post for what the letters stand for.)
Russell, you are trying to influence people's perception by grouping the first 3 characters together. The last 3 characters don't matter because they are enclosed in brackets.
A more generic representation would be:
6 / 2 * (1 + 2) = ?
I'd really like to put the above question to a "proper" maths instructor and get their opinion. Unfortunately, I don't currently know any "proper" maths instructors.
However, referring back to the original question: 6/2(1+2) directly implies that the "2(1+2)" operations must be done first. That is: it does for me.
> -----Original Message-----
> From: @spam@piclist-bouncesspam_OUT.....mit.edu [spamBeGonepiclist-bouncesEraseMEmit.edu] On Behalf
> Of RussellMc
> Sent: 13 March 2012 14:53
> To: Microcontroller discussion list - Public.
> Subject: Re: [OT] Maths fun
>
> > Nonsense,
>
> ?
>
> > the answer should be according to the rules of the system at
> > hand! If a system does not adhere to its own rules it is wrong, but when
> > it has strange rules it is just strange.
>
> I am saying that the answer to
>
> 6/2 * (1+2)
>
> as written, and based on the "proper" [tm] rules of mathematics = 9.
> I am saying that "1" is an incorrect answer.
> Do you disagree in either case?
>
> If you do disagree, do you hold that " * " is not commutative?
> Or ... ?
>
> Is:
>
> 6/2 * (1+2) = = (1+2) * 6/2 ?
>
>
Russell,
Multiplication is commutative, but obviously division is not. If the operations in the equation as originally written are performed in the order taught to children in the UK i.e. "BODMAS" then the division would be performed before the multiplication and the result will be 9. This appears to form the basis of your argument.
However, this thread has already shown that in the US at least, children are taught a different mnemonic (PEDMAS) which puts multiplication ahead of division in the ordering, and which yields a result of 1.
This suggests that you can not guarantee that the order of evaluation that someone will apply will be the same as your own, so parentheses should be used if there is any ambiguity in the expression.
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
> -----Original Message-----
> From: piclist-bouncesspamBeGonemit.edu [RemoveMEpiclist-bounces@spam@spamBeGonemit.edu] On Behalf
> Of RussellMc
> Sent: 13 March 2012 14:53
> To: Microcontroller discussion list - Public.
> Subject: Re: [OT] Maths fun
>
> > Nonsense,
>
> ?
>
> > the answer should be according to the rules of the system at
> > hand! If a system does not adhere to its own rules it is wrong, but when
> > it has strange rules it is just strange.
>
> I am saying that the answer to
>
> 6/2 * (1+2)
>
> as written, and based on the "proper" [tm] rules of mathematics = 9.
> I am saying that "1" is an incorrect answer.
> Do you disagree in either case?
>
> If you do disagree, do you hold that " * " is not commutative?
> Or ... ?
>
> Is:
>
> 6/2 * (1+2) = = (1+2) * 6/2 ?
>
>
Russell,
Multiplication is commutative, but obviously division is not. If the operations in the equation as originally written are performed in the order taught to children in the UK i.e. "BODMAS" then the division would be performed before the multiplication and the result will be 9. This appears to form the basis of your argument.
However, this thread has already shown that in the US at least, children are taught a different mnemonic (PEDMAS) which puts multiplication ahead of division in the ordering, and which yields a result of 1.
This suggests that you can not guarantee that the order of evaluation that someone will apply will be the same as your own, so parentheses should be used if there is any ambiguity in the expression.
Mike
I sent that a little prematurely - the mnemonic that puts multiplication first is "PEMDAS".
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
> AFAIK in my 'basic' school (6-12y) I was told that multiplication has
> precedence over division. In high school (12-18y) I recall them having
> equal precedence, and to evaluate left-to-right. And the wiser of te
> teachers discouraged writing anything that could be interpreted
> differently depending on whether multiplication was to have precedence
> (over division) or not, for instance by using the horizontal bar instead
> of the /.
>
Now I have an impression that when you write
6/2(1+2) without the '*'
then this way the multiplication is treated as a higher priority than the
division, otherwise equal to it? Or is this absurd?
> For a certain value of '"proper" [tm] rules of mathematics' that is
> certainly true. The trouble is in deciding that rules.
Quite apart from precedence rules, one of the "rules" which is
"universal" ([tm] again) is that multiplication is commutative.
ie A x B = B x A
So far nobody seems to have addressed why this does not apply in the
given example if the answer is to equal "1".
> This suggests that you can not guarantee that the order of evaluation that someone will apply will be the same as your own, so parentheses should be used if there is any ambiguity in the expression.
A very safe suggestion.
I'm beginning to be just slightly stirred towards the point of view
that there is no safe logic here, as oppossed to my prior view that
there is only one fndamentally correct answer. But just slightly :-).
The point that influences me is that one COULD claim that in
6/2 * (1+2)
You may evaluate
2 * (1+2)
or
(1+2) * 2
and use the result as the divisor in 6/6.
Thereby retaining the commutative nature of multiplication.
This does not make me happy with the suggestion that the / effectovely
is preceded by an implied bracket, but I better see the point.
Any proper [tm] mathematics teachers here?
(Please provide notarised certification of credentials when applying).
On 13/03/2012 15.26, RussellMc wrote:
>> For a certain value of '"proper" [tm] rules of mathematics' that is
>> certainly true. The trouble is in deciding that rules.
> Quite apart from precedence rules, one of the "rules" which is
> "universal" ([tm] again) is that multiplication is commutative.
No! This is not a rule but a property that desced from definition (on reals)!
A rule can be arbitrary but a property (in mathematics) no!
> ie A x B = B x A
> So far nobody seems to have addressed why this does not apply in the
> given example if the answer is to equal "1".
>
>
> Russell
I lost the original post (subscribed to OT only two days ago) so i can miss some point.
I think that there is a problem of context (every context has his rules): some context lacks of rules to forbid to write ambiguous formulas.
For example: at school I never see the use of "/" inline, the line of fraction must be used.
When I write software am used to use parenthesis to guarantee that both I and Him (tm) dont see ambiguities.
So I never would write an expression like this.
Nicola
> Quite apart from precedence rules, one of the "rules" which is
> "universal" ([tm] again) is that multiplication is commutative.
> ie A x B = B x A
That is true for all values of a and B, but not necessarily for all textual fragments that you can substitute for A and B, especially when * and / are interpreted as equal precedence (or / higher than *).
On Sat, Mar 10, 2012 at 5:02 PM, cdb <.....colinRemoveMEbtech-online.co.uk> wrote:
> I saw this on an RISCOS enthusiast website.
>
> Using, head, as many different calculators that you have to hand
> (especially if you have an iPhone or Windows calc) what result do you get
> from the following sum.
>
> 6/2(1+2)
>
> Type it in exactly as above.
>
> My trusty Casio fx5000f let me down, sort of.
>
Just for fun, I ran it through my own (javascript) implementation of
the shunting yard algorithm. Mine doesn't support implicit
multiplication so I had to use:
On Tue, 13 Mar 2012 09:22:29 -0600, Dwayne Reid wrote:
:: I'd really like to put the above question to a "proper" maths
:: instructor and get their opinion.
As I mentioned in my OP I found this ' conundrum ' on a RISCOS website. It was posed by a UK maths teacher, he was surprise that his pupils iPhones came up with the answer of 2, and pointed out that the correct answer is 9.
I'll have to hunt around for the website again, but it was an RISC ARM enthusiast website in th eUK.
Nice to know what the expected answer is but is I still think it should be
1.
I read it as 6 / ( 2 * (2 + 1) )
It has been a great discussion though
and certainly hi-lighted the differences in basic math education around the
world as well as differences in calculator implementations.
> Any proper [tm] mathematics teachers here?
> (Please provide notarised certification of credentials when applying).
Depends what you mean by proper :) I teach privately, often to those with special needs and have got them all to graduate grade 12 that have previously failed. I usually see them when they are out of high school and trying again but that's a different story.
My take on this to them would be along these lines...
Calculators only do what you tell them and in most cases they will complete the previous operation when a new operator is started, so in this case, typing 6 / 2 ( 1 + 2 ) could have several different results and that they would have to be more explicit. Some calculators accept the ( to include an implicit * and some don't. The school standard here, a sharp, does not and returns a result of 3 since it discards the 6 / 2 previously entered since there was no operator. My iPhone calculator does this also. My two ageing casios (30 years old) assume that ( means *( and give me 9. As others have mentioned, some calculators need this to be interpreted and some did exactly that.
As written, there is enough ambiguity that I would tell a student to mark their paper to show this is the case and state their assumption - 6/2 *(1+2).. Doing this will avoid them loosing a mark if they should get it wrong.
As it stands, the / 2 is bound to the 6. There is no bracketing to indicate that this is not the case and thus the /2 should stay with the 6. However, students are taught to calculate the contents of brackets first working from the inner most out, so in this case they would rewrite to 6/2 x (3). They would then write 3 x (3) and then 9. My students get use to writing out the stages since it makes the difference to them in following what is going on although the level changes as they advance. If they get stuck, they have a tool they can use to work it out - expand the stages.
However, too many that write this sort of thing do get sloppy when they really mean 6/(2*(1+2))
> Here we are - the website that originally started all this off 9(or those
> looking for a proper maths teacher :) ).
>
> http://www.pilearn.com/
>
> Warning, people who enter, might be gone some time.
>
> Colin
> --
> cdb, spamBeGonecolinKILLspam@spam@btech-online.co.uk on 14/03/2012
>
> Web presence: http://www.btech-online.co.uk
>
> Hosted by: http://www.justhost.com.au
>
>
> This email is to be considered private if addressed to a named individual
> or Personnel Department, and public if addressed to a blog, forum or news
> article.
>
>
>
>
planet.eon.net>
