Unexpected use of k$ notation in output of Reduce?

Questions
, , ,
1

Motivation: Analyzing solutions to z = z^z

So I’ve been approaching this (probably futile and transcendental) equation for a while, from a variety of angles. Below is a basic desmos screenshot of the various components.

Screenshot2025-07-07142055.png
Screenshot2025-07-07142055.png2559×1208 371 KB

The most promising has seemed to be via first parameterizing |z| = |z^z|. Perhaps via an explicit function of x for y. As an undergrad barely familiar with complex analysis, any potential solution has evaded me. Finding a solution, for any of the relations, probably requires some Lambert W stuff if a solution is even possible.

So I checked wolfram. And mostly, it just tells me it also can’t find a solution. Fine enough.
Except for when I check |z| = |z^z|. Then, sometimes it tells me something involving some seemingly internal and buggy components.

This can most easily be seen via the wolfram alpha link: |x+yi|=|Power[(x+yi),(x+yi)]| - Wolfram|Alpha

The input is read correctly. It correctly plots an implicit. But for example, it tells me that a solution is “y = -Im(x) + e^Re(K$4071615[1]) + i Re(x)” which is nonsensical. The value after the dollar sign changes with each load of the page.

I also see this behavior in Wolfram Mathematica 13.3, via Reduce.
For example, my input:

Reduce[Abs[x + y*I] == Abs[(x + y*I)^(x + y*I)] && x > 1 && y > 0, {x,y}, Complexes]

returned the output:

E^Re[K$109780[1]]>1&&1<x<E^Re[K$109780[1]]&&y==Sqrt[E^(2 Re[K$109780[1]])-x^2]

Which is again, nonsensical. None of the K components let me view documentation, and seemingly randomize with each evaluation. I haven’t found much about this problem via searching online, apart from confirming that the k dollar sign notation has to do with the internal evaluation.

Expected Behavior:
I expect that Reduce would either output itself and an error about the system being unsolvable, or output an equivalent mathematical expression which contains functions and quantities with documentation.

It’s fully likely the solution doesn’t have any finite representation using standard functions and such. Wolfram can’t change which transcendental functions have computable roots, but I doubt this behavior is an intentional way to convey that. Or maybe there is something useful buried by this error…
Either way, thanks for reading and any suggestions/help.

2

Yeah, it looks like some internal symbols were leaked out. Mathematica “localizes” by using naming conventions. To create a unique symbol it appends $n where n is an integer that keeps getting larger to insure no name collisions.

FWIW, I’m not sure how Mathematica will handle the constraints x>1 and y>0 when you’re explicitly setting the domain to be Complexes. I don’t think that really has anything to do with the specific inability to reduce, however.

3

The K$... variable is a parameter. It is likely generated internally by Module[], and it shouldn’t be left in the answer. I’m not sure why you’re seeing it, but it is helpful. If we replace it by k, we can construct the following parametrized family of solutions:

mySol // ClearAll;
mySol[k_?NumericQ] := 
  First@SolveValues[{ComplexExpand[
      Abs[x + y*I] == Abs[(x + y*I)^(x + y*I)], 
      TargetFunctions -> {Re, Im}], 
     0 <= x <= E^k && y == Sqrt[E^(2 k) - x^2]}, {x, y}];

Then

Table[N@mySol[k], {k, 0, 5, 1/4}] // ListLinePlot
4

First doesn’t seem to be able to be applied to the Solved expression. Thinks its just an empty list?

Screenshot2025-07-10001307.png
Screenshot2025-07-10001307.png1257×822 41.8 KB

5

The wolfram documentation for Reduce does specifically mention that you can restrict your parameters to be real, but allow calculations involving complex numbers via that format.

Screenshot2025-07-10002058.png

Thanks for the variable localization primer, though!

6

Sorry, I copied the wrong code. I updated my previous answer, which should work now.