5 ms·

Bad Math at Wolfram Alpha (Or Not?)

9 points by mfcc64 4y ago

civilized 4y ago
In the real world, the right answer is to acknowledge ambiguity and make sure you understand the context and what the person is asking. But without that context, if you must give an answer, this is the best one. Adding 3% to anything means multiplying it by a factor of 1.03. For uniformity, this must include percentages themselves. Differences between percentages are called percentage points, so if you want to add 1% and 3% and get 4%, you should call the second term "3 pp". This will seem outrageous to many programmers, who will understandably want two numeric-looking things of the same type to add in the ordinary way. But percentages don't work that way. They're a shorthand for a non-additive operation so they have different rules.
- injb 4y ago
  I agree about clearing up ambiguity. But I'm not convinced that there's a best way to answer it without context. For instance, enter "1%" into Wolfram and it'll tell you it's 1/100. Do the same for 3% and it'll tell you it's 3/100. Now ask it to add those 2 fractions, and it'll obviously give you 4/100 - which it reports can be expressed as 4%. These are supposed to be alternate representations of the same thing, so arguably the answer shouldn't be different.
  - civilized 4y ago
    I agree, choosing a single answer at all is a bit weird here.
  - beardyw 4y ago
    Though to be fair in normal usage 100 + 3% would be 103. I feel there is an implicit "of it" after 3% which you wouldn't expect with 3/100. I think it's accountant maths.
    - skyde 4y ago
      basically the « % » symbol in 3% is a fraction notation or it’s a type notation you can overload the add operation like below. Add(int x, Percent y) = x + (y/100)*x
  - nh23423fefe 4y ago
    but `+` is polymorphic in the inputs as is `print` just because `print` does one thing doesn't really mean `+` is constrained in the same way
    - injb 4y ago
      Right, I'm just saying I think it's reasonable to expect + to be kind of isomorphic with different representations of the same thing. Let's say f(x) gives some alternate representation of x. Then f(3) + f(1) should be equal to f(3 + 1). Under this interpretation, f(3%) = 3/100 etc, so that 3% + 1% = 4%. But you could certainly argue that the idea of equating 3% with 3/100 is simply wrong. I like it because I like to think of "per" as meaning "divided by", and we generally use it that way when we use units like "metres per second = m/s = ms^(-1)".
- gowld 4y ago
  > This will seem outrageous to many programmers, who will understandably want two numeric-looking things of the same type to add in the ordinary way What is 1 o'clock + 1 o'clock?
- ncmncm 4y ago
  This is the "wrong result can be justified on a technicality" argument. But a wrong result is just a wrong result. How you got there is immaterial except insofar as it offers you clues on how to fix it. Mathematica is well equipped to recognize the circumstances that produced the wrong result, and produce the right result instead. That involves work, but Mathematica has kept a stranglehold on the product specifically in order to extract the revenue that could be used to pay for such work.
  - nh23423fefe 4y ago
    asserting wrongness isn't persuasive in the face of ambiguity
  - deleted 4y ago
    [deleted]

9 points by mfcc64 4y ago

In the real world, the right answer is to acknowledge ambiguity and make sure you understand the context and what the person is asking. But without that context, if you must give an answer, this is the best one. Adding 3% to anything means multiplying it by a factor of 1.03. For uniformity, this must include percentages themselves. Differences between percentages are called percentage points, so if you want to add 1% and 3% and get 4%, you should call the second term "3 pp". This will seem outrageous to many programmers, who will understandably want two numeric-looking things of the same type to add in the ordinary way. But percentages don't work that way. They're a shorthand for a non-additive operation so they have different rules.

injb 4y ago
I agree about clearing up ambiguity. But I'm not convinced that there's a best way to answer it without context. For instance, enter "1%" into Wolfram and it'll tell you it's 1/100. Do the same for 3% and it'll tell you it's 3/100. Now ask it to add those 2 fractions, and it'll obviously give you 4/100 - which it reports can be expressed as 4%. These are supposed to be alternate representations of the same thing, so arguably the answer shouldn't be different.
- civilized 4y ago
  I agree, choosing a single answer at all is a bit weird here.
- beardyw 4y ago
  Though to be fair in normal usage 100 + 3% would be 103. I feel there is an implicit "of it" after 3% which you wouldn't expect with 3/100. I think it's accountant maths.
  - skyde 4y ago
    basically the « % » symbol in 3% is a fraction notation or it’s a type notation you can overload the add operation like below. Add(int x, Percent y) = x + (y/100)*x
- nh23423fefe 4y ago
  but `+` is polymorphic in the inputs as is `print` just because `print` does one thing doesn't really mean `+` is constrained in the same way
  - injb 4y ago
    Right, I'm just saying I think it's reasonable to expect + to be kind of isomorphic with different representations of the same thing. Let's say f(x) gives some alternate representation of x. Then f(3) + f(1) should be equal to f(3 + 1). Under this interpretation, f(3%) = 3/100 etc, so that 3% + 1% = 4%. But you could certainly argue that the idea of equating 3% with 3/100 is simply wrong. I like it because I like to think of "per" as meaning "divided by", and we generally use it that way when we use units like "metres per second = m/s = ms^(-1)".
gowld 4y ago
> This will seem outrageous to many programmers, who will understandably want two numeric-looking things of the same type to add in the ordinary way What is 1 o'clock + 1 o'clock?
ncmncm 4y ago
This is the "wrong result can be justified on a technicality" argument. But a wrong result is just a wrong result. How you got there is immaterial except insofar as it offers you clues on how to fix it. Mathematica is well equipped to recognize the circumstances that produced the wrong result, and produce the right result instead. That involves work, but Mathematica has kept a stranglehold on the product specifically in order to extract the revenue that could be used to pay for such work.
- nh23423fefe 4y ago
  asserting wrongness isn't persuasive in the face of ambiguity
- deleted 4y ago
  [deleted]