Hi Doug,

There is a root of sin(x)*x^2+sin(x)-2*x near -2.3311223704. It is not a root of cos(x)-x*sin(x)+1 and it is not a root of sin(x).

Have I misunderstood you?

acer

I don't see the same error in Maple 11. Using Maple 11.02 on Linux I see the worse answer, sin( RootOf(sin(_Z)*_Z^2+sin(_Z)-2*_Z)) .

Now, how can Maple sensibly and usefully represent only those values of  RootOf(sin(_Z)*_Z^2+sin(_Z)-2*_Z) which satisfy f, so that the answer is both complete and correct when _EnvAllSolutions=true? I don't see that any current RootOf notation in Maple is going to cover this. Am I missing something?

acer

In addition to adding increased confidence and assurance in the product for the Maple user, a large published test suite would allow talented experts to produce patches for the Maple language library.

Without a comprehensive test suite, any patches  (fixes, or enhancements) would be insufficiently tested.

Now, look at the help-page ?UndocumentedNames and scan down to the one named TestTools.

> eval(TestTools);
module()
export Try, Trynocrash, i, _pexports, TestOptions, Info, ResetInfo,
SetRecord, PlotStructure, StatisticsTests, HadFailure, PrintOnFail,
calcver;
description "a package for test tools"
     ...
end module

Now examine the output of eval(TestTools:-Try) . This is for testing purposes. Has anyone here (eg. package authors) tried using it for that? Should it be documented?

acer

One can obtain the source, compile, run (and observe the coverage of) its official test suite, and replace the gmp library that comes with Maple. (Ok, it's probably easier on some platforms that on others.)

Doesn't that make it more thoroughly testable (by the end-user) than Maple's own kernel in several key ways?

acer

The returned result of RootOf(sin(_Z)*_Z^2+sin(_Z)-2*_Z) appears to be wrong, as a root of cos(x) - x sin(x) + 1.

Somehow, the command,

evalf({%})

got displayed in your post as the 2D Math,

evalf({true});

acer

The hard part for graphing this is not dealing with the rationals, it is dealing with the irrationals.

One difficulty is in making f plot as a function (1-to-1, not 1-to-many). Each irrational is only representable in fixed precision floating-point as a value which happens to also correspond (perfectly) to some rational. And that rational should here be plotted also as a rational (using the rule in f for rationals). But if the same point x gets plotted twice, by both schemes, then the plot doesn't really represent a function (because it's 1-to-2).

Also, how does one make the line along y=0 appear to be not merely solid and yet still be faithful to the spirit of the given definition? Omitting the line along y=0 altogether doesn't seem to encapsulate that important part of it all (to me).

acer

It's great that it works for you now.

I suspect that the trick I had posted, about replacing the gcversion() routine, would also suffice as workaround for that part of the problem.

I'm glad that you found SetBuildVariable() as well. But beware (in Maple 11 at least, and maybe 12 too) the first run of Compiler:-Compile() may clobber the overrides that you specify with SetBuildVariable().

I think that all this shows that it is a design in need of improvement. If the result of `gcc --version` has to be matched according to a fixed number of patterns, then something that fragile should not be a lynchpin for the whole Compiler. A "no-check" switch might suffice, to get around it.

Similarly, if location of supporting system libraries like libm.so is so tricky to get right automatically (and 100% of the time) then a overriding mechanism for compiler/linker/flags should be documented and much easier to use. Ie, it should not necessitate kernelopts(opaquemodules=false).

If it's fragile and hard to make perfect/automatic, then it should be easily confgurable.

acer

How would you be able to distinguish the difference between a plot of that function and the plot of the solid lines y=0 and y=1?

plot([0,1],x=-5..5,color=red,thickness=5);

Remember, the rationals are a dense subset of the reals. Between any two reals there exists some rational. And, given a nonzero distance and some real number, there is a rational to be found within that distance from it. So, how could you plot the rationals without it "looking" like a solid line?

acer

The routine Compiler:-Tools:-gccversion() issues the folowwing call, and then parses the result to extract the version number.

