Want add, problem for today not seems to be related only to "minimal nonzero" value. Somwhere it highly depends on machine epsilon. So, other place of double harware dependance:

plot_test.mw

That what i want. You see,

"Error, invalid left hand side in assignment"

for assign(m || (RVars[1,1]),  5);

but there are even two your workarounds.

That what i want. You see,

"Error, invalid left hand side in assignment"

for assign(m || (RVars[1,1]),  5);

but there are even two your workarounds.

@Markiyan Hirnyk ,

i'm not about "maple for me". I'm about "me for others". With maple everything is OK.

@Markiyan Hirnyk ,

i'm not about "maple for me". I'm about "me for others". With maple everything is OK.

@acer 

Aha, that's what i say. Better for me to create interface with inputting of PDF's directly. Of course, generally speaking, problem there is every function definition creates barrier, and b from this example treated as local to this function, ao not indent to main expression.Better to avoid such parsing at all. Hope, users forgive me about "caution" label. Users use to panic in such situation :)

@acer 

Aha, that's what i say. Better for me to create interface with inputting of PDF's directly. Of course, generally speaking, problem there is every function definition creates barrier, and b from this example treated as local to this function, ao not indent to main expression.Better to avoid such parsing at all. Hope, users forgive me about "caution" label. Users use to panic in such situation :)

@Markiyan Hirnyk 

Thank you to all of you. In this case i understand that it rather my error. It's kind stupid to propose user to input whole tricky Distribution constructor and trying to locate parameters over which it depend on. It's better in some cases simply input PDF directly. And yes, of course last case not universal too, better to input GeometricDistribution than infinity sum of Dirac's delta fo it PDF. So, should be checkbox. Goddamn, i hate GUI :( 

And yes, caution about bad behaviour of Distribution  constructor... Hate it...

@Markiyan Hirnyk 

Thank you to all of you. In this case i understand that it rather my error. It's kind stupid to propose user to input whole tricky Distribution constructor and trying to locate parameters over which it depend on. It's better in some cases simply input PDF directly. And yes, of course last case not universal too, better to input GeometricDistribution than infinity sum of Dirac's delta fo it PDF. So, should be checkbox. Goddamn, i hate GUI :( 

And yes, caution about bad behaviour of Distribution  constructor... Hate it...

Axel Vogt,

It's quite OK for me:) I have no such situation. But it seems generally would work too because even no errors would occured (for symbols it just will return them). But if you also have smth like sqrt(2) you could apply only half

  convert(%, rational);

and it should be OK in that case too.

Axel Vogt,

It's quite OK for me:) I have no such situation. But it seems generally would work too because even no errors would occured (for symbols it just will return them). But if you also have smth like sqrt(2) you could apply only half

  convert(%, rational);

and it should be OK in that case too.

Sorry for up, but...

" The code
may be excellent code, but it’s written in 1989 let’s say. It’s excellent for 1989. Now Maple
starts evolving. The theory starts evolving/improving too. There may be better algorithms. There may be better constructions in the language that allows you to do whatever you were doing more efficiently, or you have possibilities of covering other domains that you were not covering before. So the code ages. Unless somebody is actively maintaining it, the code ages (sometimes called “bit rot”). No matter how good the code is, it will age. In the case of computer algebra and in the case of Maple, things tend to age pretty quickly. They require maintenance. Without somebody actively maintaining the code what happens is that, no matter how good the code is initially, at some point it becomes a liability. At some point it becomes a piece of code that is too slow, doesn’t do the job properly, is coded using archaic constructs, inefficient constructs, and so on. At some point it is either removed, or the company or somebody else actively takes over that code. It’s very difficult for any researcher to actively take over someone else’s code. It’s not the type of thing that researchers will normally do. If you have a new idea, you start from scratch. You are not going to go and patch something in someone else’s code. It’s really the job of the company to maintain that code."

Gold words! Why still today many people don't understand that?! I mean not only in Maple.

doesn't work.

For example

> restart;
> interface(verboseproc=2):
> eval(`fsolve/sysnewton`);

and within number of formats via "export as" in best case it only writes

proc(eqns, vars)  ...  end;

as if verboseproc less than 2

doesn't work.

For example

> restart;
> interface(verboseproc=2):
> eval(`fsolve/sysnewton`);

and within number of formats via "export as" in best case it only writes

proc(eqns, vars)  ...  end;

as if verboseproc less than 2

"using operators instead of expressions seems to use a weaker tolerance".

Yeah, it looks natural. All of that functions was created via codegen stuff so they are optimized => less operations made => precision of result is higher. But problem not in tolerance i.e. smth that checked and smth else under check fails. There could be another stuff that i had with newton under c on double type.Namely, because of round-off error newton algorythm could be divergent i.e. stuck on pairs (or even triples and generally on arbitrary number, i suspect) of points x1, x2 such that

x2= newton_step(x1) and x1= newton_step(x2).

To overcome such situation after "critical times of guesses" i fixed delta=|x2-x1| and

after "other critical times of guesses" i calculate new delta and if i see that new delta wasn't twice less than old one then i changed guess to random perturbated:

x2+=unit_rand()*(x1-x2). Sequence of guesses still inside bounds and more probably covergent to only one point.

I just wonder, wheather maple developers did smth like that, because such behavior doesn't depend on neither tolerance cryterium nor precision of calculations as well. It depends only on precision in that sense if precision is higher then such situation is less probable to occur but still probable.