@John2020 So why not provide the additional problematic example!?

It might be that you need to adjust what is frozen, eg. Physic:-diff versus diff or some such thing.

[edit. The above was not adequately clear, sorry. I meant that one might have to ensure that it is not Physics:-diff which is frozen, but the original global name :-diff. I meant that one might distinguish one versus the other.]

As the OP has learned an exact expression can be achieved here, though some of the methodology is not (as yet) explicitly given.

One way in which it can be achieved is through a change of variables under some reasonable assumptions that agree with the supplied plotting range.

This form of exact result does not suffer from the same numeric difficulties under fsolve. This particular form of the exact result can also be evaluated numerically without undesirable small (or float 0.0) imaginary components.

Download inverse_function_with_fsolve_ac2.mw

[edit] In fact the same well-behaved exact form can be obtained even more directly. (The key here is to also pass the lower-bound assumption x0>0.)

@tomleslie The edit I suggested is not too hard to guess, and it causes the code to "run away" for me.

But I agree with you that a worksheet would be better. The OP's last Question was posted with a crucial detail missing (ie. Digits value, which made a significant difference).

@tomleslie I don't think that the OP intended

    if root_r != 0 then

as 1D input, since then it tests a factorial against zero (with unfortunate consequences on whether equations get augmented or not).

It's more likely that the OP intended,

   if root_r <> 0 then

It may even be that the OP used the != syntax in 2D Input in Maple itself, but made the mistake of thinking that literal could be sensibly shown here as plaintext code.

@Jaime_mc2 Why are you using,

   evalf(allvalues(RootOf(HermiteH(7, x), x)));

instead of, say,

   [fsolve(simplify(HermiteH(7, x)))];

Also, would a single solution suffice (if there were infinitely many)? I am wondering also why you are using solve rather than fsolve, when dealing with the equations.

Presumably you intend,
    root_r <> 0
instead of,
    root_r != 0
in the 1D Maple Notation plaintext code that you provided.

The code originally provided runs without error. But after this (reasonable) edit the code runs amok.

@tomleslie Yes, and I had previously added a zip alternative as a postscript to my Answer.

Please show us your problematic code. It could be inlined as text, or a link that you upload and attach to your Question (or a Reply/Comment to it) using the green up-arrow in the Mapleprimes editor.

@janhardo If you want the direct input treated specially then you'll have to enter it in some special manner.

If you enter it as input in the usual manner then the bracketing is no longer present and recoverable once parsing is done to get an expression.

I have shown you a few possible special manners in which to input the expression. There are other possible syntax choices, including variants of those shown.

@mmcdara Numeric rootfinding -- like much other numeric computation -- involves a balance between functionality, robustness, and speed/memory performance.

Very often there is a give-and-take amongst these qualities, when comparing approaches. Ease of use (versus, say, the need to adjust options) is a related consideration.

Even for a restricted class of problem there will usually be some approach that is faster, and some which is more robust.

Even for the restricted class of problem of finding all real roots of a univariate polynomial this dichotomy arises. (Eg. some examples may be more ill-conditioned. Etc. High accuracy goals mixes in  too.)

The given problem class in this posting is more restricted still. You might find yet more specialized approaches. 

The fsolve command leans toward robustness and ease of use. In my experience NextZero leans toward speed. Comparing them sensibly should involve tightly specifying the problem class and goals.

By default fsolve will compute all the real roots of a univariate polynomial, in a single call.

Calling allvalues of a forced RootOf wastes time. At higher working precision it can also allow (very small) imaginary artefacts to appear unnecessarily in the result.

One can simply compute like,

    fsolve(simplify(ChebyshevT(N, x)))

and get pretty good efficiency (including at higher working precision) without unnecessary imaginary artefacts (at higher working precision).

I'll point out that the OP's mentioned target expression,

   I*ln((-I*z+b)/(I*z+b))

is not equal to his mentioned input expression,

   I*(ln(-I*z+b)-ln(I*z+b))

for all z and b. That's is what member vv has demonstrated, by example.

My point is that it's not the case that combine(...,symbolic) is misbehaving. The difference primarily lies in the fact that the two expressions (input, and target) mentioned by the OP are not equal everywhere. The demonstrated difference (for some b and z) is inherent to the expressions themselves.

There are various ways to force the combining of the ln terms in the original expression, ignoring branch distinctions. If you perform manipulations involving ln(... exp(something) ...) or combine(expr,symbolic) then be aware of possible consequences.

I'm stating all this primarily for the benefit of the OP.

@C_R If you really wanted you could pass additional options to g, so that those were passed on to the Int call.

An option to force the specific (coarser) rounding may be part of that. (Additional cruft digits may actually be detrimental here.)

For what it might be worth to you,

Download comb_ln_alt.mw

By the way, if you want to spawn off a related conversation you could use the "Branch" button, instead of starting a wholly distint thread. That automatically inserts URL links between parent and child threads, which helps keep the related content easily accessible. The "Branch" button appears at the bottom of an item, eg. next to the Reply Button.

@janhardo Without extras,

Download combine_symbolic_ex.mw

Why is it not direct enough for you?

You might be confusing that terse approach with additional explanation, manipulation (or leading sign, etc...), and a slightly different starting expression, as shown above.

By the way, in the Reply above you have a typo, so that the expression doesn't agree with your target reformulation. You claim that you want,
    I*ln ((-z*I + b)/(z*I + b))
but you start with,
    I*ln(-z*I + b) - ln(z*I + b)
That's a typo on your part. Presumably you intended to write,
   I*(ln(-z*I + b) - ln(z*I + b))