Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Mathematica does not simplify sinh(arccosh(x))

johndcook.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Why Mathematica does not simplify sinh(arccosh(x))

#51

Post by henrikeh »

noosphr wrote: post #3

More generally it's not at all clear what 'simplify' means. Is x*x simpler than x^2? Probably? Is sqrt(5)^3 simpler than 5^(3/2)? I don't know. It entirely depends on what you're going to be doing with the expression later.

While some comments do point out the general opaqueness of Mathematica, the goal of Simplify is actually documented in Mathematica and something which can be changed: https://reference.wolfram.com/language/ref/ComplexityFunctio...

The default is a balance between leaf count and number of digits. But the documentation page above gives an example of how to nudge the cost function away from specialised functions.

Re: Why Mathematica does not simplify sinh(arccosh(x))

#52

Post by oh_my_goodness »

contubernio wrote: post #9
jstanley wrote: post #8

Earlier quoted context omitted.

Right, that's why you need further assumptions on x in order for that simplification to hold.

It's not a simplification, it's wrong. Sqrt(square(x)) equals abs(x).

Not in general. As people have pointed out elsewhere, it's true if x is real. That isn't always a helpful assumption. (When x is real you can plug that assumption into Mathematica. Then Mathematica should agree with you.)

But consider sqrt(i) = sqrt(exp(i\pi/2)). That's exp(i\pi/4). Your rule would give 1 as the answer. It's not helpful for a serious math system to give that answer to this problem.

When I square 1 I don't get i.

Re: Why Mathematica does not simplify sinh(arccosh(x))

#53

Post by newobj »

rfc3092 wrote: post #41
Almondsetat wrote: post #36

And yet it incorrectly simplifies f(x) = x/x with f(x) = 1

I believe this is correct: x/x = 1 everywhere except 0, where it has a removable singularity. So you can extend x/x holomorphically to full C. This is completely different from the phenomenon described in the article: arccosh discontinuity can’t be dealt the same way. In fact complex analysis prefers to deal with it my making functions path-dependent (multi-valued).

PLEASE explain "So you can extend x/x holomorphically to full C" to someone with only a BSc in math/cs; something about this thread is giving me an existential crisis right now.

Re: Why Mathematica does not simplify sinh(arccosh(x))

#54

Post by kccqzy »

ogogmad wrote: post #31

Does anyone else think that the latest LLMs - some of which can be used locally for free - combined with proof-verifying software like Coq or Lean for mistake-detection, might make many uses of Computer Algebra Systems like Mathematica obsolete? Certainly, people don't need Wolfram Alpha as much. On another point, it sucks to know what this means for Algebraic Geometry (the computational variant), which you could par…

Do you want your LLM to generate one hundred lines of code to do things using open source libraries, or five lines in Mathematica?

This is actually subjective. For the vibe coding folks, they don’t care if the code is long winded and verbose. For others, the conciseness is part of the point; see APL and Notation as a Tool of Thought.

Re: Why Mathematica does not simplify sinh(arccosh(x))

#55

Post by AlotOfReading »

kccqzy wrote: post #23
Someone wrote: post #16

Earlier quoted context omitted.

For Simplify, I expect its a black, or at least gray box to Mathematica maintainers, too. It will have simple rules such as constant folding, “replace x - x by zero”, “replace zero times something with the conditions under which ‘something’ has a value”, etc, lots of more complex but still easy to understand rules with conditionals such as “√x² = |x| if x is real”, and some weird logic that decides the order in which…

A lot of problems look like this. A while ago I was working on a calendar event optimization (think optimizing “every Monday from Jan 1, 2026 to March 10, 2026” + “every Monday from March 15, 2026 to March 31, 2026” to simply “every Monday from Jan 1, 2026 to March 31, 2026”). I wrote a number of intuitive and simple optimization passes as well as some unit tests. To my horror, some passes need to be repeated twice i…

You can simplify most of those problems by writing the constraints down in conjunctive/disjunctive normal forms and applying standard simplification on them, like you're back in school. That also eliminates things like repetition, since doing so also makes the problem declarative. If you need the recursive loops, you're guaranteed to be to stratify them for any reasonable problem. If you wanted, you could solve the problem optimally from this point by finding the prime implicants, or just accept a suboptimal solution that runs faster than you have any reason to care about, like datalog and sql do.

That doesn't work in general for mathematica because it's too powerful.

Re: Why Mathematica does not simplify sinh(arccosh(x))

#56

Post by meatmanek »

> For example, Sinh[ArcCosh[2]] returns −√3 but √(2² − 1) = √3. The expression Mathematica returns for Sinh[ArcCosh[x]] correctly evaluates to −√3