Compiler:-Build:-ssystem("gcc --version");

The result of that can be in several forms (due to there being so many gcc variants, I suppose) so it then tries to parse the result using a variety of patterns -- namely Compiler:-Tools:-gccversion_patterns.

Maybe you can try to force that routine call to return an acceptable string, by replacing it with your own routine. For example,

> restart:
> kernelopts(opaquemodules=false):
> unprotect(Compiler):
> Compiler:-Tools:-gccversion := proc() "4.3.0"; end proc:
> protect(Compiler):

> y := proc( x :: float ) 2.3 * x end proc:
> cy := Compiler:-Compile(y):

The Compiler may indeed save that gccversion result somewhere. If I try to alter it once again, after running Compiler:-Compile for the first time, then any further use of Compiler:-Compile results in the error message about not finding a valid installed gcc. In other words, maybe the failure to find a valid gcc version string is itself all that's preventing the Compiler to work for you. Let's hope.

By the way, when the Compiler runs for the first time it initializes all its flags and values. For cflags and ldflags, etc, that initialization has to happen before any values are overridden. Otherwise the initialization clobbers the custom values. But once it is initialized, those flags may be overridden. In the past, I have had some success using these following two commands to get and set the flags. They are internal, and not intended for general use, so kernelopts(opaquemodules=false) needs to be issued before they are accessible.

Compiler:-Build:-GetBuildVariable()
Compiler:-Build:-SetBuildVariable()

acer

It's an attempt at being thorough, without having to visually scan the code.

The help-pages describe the levels of userinfo "intended" for the end-user. But the mechanism works just the same for levels greater than 5. By setting it to some "huge" value one can get some assurance that one is also covering any userinfo messages put in for debugging purposes (and perhaps not otherwise intended for the end-user).

acer

It's an attempt at being thorough, without having to visually scan the code.

The help-pages describe the levels of userinfo "intended" for the end-user. But the mechanism works just the same for levels greater than 5. By setting it to some "huge" value one can get some assurance that one is also covering any userinfo messages put in for debugging purposes (and perhaps not otherwise intended for the end-user).

acer

I'm not sure exactly what you're after. Does this get close at all?

restart:
printlevel := 1;
with(PDEtools):
with(codegen,fortran):
with(CodeGeneration,Fortran):
                                                                                
assume (Q::real,Q<>0);
                                                                                
alias(Q = Q(x, y, t), H = H(x, y, t), S = S(x,y,t) , B = B(x, y, t)):
declare(Q(x, y, t), H(x, y, t), S(x,y,t), B(x, y,t)):
                                                                                
interface(showassumed=2);
qs:=aa/(1-p)*abs(Q)^mm/(H-B)^mm*abs(1,Q);
diff(H, t) = -(diff(Q, x))-diff(qs,x);
                                                                                
simplify(%);

acer

I'm not sure exactly what you're after. Does this get close at all?

restart:
printlevel := 1;
with(PDEtools):
with(codegen,fortran):
with(CodeGeneration,Fortran):
                                                                                
assume (Q::real,Q<>0);
                                                                                
alias(Q = Q(x, y, t), H = H(x, y, t), S = S(x,y,t) , B = B(x, y, t)):
declare(Q(x, y, t), H(x, y, t), S(x,y,t), B(x, y,t)):
                                                                                
interface(showassumed=2);
qs:=aa/(1-p)*abs(Q)^mm/(H-B)^mm*abs(1,Q);
diff(H, t) = -(diff(Q, x))-diff(qs,x);
                                                                                
simplify(%);

acer

I see. Sorry, I missed that. As you suggested, it's likely the assumption on Q that interferes with the effectiveness of the subsequent declare() command on Q. I tried a few other ways, but no joy so far. Maybe someone else will see it...

acer

I see. Sorry, I missed that. As you suggested, it's likely the assumption on Q that interferes with the effectiveness of the subsequent declare() command on Q. I tried a few other ways, but no joy so far. Maybe someone else will see it...

acer