Giuseppe Panei writes:
 > I hope this is in right format.

Yes.

 > The intrinsic sqrt (z) for z complex yields only a result.

 > If I need all the solutions, have I write a module to overwrite the original
 > intrinsic ? (This new intrinsic maintain the same name as original.)

You can, but I recommend against it and there are complications.  And,
as I mentioned before, you need to define exactly what you would
expect this replacement to do.  Just saying that you "need all the
solutions" doesn't define exactly what you want.  How do you expect
these to be returned?  Is the function to return an array?  If so,
then it won't be usable in the same contexts that the existing sqrt
is, making it seem like a bad idea to replace the existing sqrt.

Also, as someone else pointed out, this seems like a lot of
complication for a trivial problem.  The two solutions are what
sqrt(z) currently returns and the negative of that.  If you wanted
those in an array, you could just write

  (/ 1, -1 /) * sqrt(z)

If that's not what you want, then I don't understand the question.

 > If I want all the n-root of z = z1 ** (1 / n) must be overwritten the **
 > operator?

In a way, the answer to this one is much simpler.  No, you can't
override intrinsic operators.  You can extend them to new types where
they don't have intrinsic definitions (for example, you could define
** for a derived type), but you can't override them.

If you could override them, then you'd need to answer the question
of exactly what answers you wanted.  There isn't a n'th root operator
at all - there is an exponentiation.  The difference is significant.
In particular, to do an n'th root, your function does *NOT* get n
as an argument.  It gets a floating point number.  Turning that
floating point number into some rational form (such as 1/n) is not
at all trivial...it is most unlikely to equal exactly 1/n unless
you are restricting this to some particular choices on n (notably
powers of 2).

If you want to define an operator than takes n as one of its arguments
and gives n'th roots, then I suggest that ** would be a pretty
inappropriate choice of thing to overload even if it were allowed.
If, however, you expect to be able to raise something to a power
of approximately 0.1111111 and expect to be able to recognize that
as an approximation to 1./9. that should be treated much differently
than, say 0.1111112, I think you have a lot of work ahead of you in
terms of precisely defining what the problem is before you are
ready to figure out how to do it in Fortran.

--
Richard Maine                |  Good judgment comes from experience;
[log in to unmask]       |  experience comes from bad judgment.
                             |        -- Mark Twain