but the expression given is sqrt((x-1)/(x+1))(x+1), which for x=2 would be sqrt(1/3)*3 = sqrt(3)

did you mean Sinh[ArcCosh[-2]]?

Re: Why Mathematica does not simplify sinh(arccosh(x))

#57

Post by rfc3092 »

newobj wrote: post #53
rfc3092 wrote: post #41

Earlier quoted context omitted.

I believe this is correct: x/x = 1 everywhere except 0, where it has a removable singularity. So you can extend x/x holomorphically to full C. This is completely different from the phenomenon described in the article: arccosh discontinuity can’t be dealt the same way. In fact complex analysis prefers to deal with it my making functions path-dependent (multi-valued).

PLEASE explain "So you can extend x/x holomorphically to full C" to someone with only a BSc in math/cs; something about this thread is giving me an existential crisis right now.

- function extension is defining a function where it is not defined

- function extension is an extension that keeps (or gives) Adj property

- extended function is usually treated as originals if extension is good enough. Real analysis starts with defining real numbers and extending familiar functions onto them

- in this particular case we do not need C - even continuous extension on R works and agrees with x/x = 1 at 0

- holomorphic (analytic) extension makes function infinitely differentiable at every point of C

- because of the nature of discontinuity you can’t extend the simple arccosh in any reasonable way on C without introducing multivalued or path-dependent functions

- this continuity makes x/x=1 a reasonable simplification for CAS imo but not for complex functions as in the OP

- many things with point singularities in R have more structure in C, but x/x is not one of them. Even 1/x is of a different nature.

“You do not divide by zero” that forces you to carry x != 0 is more of a high-school construct than a real thing. Physicists ignore even more important stuff, and in the end their formulas work “just fine”.

Re: Why Mathematica does not simplify sinh(arccosh(x))

#58

Post by LegionMammal978 »

AlotOfReading wrote: post #55
kccqzy wrote: post #23

Earlier quoted context omitted.

A lot of problems look like this. A while ago I was working on a calendar event optimization (think optimizing “every Monday from Jan 1, 2026 to March 10, 2026” + “every Monday from March 15, 2026 to March 31, 2026” to simply “every Monday from Jan 1, 2026 to March 31, 2026”). I wrote a number of intuitive and simple optimization passes as well as some unit tests. To my horror, some passes need to be repeated twice i…

You can simplify most of those problems by writing the constraints down in conjunctive/disjunctive normal forms and applying standard simplification on them, like you're back in school. That also eliminates things like repetition, since doing so also makes the problem declarative. If you need the recursive loops, you're guaranteed to be to stratify them for any reasonable problem. If you wanted, you could solve the p…

Even for boolean logic problems, a minimum-size CNF or DNF will not necessarily be the cheapest solution in terms of gates. As far as I know, hardly anyone has even attempted automatic minimization in terms of general binary operators.

Re: Why Mathematica does not simplify sinh(arccosh(x))

#59

Post by rfc3092 »

newobj wrote: post #53
rfc3092 wrote: post #41

Earlier quoted context omitted.

I believe this is correct: x/x = 1 everywhere except 0, where it has a removable singularity. So you can extend x/x holomorphically to full C. This is completely different from the phenomenon described in the article: arccosh discontinuity can’t be dealt the same way. In fact complex analysis prefers to deal with it my making functions path-dependent (multi-valued).

PLEASE explain "So you can extend x/x holomorphically to full C" to someone with only a BSc in math/cs; something about this thread is giving me an existential crisis right now.

As for existential crisis, you probably have missed this one: https://news.ycombinator.com/item?id=46962402

It was really fun

Re: Why Mathematica does not simplify sinh(arccosh(x))

#60

Post by AlotOfReading »

LegionMammal978 wrote: post #58
AlotOfReading wrote: post #55

Earlier quoted context omitted.

You can simplify most of those problems by writing the constraints down in conjunctive/disjunctive normal forms and applying standard simplification on them, like you're back in school. That also eliminates things like repetition, since doing so also makes the problem declarative. If you need the recursive loops, you're guaranteed to be to stratify them for any reasonable problem. If you wanted, you could solve the p…

Even for boolean logic problems, a minimum-size CNF or DNF will not necessarily be the cheapest solution in terms of gates. As far as I know, hardly anyone has even attempted automatic minimization in terms of general binary operators.

That's true, it'll just be the minimal solution in SOP. I'm willing to call that good enough. My experience is that in practice you're often better off just relying on the fact that modern computers can execute billions of them per second.
Post reply on HN