@Thomas Richard Whilst I was installing the new version 2016 of Maple, I recalled having submitted this question and having read some of the replies (bug or irrelevant difference or ...). I tried out my original example, yet it still gives the same result...

I was wondering: do you know whether something has happened with the "SCR internally"? Or has this been discussed somewhere and was it decided not to change this?

I still feel very uncomfortable with the provided answers...

-- Regards,

Franky 

Hmmm... I seem to be having trouble replying and picking the right @user alias, sorry for that.

What I wanted to say was: the condition number has a mathematical meaning (as vv said), and since the matrices are mathematically identical, we should get the same mathematical result, perhaps with some rounding errors (leading to some inexact trailing digits). But this is not the case here.

As Marklyan Hinryk said, this issue has been bugging me [to use the approriate language ;-)] for some days now. I strongly feel a user shouldn't be faced with such ****** "problems" [feel free to use your own adjective]. Let alone that users should be attempting to try to localize them.

We've encountered this in our practice sessions in a course on Linear Algebra. I can say they don't trust Maple anymore, and I can't blame them (unfortunately).

-- Franky

 

@Markiyan Hirnyk 

"Working expenses", really???

The matrices are mathematically speaking identical, so their condition number should also be the same (up to rounding errors). But this is not a rounding error — this is just plain wrong!

-- Franky

Hi acer, thanks again for your reply.

Your explanation makes it a lot more clearer thanks. Indeed, the exact result is correct and can be obtained by using the proper convert to radical or properly (re)defining Normalizer and TestZero.

Only your last remark leaves me puzzled again: if they happen to do the same thing, then I would be expecting the same results (off course?), but that's not the case, since explicitly defining Normalizer := x -> normal(x) gives something different.

Again, it's correct for the exact case — I should have changed (or change, if possible) the titel of the question to something else...

Then again, the differences for the floating-point case remain unexplained up 'till now.

-- Many thanks,

Franky

 

Hi acer,

Indeed when converting to radical or when explicitly setting Normalizer, it works fine for the exact case.

I thought Normalizer was set to normal by default, as it says in the documentation:

Normalizer is set to `normal` initially, and is used by the kernel in series to normalize leading terms of divisors.

Also, why would your suggestion of TestZero using simplify be 'safer' than the default?

Testzero is initialized with proc() evalb(Normalizer(args[1]) = 0) end proc, which is a relatively trivial test for zero.

Furthermore, neither of these two have any affect on the floating-point computation, which still says the condition number is 68.06563146 instead of 120 (.something). I still don't see where this comes from, and this makes me feel totally unconfortable with relying on Maple here, especially since other software (e.g. Matlab) does not have a problem with this (and neither does linalg[cond])...

Finally, about your remark on the "hidden zero" being used as a pivot, such things should be avoided, is it not? Or is this the responsibility of the user? Try explaining this to a user who just wants to compute a condition number...

In the LinearAlgebra package, the only information about TestZero and Normalizer is in the documentation of IsSimilar:

Assignment to Normalizer of a stronger normalization routine can provide better zero recognition during this calculation than is provided by the default normal routine. Such an assignment to Normalizer or Testzero may be necessary for input which is not of type ratpoly.

I can't say this explanation helps a lot, instead it only confuses the users even more.

Thanks for your reply,

Franky

Hello again,

Comparing two other cases, we get

product( F((2*i-1) mod 3 + 1), i=1..10 );

F(5) F(7) F(9) F(11) F(13) F(15) F(17) F(19) F(21) F(23)

versus

mul( F((2*i-1) mod 3 + 1), i=1..10 );

F(2)^4  F(1)^3  F(3)^3

What is going on in the first (product) case???

-- Franky

What I want is to ensure that the assignment of x to 7 inside the procedure does not get outside the procedure. So after calling f(y) for some variable y, y should keep its current value after the executing of y... That's how it works in C, using pass by value. You can reassign an argument inside a procedure, but that does not affect the value of the passed-in variable. So even if library routines rely on the pass by reference behavior, is there a way to tell a procedure to either get a pass by value behavior, or to give an error/warning when a passed-in variable gets changed inside a procedure? -- Regards, Franky

Thank you very much - it works like a charm!

-- Regards,

Franky.

Well, > g := f(x,a,b) assuming a::integer, b::integer; results in g := (-1)^a * GAMMA(a) * GAMMA(-a-b+1) / GAMMA(-b+1); Filling in b=3 again gives division by GAMMA(-2) ... the same problem. Looking at the integral, however, and filling in values for a and b, e.g. > h := f(x,2,3); gives h := 1/4 * x^4 - 2/3 * x^3 + 1/2 * x^2; which is just a simple polynomial... -- Regards, Franky

Well, > g := f(x,a,b) assuming a::integer, b::integer; results in g := (-1)^a * GAMMA(a) * GAMMA(-a-b+1) / GAMMA(-b+1); Filling in b=3 again gives division by GAMMA(-2) ... the same problem. Looking at the integral, however, and filling in values for a and b, e.g. > h := f(x,2,3); gives h := 1/4 * x^4 - 2/3 * x^3 + 1/2 * x^2; which is just a simple polynomial... -- Regards, Franky

For your information, > value( Int( t^(a-1) * (1-t)^(b-1), t=0..x ) ); gives exactly the same results, that is, it is replaced with GAMMA and hypergeom in Maple-11/12, and stays unchanged in Maple-10. Actually, I just want to know whether the replacement is valid or not... -- Regards, Franky.

For your information, > value( Int( t^(a-1) * (1-t)^(b-1), t=0..x ) ); gives exactly the same results, that is, it is replaced with GAMMA and hypergeom in Maple-11/12, and stays unchanged in Maple-10. Actually, I just want to know whether the replacement is valid or not... -- Regards, Franky.

The vertical asymptote at x=0 is shifted by quite a distance! This is the first time I have seen such a bad, bad plot! Although I understand what you are saying, my opinion is that this should never happen - certainly not with such a simple function. Changing x=-Pi..Pi to x=-4..4 or even x=-3.1415..3.1415 gives a much better result (though still the same happens)? Why is it so bad here to take x=-Pi..Pi? Adding discont=true is what was missing - thanks for that. But still I feel that the default plot gives a very bad result. -- Regards, Franky.

Do you have an example of this?

Do you have an example of this?