Electronics > Beginners
Exponents
<< < (10/17) > >>
magic:
Well, having studied computer science at a somewhat maths-heavy uni I can say with certainty:

No one would ever read -3⁴ as (-3)⁴, it's definitely -(3⁴).
I can understand why a naively written parser could misinterpret -3^4.

Ergo, big  :-- for Microsoft.

OK, somebody just asked how they come up with it. Simple: their software just doesn't realize that - without anything on the left is still subtraction, albeit from implied zero. So it ignores it and treats it as part of the number. Then it sees ^ and calculates the exponent.
soldar:
I started using Excel when it was still called Multiplan. I bet few people remember that name or that spreadsheet. It used the row-column notation R4C5 for absolute address and R[-2]C[-1] for relative addressing which I still use in Excel because, thankfully, you can choose that.

In these decades of using Multiplan and Excel I never noticed this quirk which they should have corrected from the beginning. As has been said, changing it now might create a compatibility problem with older sheets.

In the early 1980s, before using Multiplan, I was using another spreadsheet, Dynacalc, on a UNIX-like operating system called OS9, on a Dragon (Tandy) computer.  It is just amazing what they could do with such limited hardware.
Wimberleytech:

--- Quote ---
And that's exactly the answer you would have gotten in the original spreadsheet, VisiCalc! The original designers, in hindsight, admit that ignoring precedence was a poor choice on their part.


--- End quote ---

Son of a gun!  You are correct.  I just tested that expression in Visicalc...who knew??  I guess you did.
Nominal Animal:
Further example:


--- Code: ---echo ' 3 ^ 4 ' | bc
echo ' - 3 ^ 4 ' | bc
echo ' - - 3 ^ 4 ' | bc
--- End code ---
all output 81, because the negation operator - has higher precedence in bc than the exponentiation operator ^ .

That is, the above expressions are equivalent to

--- Code: ---echo ' 3 ^ 4 ' | bc
echo ' (-3)^4 ' | bc
echo ' (-(-3))^4 ' | bc
--- End code ---
Similarly for Bash, bash -c 'echo $[-3**4]', bash -c 'echo $[--3**4]', and bash -c 'echo $[---3**4]' all output 81 .  (The same with bash -c 'echo $(( -3**4 ))' and so on, for the same reason.)

This is explained in their documentation by stating that the negation operator - has higher precedence than the exponentiation operator (^ in bc, ** in Bash), which has higher precedence than subtraction (-).

However, Python, Perl, and Ruby all parse/associate the expressions correctly:

--- Code: ---python -c 'print(-3**4)'
perl -E 'say -3**4'
ruby -e 'puts -3**4'
--- End code ---
all output -81.
Their documentation, fortunately, clearly says that exponentiation ** has higher precedence than negation - .  (Note, however, that they do have slightly different operator precedences from each other, so expressions in one are not necessarily parsed the exact same way in the other.  Trap for young players!)

In general, because many programmers aren't that good at math and changing the precedence/associativity rules when your users have gotten used to them would be downright evil, one must assume that software environments do not always parse or compute expressions correctly.  However, they can almost always be forced to Do The Right Thing, by using parentheses.

(It would be better if there was a separate operators for negation and subtraction instead. I wouldn't mind a superscript minus, -, myself.  It would completely remove the ambiquity.  Similarly for exclusive-or/exponentiation (^).  I blame ASCII for not having suitable glyphs to port to the Portable Character Set.

In all the above environments and languages, adding parentheses will fix the issue: -(3**4) or -(3^4) (depending on what is used to signify exponentiation) will yield the expected answer, -81.

TL;DR: Consider it a human interface problem in various applications and programming languages.  Always use parentheses to avoid mistakes.
ebastler:

--- Quote from: Nominal Animal on April 10, 2019, 02:52:57 pm ---In general, because many programmers aren't that good at math and changing the precedence/associativity rules when your users have gotten used to them would be downright evil, one must assume that software environments do not always parse or compute expressions correctly.

--- End quote ---

You have a point there, but nevertheless it's pretty disappointing. By the same token, you could argue that one should expect some spelling errors in programming languages' keywords -- programmers aren't that good at spelling, and cannot break backwards compatibility once a language has been rolled out. But I have yet to see a language with a "prnit" or "inputt" command.  ;)
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod