Bad Math at Wolfram Alpha (Or Not?) | Hacker News Reader

Bad Math at Wolfram Alpha (Or Not?)

wolframalpha.com

9 pointsmfcc6410 comments

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.

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.

I agree, choosing a single answer at all is a bit weird here.

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.

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

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

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)".

> 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?

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.

asserting wrongness isn't persuasive in the face of ambiguity

Reply on news.ycombinator.com