@Muhammad Usman Do you agree or disagree that there is something wrong with your value of epsilon​​​​​? 

@Fereydoon_Shekofte Coding Theory is the branch of mathematics that studies error-detecting and error-correcting "codes", which are means of encoding digital/binary information with extra bits (in some optimal way) so that it's possible to detect most accidental^[*1] errors arising from the transmission or storage of the data via potentially noisy media. With some more extra bits, it's possible to correct some errors also.

A prominent example is compact disks (CDs). The code that they use can perfectly correct up to 15%^[*2] of corruption of the disk. That's why dirty and scratched CDs are often still playable, producing exactly the same sound as when they were new.

[*1]  I emphasized "accidental" because, AFAIK, Coding Theory makes no attempt to thwart intelligent, malicious hackers who know the code from getting corrupt data through a channel by design.

[*2]  Getting the 15% maximum correction depends on the corruption being evenly spread over the CD. This is why if you wipe a CD with a cloth to clean it, you should do it radially. A scratch along an arc concentric to the disk can corrupt a large contiguous swath of data and not be correctable. Even if it's much less than 15% of the total disk, it may still be more than 15% of the contiguous data blocks that have been damaged.

What happens if you go to menu File => Restore Backup? If backups are enabled, that should take you to a standard file-selection dialog.

@mmcdara The only place where exp functions and the numeric literal 1000 occur are in the ICs. This is precisely what you did change.

(In the following discussion, I've changed the OP's lowercase l to L because the l is easily mistaken.) 

You seem to be trying to compensate for the OP's very wrong huge epsilon value (> 10^7) by making the argument to exp of much smaller magnitude. IMO, that can't possibly work in any meaningful way----and here's why:  We're given that y is bounded by 0 <= y <= 1, and L is some fixed value of y  (L = 1/5 is used in the OP's example). The piecewise expression that uses epsilon in the ICs is of the (logical) form

• "If y is within epsilon of L, then return a very small positive number, otherwise return 1 minus the same very small number."

So how can an epsilon > 1 be meaningful? I'm not saying that it'll be erroneous in any arithmetic sense; rather, I'm saying that it can't serve any practical purpose. That value of epsilon must be the result of an error the OP made in setting up the problem. 

I do think that the -1000 used by the OP will be problematic, as I mentioned earlier, and its magnitude should be reduced. But I wouldn't go so far as to change it to -1/1000 as you did.

@Muhammad Usman Your value of epsilon is 3.12 * 10^7. That's way too big. I expected epsilon to be something like 10^(-3) or less.

Also, note that in floating-point computation 1 - exp(-1000*(y-l)^2) is often likely to be identically 1 (a phenomenon known as machine epsilon), which (I'm just guessing here) is precisely what you're trying to avoid.

@acer I think that your disparagement in the ending paragraph of your Answer may be due to conflation of the name-forming quotes `...` and the empty-named function ``(...). Only the former can lead to inappropriate changes in typography, such as italics. Here is each applied to the OP's situation (assuming one wanted to directly input the expression as inert). Compare the 2D output of these:

1. `3`*(a - 1)  #3 becomes an italicized name.
2. 3*``(a - 1)  #produces desired output; a-1 remains type `+`.

The expand command will turn #2 back into what one would've had if `` weren't used in its input.

I think that the OP may want to deconstruct to an inert form an already-automatically-simplified expression. In that case she can use (assuming expr is an expanded polynomial such as 3*a - 3):

content(expr) * ``(primpart(expr))
or (same thing in a more-functional style)
(content * (``@primpart))(expr) 

Vote up.

I converted this from a Question to a Post yesterday. I only mention it so that it'll appear on the "Active Conversations" list. The conversion process seems to remove it from that list.

The default grid is [49,49], so your [200,200] is more than 16 times larger, so it likely takes more than 16 times the amount of time.

@NIMA112 In  your case, singularities occur along the lines in the A-B-plane where the arguments to your lns are 0. Specifically, those lines are B = 0, A = -B, and A = -100*B.

@NIMA112 I think that you've downloaded an older version of DirectSearch. Try this one:

https://www.maplesoft.com/Applications/Detail.aspx?id=101333

It's a shame that the Maple Applications Center returns the older version as the primary "hit" with barely a hint that there's a newer version. It's especially a shame considering that this is, IMO, the most useful third-party package ever written for Maple.

@Ritz11 That's a decent answer written from a non-language-specific functional-programming perspective. That is, there are no Maple-specific details other than precisely those copied verbatim from the original Question. So, was that written by ChatGPT or similar AI?

Here it is with some Maple details:

p:= 2*(x-2)^2*(x-1);
F:= factors(p);
seq[fold= (`*`, fun(F[1]))](fun(f[1])^f[2], f= F[2]);
 

@NIMA112 I suspect that the roots are found by trial-and-error. Making implicitplots (as I showed above) helps. Roots are where the red and green cross. You need to change the ranges of A and B. Many choices will show no roots. If you find an intersection, that gives you about 2 significant digits of A and B. You then use these as seed values to fsolve to refine to as many digits as you want (which doesn't always work). The plots are computationally intensive, taking about 2 minutes each.

@sand15 That's strange. I don't know what's happening there. If one were really interested, one could display all the results of the assignments leading up to the creation of the two equations and check where the numeric values in the two executions (2015 and 2023) begin to diverge.

Anyway, this implicitplot clearly shows the 2 roots that I proposed. And by adjusting the ranges appropriately, it'll show the 2 latest roots that @Axel Vogt found. (And it finds another root fairly close to Axel's [A= 37.6324, B= -0.356503].)

plots:-implicitplot(
    Re~(rel), A= -4..1, B= -1..2, 
    gridrefine= 3, crossingrefine= 3, color= [red, green]
);

@sand15 I had moved the OP's Digits:= 50 from where it originally appeared in the worksheet to immediately after the restart: Making that change in your version of the worksheet and re-executing your computation of the residuals using my posted numeric solution yields

eval(rel, {
    A = -2.7553365135418814642586082436429575890825402826031,
    B = -0.70285804987973303586180028708027467941012949957141
});
[-4.426*10^(-43) - 0.*I, 
-4.0506731414438437950164110646723220186973915791808*10^(-40) - 0.*I]

which seems sufficiently close to 0 to me.

@Joe Riel I also found those lines of code, and they clearly show why expand isn't idempotent in this case. The question to me is Shouldn't it be idempotent by design? That is why I only said that perhaps it was a shortcoming or bug. Making it idempotent would be easy.