

It appears that at least three major spreadsheets, Excel, Apache OpenOffice Cal and gnumeric have a problem with the correct order of operations when dealing with exponents. The gnumeric result is very strange.
This problem has probably been reported before but just in case it has not, it would appear to be one more serious problem with spreadsheets. It might be useful in warning people away from using a spreadsheet for serious analysis.
Excel
2^2 = 4
2^2^3 = 64
Apache OpenOffice
2^2 = 4
2^2^3 = 64
gnumeric # note one correct, one error!
2^2 = 4
2^2^3 = 256
John Kane
Kingston ON Canada
____________________________________________________________
FREE 3D EARTH SCREENSAVER  Watch the Earth right on your desktop!
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


On Fri, Sep 18, 2015 at 8:39 AM, John Kane < [hidden email]> wrote:
> It appears that at least three major spreadsheets, Excel, Apache
> OpenOffice Cal and gnumeric have a problem with the correct order of
> operations when dealing with exponents. The gnumeric result is very strange.
>
> This problem has probably been reported before but just in case it has
> not, it would appear to be one more serious problem with spreadsheets. It
> might be useful in warning people away from using a spreadsheet for serious
> analysis.
>
> Excel
>
> 2^2 = 4
>
> 2^2^3 = 64
>
> Apache OpenOffice
>
> 2^2 = 4
>
> 2^2^3 = 64
>
My opinion: One correct, one error! R agrees with me on this:
> 2^2
[1] 4
> 2^2^3
[1] 256
> 2^(2^3)
[1] 256
> 2^2
[1] 4
> (2)^2
[1] 4
>
>
> gnumeric # note one correct, one error!
>
My opinion: two correct!
>
> 2^2 = 4
>
> 2^2^3 = 256
>
> John Kane
> Kingston ON Canada
>
>
Seems to be a bit offtopic. Unless your point to is to use R for
important work instead of some spreadsheet. A point with which I completely
agree!
MSExcel, and Apache OpenOffice, appear to implement the above as
(2^2)^3==64. Whereas gnumeric implements appears to implement this as:
2^(2^3)==256. Which is "correct"? Depends on whom you ask.
ref: https://en.wikipedia.org/wiki/Order_of_operations<quote>
If exponentiation is indicated by stacked symbols, the usual rule is to
work from the top down, thus:
[image: a^{b^c} = a^{(b^c)}],
which typically is not equal to [image: (a^b)^c]. However, some computer
systems may resolve the ambiguous expression differently. For example,
Microsoft
Office Excel < https://en.wikipedia.org/wiki/Microsoft_Office_Excel>
evaluates *a*^*b*^*c* as (*a*^*b*)^*c*, which is opposite of normally
accepted convention of topdown order of execution for exponentiation. If
a=4, p=3, and q=2, [image: a^{p^q}] is evaluated to 4096 in Microsoft Excel
2013, the same as [image: (a^p)^q]. The expression [image: a^{(p^q)}], on
the other hand, results in 262144 using the same program.
</quote>
Gnumeric abides by the above definition. FWIW. BTW  MSExcel also has
1900 as a friggin' leap year (due to Lotus 123 apparently), so I don't
consider MSExcel (or anything else from MS for that matter) to be a
definitive source of correctness. Personal opinion. FSF associate member.
Penguinista.

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.
Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha! <><
John McKown
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


Unfortunately the order of operations is not universal in computing. The real question is whether a program performs the way it is documented. Excel documents that unary operations take precedence over exponentiation and that within groups, the order is left to right. LibreOffice Calc behaves as Excel, but does not document the order of operations except to say */ before +, left to right. I couldn't find any statement about the order of operations in the documentation for Gnumeric.
R documents that unary operations come after exponentiation and, within exponentiation, the order is right to left. Fortran puts unary operations with addition and subtraction after exponentiation with exponentiation right to left. C does not have an exponentiation operator, but unary operations come before multiplication and division.
When in doubt, use parentheses to make sure you get what you want.

