@one man If you are allowed the somewhat ad hoc use of 1.*10^(-10) as a starting point for NextZero then one could use fsolve similarly, ie, where you called NextZero in the loop (after instantiating with numeric values for ns):

   fsolve(eqn, 1.*10^(-10)..infinity)

For example,

restart;
N := 60: L := 10: a := 2*10^(-12):
ns := [.9603, .9647, .9691]:
eqn := proc (A) options operator, arrow; ns[i]-1+(N/A+(A*L)^(L/(1-L)))^((1-L)/L)*(2+a*exp((N/A+(A*L)^(L/(1-L)))^(1/L))/(A*L*(N/A+(A*L)^(L/(1-L)))^((L-1)/L)+a*exp((N/A+(A*L)^(L/(1-L)))^(1/L))))/(A*L) end proc:
for i to nops(ns) 
do 
  fsolve(eqn, 1.*10^(-10)..infinity);
end do;

        9.300682773*10^(-10)   
        3.054144319*10^(-9)  
        1.172662805*10^(-8)  

I'll note that at default Digits=10 not all the NextZero results you showed are accurate to ten digits.

@golnaz The conditions under which the different computational path is taken by fsolve here is a bit complicated.

The following happens to handle both your equations. And fortunately it's not horribly expensive for these examples. I am not saying that it will handle all other possible examples. There is one internal solving method (one of the constructed inverse iterators) which happens to work for these two examples. But its construction depends on the form into which the algebraic expression is cast.

Download r_ac.mw

[edit] I think that reliance on the above fortuitous form is not the best approach for you. I think that it'd be better to use ranges nudged slightly off singular points, since that can usually be automated.

@Syed Asadullah Shah Your code makes F as a table. Do you understand than F(3), F(2), F(k+2) is not correct Maple syntax for indexing into that?

Do you understand what I meant by an instance of pade*(...) in the code?

Perhaps you might start by making syntax corrections.

@golnaz I will submit a bug report against this.

I notice that the following succeeds even without specifying the much reduced range for A. It's following a different path inside the internal fsolve:-fsolve96CplxUni routine.

Download A_ac2.mw

@Syed Asadullah Shah Please answer properly.

@Syed Asadullah Shah 

Please answer my question properly: What do you mean by F(k+2)? Did you mean F[k+2] instead?

Don't repost the same worksheet.

@DJJerome1976 There seems to be an issue with the 2D Input's parser, in particular with how it resolves the name Degree when used in that local declaration. The 2D parser is not resolving that to the binding of the GraphTheory package's export, despite the fact that with(GraphTheory) was previously executed. That problem doesn't occur with 1D input.

Here's an alternative (using Maple 2022.1, which I think may be the same version as you):

Download graph_ac.mw

Why haven't you bothered to attach the actual data (Mat2)?

@Thomas Richard I do not know of any launching option or init file setting that would change that limit.

I tried editing my init file and including a concocted line for FileMRU11. When I launched the GUI that entry did not appear in the drop-list, and it vanished upon full closing.

@nm The (mapped) operator,

   z->assign(z)

is a procedure in its own right. It declares its own z as its (only) procedural parameter. That z is not a parameter or local of a procedure within which that inner prodecure is defined.

Consider this example:

  f := proc(x)
    local p, r;
    p := proc(z) z^2; end proc;
    r := z -> sin(z);
    (z->sqrt(z))(p(r(x)));
  end proc;

The "z" that is a parameter of
   proc(z) z^2; end proc
is not a local or parameter of f.

The "z" that is a parameter of
   z -> sin(z)
is not a local or parameter of f.

The "z" that is a parameter of
   z->sqrt(z)
is not a local or parameter of f.

Please add any closely related followup example here, instead of in a separate Question thread.

@C_R You wrote, "What I just tried: When this equation is inserted into an evalf call, "t54" and "la" are defined as double in the C code (without requiring your solution).

codegen neither requires your solution nor evalf workarounds (which make the code less clean)."

You just described something as involving an "evalf call", and then characterize than that as not being an "evalf workaround".

By the way, I deliberately didn't mention the approach of wrapping in an evalf call since that could possibly alter the structure (prematurely). That's one reason why I went for the type approach. Another possible reason is that roundoff error might produce inferior float approximations -- you didn't mention using evalf[15] or (possibly necessarily) even higher working precision. Another reason is that some targeted variable (which one hopes to be declared float) might only appear in equations that also involve variables that one wants declared integer. Forcibly specifying the types of the (Maple language) procedure seems like a much tighter and generally better approach.

CodeGeneration[C] tries to deduce the types of variables during its pass through the code. Yes, the absence of floats in formulas can lead it to figure an integer rather than a float type declaration; that aspect is by design. Yes, it is known to be quirky with regard to the defaulttype option. That's not really news. That's all part of why I'd instead suggest putting type specifications on the procedure's parameters.

@C_R I don't understand what you're now trying to say or ask, sorry. In particular, I don't understand what "required" means in your Reply.

Using "float[8]" as type-specification of the Maple language procedure's parameters induced CodeGeneration[C] to translate to a C language declaration with "double". And the Maple procedure can be generated with that effect specified programmatically, which is what you originally seemed to be asking. It's unclear to me how you might now be trying to follow that up.

It's true that CodeGeneration[C] has some warts. It might not always do as good a job as does Compiler:-Compiler. And so on.

I cannot recall seeing anyone use "double" as a type in Maple in a highly useful and practical scenario. It happens that CodeGeneration, Matrix/Array/Vector & LinearAlgebra/Statistics, and Compiler:-Compile, etc, know about the Maple type float[8]. I personally would not expect any of those to understand "double" to mean the same thing as "float[8]".

It may be that someone added a Maple type "double" in Maple 2015. I'd be surprised if they had also made the effort to make all the Maple contexts that recognized "float[8]" also accept "double" in the very same ways. I think that doing so would be misdirected effort.

You are missing a multiplication between one instance of Pi and the bracket that immediately follows it.

You'll need to correct that, either with an explicit multiplication symbol or (if still using 2D Input) an extra space.

(In an Answer below this was corrected in the 1D plaintext input.)

@mmcdara Perhaps this will explain a little.

The elementwise tidle syntax is less flexible here, and goes for speed. (Less flexibility and terseness often go together...) The map command provides flexibility here.

Download float8_map_tilde.mw

Btw, I didn't do any conversion to list, since it's not needed here and seems more complicated.

ps. Sometime I switch to Source mode in the Mapleprimes editor, and paste in output from Maple's Commandline Interface (or from the GUI with prettyprint=1) between <pre></pre> tags. That can be related to whether my rtable outputs appear explicitly instead of as some strange handle.