David L Carlson
Department of Anthropology
Texas A&M University
College Station, TX 778404352
Original Message
From: Rhelp [mailto: [hidden email]] On Behalf Of John McKown
Sent: Friday, September 18, 2015 9:31 AM
To: John Kane
Cc: rhelp
Subject: Re: [R] Spreadsheet math problem (exponentiation)
On Fri, Sep 18, 2015 at 8:39 AM, John Kane < [hidden email]> wrote:
> It appears that at least three major spreadsheets, Excel, Apache
> OpenOffice Cal and gnumeric have a problem with the correct order of
> operations when dealing with exponents. The gnumeric result is very strange.
>
> This problem has probably been reported before but just in case it has
> not, it would appear to be one more serious problem with spreadsheets. It
> might be useful in warning people away from using a spreadsheet for serious
> analysis.
>
> Excel
>
> 2^2 = 4
>
> 2^2^3 = 64
>
> Apache OpenOffice
>
> 2^2 = 4
>
> 2^2^3 = 64
>
My opinion: One correct, one error! R agrees with me on this:
> 2^2
[1] 4
> 2^2^3
[1] 256
> 2^(2^3)
[1] 256
> 2^2
[1] 4
> (2)^2
[1] 4
>
>
> gnumeric # note one correct, one error!
>
My opinion: two correct!
>
> 2^2 = 4
>
> 2^2^3 = 256
>
> John Kane
> Kingston ON Canada
>
>
Seems to be a bit offtopic. Unless your point to is to use R for
important work instead of some spreadsheet. A point with which I completely
agree!
MSExcel, and Apache OpenOffice, appear to implement the above as
(2^2)^3==64. Whereas gnumeric implements appears to implement this as:
2^(2^3)==256. Which is "correct"? Depends on whom you ask.
ref: https://en.wikipedia.org/wiki/Order_of_operations<quote>
If exponentiation is indicated by stacked symbols, the usual rule is to
work from the top down, thus:
[image: a^{b^c} = a^{(b^c)}],
which typically is not equal to [image: (a^b)^c]. However, some computer
systems may resolve the ambiguous expression differently. For example,
Microsoft
Office Excel < https://en.wikipedia.org/wiki/Microsoft_Office_Excel>
evaluates *a*^*b*^*c* as (*a*^*b*)^*c*, which is opposite of normally
accepted convention of topdown order of execution for exponentiation. If
a=4, p=3, and q=2, [image: a^{p^q}] is evaluated to 4096 in Microsoft Excel
2013, the same as [image: (a^p)^q]. The expression [image: a^{(p^q)}], on
the other hand, results in 262144 using the same program.
</quote>
Gnumeric abides by the above definition. FWIW. BTW  MSExcel also has
1900 as a friggin' leap year (due to Lotus 123 apparently), so I don't
consider MSExcel (or anything else from MS for that matter) to be a
definitive source of correctness. Personal opinion. FSF associate member.
Penguinista.

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.
Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha! <><
John McKown
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


> On 18 Sep 2015, at 16:31, John McKown < [hidden email]> wrote:
>
> On Fri, Sep 18, 2015 at 8:39 AM, John Kane < [hidden email]> wrote:
>
>> It appears that at least three major spreadsheets, Excel, Apache
>> OpenOffice Cal and gnumeric have a problem with the correct order of
>> operations when dealing with exponents. The gnumeric result is very strange.
>>
>> This problem has probably been reported before but just in case it has
>> not, it would appear to be one more serious problem with spreadsheets. It
>> might be useful in warning people away from using a spreadsheet for serious
>> analysis.
>>
>> Excel
>>
>> 2^2 = 4
>>
>> 2^2^3 = 64
>>
>> Apache OpenOffice
>>
>> 2^2 = 4
>>
>> 2^2^3 = 64
>>
>
> My opinion: One correct, one error! R agrees with me on this:
>> 2^2
> [1] 4
>> 2^2^3
> [1] 256
>> 2^(2^3)
> [1] 256
>> 2^2
> [1] 4
>> (2)^2
> [1] 4
>>
>
>
>
>
>>
>> gnumeric # note one correct, one error!
>>
>
> My opinion: two correct!
>
>
I don’t agree.
All are wrong according to standard math rules except Gnumeric with the exponentiation.
R is correct.
See https://en.wikipedia.org/wiki/Order_of_operationsLesson: always use parentheses to make absolutely clear what you mean.
Berend
>
>> 2^2 = 4
>>
>> 2^2^3 = 256
>>
>> John Kane
>> Kingston ON Canada
>>
>>
> Seems to be a bit offtopic. Unless your point to is to use R for
> important work instead of some spreadsheet. A point with which I completely
> agree!
>
>
> MSExcel, and Apache OpenOffice, appear to implement the above as
> (2^2)^3==64. Whereas gnumeric implements appears to implement this as:
> 2^(2^3)==256. Which is "correct"? Depends on whom you ask.
>
> ref: https://en.wikipedia.org/wiki/Order_of_operations> <quote>
>
> If exponentiation is indicated by stacked symbols, the usual rule is to
> work from the top down, thus:
> [image: a^{b^c} = a^{(b^c)}],
>
> which typically is not equal to [image: (a^b)^c]. However, some computer
> systems may resolve the ambiguous expression differently. For example,
> Microsoft
> Office Excel < https://en.wikipedia.org/wiki/Microsoft_Office_Excel>
> evaluates *a*^*b*^*c* as (*a*^*b*)^*c*, which is opposite of normally
> accepted convention of topdown order of execution for exponentiation. If
> a=4, p=3, and q=2, [image: a^{p^q}] is evaluated to 4096 in Microsoft Excel
> 2013, the same as [image: (a^p)^q]. The expression [image: a^{(p^q)}], on
> the other hand, results in 262144 using the same program.
> </quote>
>
> Gnumeric abides by the above definition. FWIW. BTW  MSExcel also has
> 1900 as a friggin' leap year (due to Lotus 123 apparently), so I don't
> consider MSExcel (or anything else from MS for that matter) to be a
> definitive source of correctness. Personal opinion. FSF associate member.
> Penguinista.
>
> 
>
> Schrodinger's backup: The condition of any backup is unknown until a
> restore is attempted.
>
> Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
>
> He's about as useful as a wax frying pan.
>
> 10 to the 12th power microphones = 1 Megaphone
>
> Maranatha! <><
> John McKown
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list  To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/rhelp> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html> and provide commented, minimal, selfcontained, reproducible code.
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


Let me add a little bit here:
When using math formulas, one should know about the parsing rules form complex expression
which do not have all the necessary parenthesis.
Different systems do have different parings rules.
In the case of a^b^c, the expression is ambiguus because
(as mentioned in a previous mail) in general
(a^b)^c != a^(b^c)
To avoid unintended consequences, just us parentheses and you will get
the right result.
in the case of a^b
The question is the order of precedence of unary  and binary ^.
In Excel, 2^2=4, but 02^2=4
Reason: For Excel, unary  is stronger than the power operator, but binary minus is weaker.
My feeling is that too many people are bashing spreadsheets for the wrong reason.
Spreadsheets ca do things R cannot do: Automatic recalculation when input changes,
and visual point and click modelling of dependencies.
The calculation engine of Excel admittedly has some weak points.
That is the reason why I wrote RExcel which gives you all the advantages of the spreadsheet interface
and allows you to use the R calculation within this interface whenever needed.
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


On Fri, Sep 18, 2015 at 10:04 AM, David L Carlson < [hidden email]> wrote:
> Unfortunately the order of operations is not universal in computing. The
> real question is whether a program performs the way it is documented. Excel
> documents that unary operations take precedence over exponentiation and
> that within groups, the order is left to right. LibreOffice Calc behaves as
> Excel, but does not document the order of operations except to say */
> before +, left to right. I couldn't find any statement about the order of
> operations in the documentation for Gnumeric.
>
> R documents that unary operations come after exponentiation and, within
> exponentiation, the order is right to left. Fortran puts unary operations
> with addition and subtraction after exponentiation with exponentiation
> right to left. C does not have an exponentiation operator, but unary
> operations come before multiplication and division.
>
> When in doubt, use parentheses to make sure you get what you want.
>
>
Very true. I do that if there is almost any chance that I, or another,
might not actually know which is first. I especially adopted this when I
learned a language called APL. It has _no_ precedence of operations. And it
does them from right to left. E.g. A=B*C+D is interpreted as A=B*(C+D). I
did programming in it for a couple of months. Then went back to normal
programming. Wrote completely _wrong_ code. When I asked a friend why the
calculation didn't get the "right" answer (2*4+3 == 14 was example I gave),
he looked at me like I was insane <grin/>.

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.
Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha! <><
John McKown
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


Methinks that any math teaching should make learners aware of the fact that
math conventions are not laws of nature, and that ambiguous expressions may
produce different values in different systems.
I think 2^2=4 is perfectly reasonable.
In my experience, most people after high school math do not know that
binary  und unary  are very different operations.
And that is the fault of the current way of teaching math!
> On Sep 18, 2015, at 18:00, John Kane < [hidden email]> wrote:
>
> A very good point re RExcel for sophisticated users. The majority of spreadsheet users, will never have heard of RExcel (or R for that matter) and very likely will no have the sophistication of knowing that they need to use brackets. Plus RExcel is not available in flavours for Apache OpenOffice or gnumeric as far as I am aware.
>
> If one actually learned the formal mathematical order of operations and still remembers them the expectation is that 2^2 will return 2. In a 20 sheet spreadsheet the error is likely to go completely undetected and may or may not have significant effect on final results.
>
> I, recently, was reading an education blog where the author was bemoaning the fact that shiny new math teachers were teaching that 2^2 = 4. Presumably they are putting their faith in Excel, etc., rather than the actual math conventions.
>
> John Kane
> Kingston ON Canada
>
>
>> Original Message
>> From: [hidden email]
>> Sent: Fri, 18 Sep 2015 17:13:44 +0200
>> To: [hidden email]
>> Subject: Re: [R] Spreadsheet math problem (exponentiation)
>>
>> Let me add a little bit here:
>>
>> When using math formulas, one should know about the parsing rules form
>> complex expression
>> which do not have all the necessary parenthesis.
>>
>> Different systems do have different parings rules.
>> In the case of a^b^c, the expression is ambiguus because
>> (as mentioned in a previous mail) in general
>> (a^b)^c != a^(b^c)
>> To avoid unintended consequences, just us parentheses and you will get
>> the right result.
>> in the case of a^b
>> The question is the order of precedence of unary  and binary ^.
>>
>> In Excel, 2^2=4, but 02^2=4
>>
>> Reason: For Excel, unary  is stronger than the power operator, but
>> binary minus is weaker.
>>
>> My feeling is that too many people are bashing spreadsheets for the wrong
>> reason.
>> Spreadsheets ca do things R cannot do: Automatic recalculation when input
>> changes,
>> and visual point and click modelling of dependencies.
>> The calculation engine of Excel admittedly has some weak points.
>>
>> That is the reason why I wrote RExcel which gives you all the advantages
>> of the spreadsheet interface
>> and allows you to use the R calculation within this interface whenever
>> needed.
>
> ____________________________________________________________
> Send any screenshot to your friends in seconds...
> Works in all emails, instant messengers, blogs, forums and social networks.
> TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if2 for FREE
>
>
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


On Fri, Sep 18, 2015 at 11:06 AM, Erich Neuwirth <
[hidden email]> wrote:
> Methinks that any math teaching should make learners aware of the fact that
> math conventions are not laws of nature, and that ambiguous expressions may
> produce different values in different systems.
>
> I think 2^2=4 is perfectly reasonable.
>
I agree. That is what APL would do. Of course, the number "minus 2" in APL
is not encoded as "2". It is encoded (hope this works) ¯2 This removes
the ambiguity.
>
> In my experience, most people after high school math do not know that
> binary  und unary  are very different operations.
> And that is the fault of the current way of teaching math!
>
Agree. Perhaps we should just "bite the bullet" and go with Reverse Polish
Notation for equations. Much easier to parse. No parentheses and no
ambiguities. Of course, this would raise more howls that converting from
Imperial measures to Metric did. We still haven't done this in the U.S. I
really want to! I sound much taller and thinner in metric. No, I won't say
what the number are. Bad enough that I'm old.

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.
Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha! <><
John McKown
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


I have no problem with 2^2 = 4 if we have consistency.
R 2^2 = 4
Spreadsheets 2^2 = 4
Which is "TRUE"? (For some nebulous value of "TRUE")
For a relatively unsophisticated user this does not bode well if he or see is transferring work from one application to another.
John Kane
Kingston ON Canada
> Original Message
> From: [hidden email]
> Sent: Fri, 18 Sep 2015 18:06:23 +0200
> To: [hidden email]
> Subject: Re: [R] Spreadsheet math problem (exponentiation)
>
> Methinks that any math teaching should make learners aware of the fact
> that
> math conventions are not laws of nature, and that ambiguous expressions
> may
> produce different values in different systems.
>
> I think 2^2=4 is perfectly reasonable.
>
> In my experience, most people after high school math do not know that
> binary  und unary  are very different operations.
> And that is the fault of the current way of teaching math!
>
>
>
>> On Sep 18, 2015, at 18:00, John Kane < [hidden email]> wrote:
>>
>> A very good point re RExcel for sophisticated users. The majority of
>> spreadsheet users, will never have heard of RExcel (or R for that
>> matter) and very likely will no have the sophistication of knowing that
>> they need to use brackets. Plus RExcel is not available in flavours
>> for Apache OpenOffice or gnumeric as far as I am aware.
>>
>> If one actually learned the formal mathematical order of operations and
>> still remembers them the expectation is that 2^2 will return 2. In a
>> 20 sheet spreadsheet the error is likely to go completely undetected and
>> may or may not have significant effect on final results.
>>
>> I, recently, was reading an education blog where the author was
>> bemoaning the fact that shiny new math teachers were teaching that 2^2
>> = 4. Presumably they are putting their faith in Excel, etc., rather than
>> the actual math conventions.
>>
>> John Kane
>> Kingston ON Canada
>>
>>
>>> Original Message
>>> From: [hidden email]
>>> Sent: Fri, 18 Sep 2015 17:13:44 +0200
>>> To: [hidden email]
>>> Subject: Re: [R] Spreadsheet math problem (exponentiation)
>>>
>>> Let me add a little bit here:
>>>
>>> When using math formulas, one should know about the parsing rules form
>>> complex expression
>>> which do not have all the necessary parenthesis.
>>>
>>> Different systems do have different parings rules.
>>> In the case of a^b^c, the expression is ambiguus because
>>> (as mentioned in a previous mail) in general
>>> (a^b)^c != a^(b^c)
>>> To avoid unintended consequences, just us parentheses and you will get
>>> the right result.
>>> in the case of a^b
>>> The question is the order of precedence of unary  and binary ^.
>>>
>>> In Excel, 2^2=4, but 02^2=4
>>>
>>> Reason: For Excel, unary  is stronger than the power operator, but
>>> binary minus is weaker.
>>>
>>> My feeling is that too many people are bashing spreadsheets for the
>>> wrong
>>> reason.
>>> Spreadsheets ca do things R cannot do: Automatic recalculation when
>>> input
>>> changes,
>>> and visual point and click modelling of dependencies.
>>> The calculation engine of Excel admittedly has some weak points.
>>>
>>> That is the reason why I wrote RExcel which gives you all the
>>> advantages
>>> of the spreadsheet interface
>>> and allows you to use the R calculation within this interface whenever
>>> needed.
>>
>> ____________________________________________________________
>> Send any screenshot to your friends in seconds...
>> Works in all emails, instant messengers, blogs, forums and social
>> networks.
>> TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if2 for
>> FREE
>>
>>
____________________________________________________________
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


BEGIN PGP SIGNED MESSAGE
Hash: SHA512
On 18/09/2015 11:13 AM, Erich Neuwirth wrote:
> Let me add a little bit here:
>
> When using math formulas, one should know about the parsing rules
> form complex expression which do not have all the necessary
> parenthesis.
>
> Different systems do have different parings rules. In the case of
> a^b^c, the expression is ambiguus because (as mentioned in a
> previous mail) in general (a^b)^c != a^(b^c) To avoid unintended
> consequences, just us parentheses and you will get the right
> result. in the case of a^b The question is the order of precedence
> of unary  and binary ^.
>
> In Excel, 2^2=4, but 02^2=4
>
> Reason: For Excel, unary  is stronger than the power operator, but
> binary minus is weaker.
>
> My feeling is that too many people are bashing spreadsheets for the
> wrong reason. Spreadsheets ca do things R cannot do: Automatic
> recalculation when input changes,
Shiny is implemented in R and it has this.
> and visual point and click modelling of dependencies.
I'm not exactly sure what you mean here, but I think you're probably
right on this one, in that it is a userinterface issue. People can
implement frontends to R that do just about anything, but those
aren't part of R.
Duncan Murdoch
> The calculation engine of Excel admittedly has some weak points.
>
> That is the reason why I wrote RExcel which gives you all the
> advantages of the spreadsheet interface and allows you to use the R
> calculation within this interface whenever needed.
>
>
>
>
> ______________________________________________ [hidden email]
> mailing list  To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/rhelp PLEASE do read the
> posting guide http://www.Rproject.org/postingguide.html and
> provide commented, minimal, selfcontained, reproducible code.
>
BEGIN PGP SIGNATURE
Version: GnuPG/MacGPG2 v2
Comment: GPGTools  https://gpgtools.orgiQEcBAEBCgAGBQJV/FRAAAoJEHE2Kz23YMZygz0H/2TZEQk2JOS8GQc5jvSXTk5+
qrgROnpgTTZwCX7rh0vPCDTGXSjAxgJikACYxGVWo/jkQKpoIkqcyrk7KnTXkPXG
fmvQ6gkJ8nq7UJ7la4alThtmrBdNhkz2xgvVn3aZIItRwRhgRT2P7f8whi/Ia5IN
CEpJyEg0ymrlVNMG8ncmAgAyebayeJDesJNPma7x7Hw0g00COQ9ZvD7U8joHgIGn
4Tic2nzlcK/ZItz3WQBcOdkqrVMCX5XcsZC6XOPMZyGPk+jIUA1qq7pQovMLWKeq
7JzH6xm6YeQ41QN4AbZyxmIZ8LvonT65MhQpS89hgGbROCZ49nUFquMcZn/Exj4=
=e1J7
END PGP SIGNATURE
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


> On 18 Sep 2015, at 16:31 , John McKown < [hidden email]> wrote:
>
> ref: https://en.wikipedia.org/wiki/Order_of_operations> <quote>
>
> If exponentiation is indicated by stacked symbols, the usual rule is to
> work from the top down, thus:
> [image: a^{b^c} = a^{(b^c)}],
[snip]
...and it might be added that this is (in "paper math") because (a^b)^c==a^{bc} and there would be no point in writing a^b^c if you might as well have written a^{bc}. (The curly braces only being there to indicate that the exponent is bc.)
Of course this sort of consideration hasn't always had effect on programmers, so you do need to check.

Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: [hidden email] Priv: [hidden email]
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.

