| Methods / ti-cas.org | |
| Some remarks around the square root |
|
Square root Differences between various C.A.S. in the manipulation of expressions... |
Author: Bernard Egger |
| Public: Students, Teachers |
Hardware used:
|
Processing of the square root by the computer algebra systems is varied, and often surprises theirs users, pupils or professors. Here, it is a question of showing on some examples certain problems.
To tackle the question we chose to examine three tools: the TI-89 (or the TI-92 Plus / Voyage 200 v2.05), the Derive software in its version 4, and the Maple software.
How the three software treats the simplification of expressions of the type:
;
; ![]()
Let us start with the TI-89.
|
|
Simplification appears traditional. And
yet, the second result is enough surprising: it is turned over in " factorized
form ", which seems logical since it was already the case of But then why the programmer did not preserve (- 1)² |
The last line highlights the option " factorization " because the form -2*sqrt(2) + 3 is turned over (logically) in developed form and not in factorized form.

The choice of DERIVE appears more coherent here: the two answers are developed.
We will see thereafter that this option makes it possible Derive to correctly answer certain questions which will put the TI-89 and Maple in the embarrassment.

For MAPLE, no problem : without additional instruction, there is no evaluation.
The differences are more " spectacular " if one goes more in the analysis.
|
|
The TI-89 preserves same logic with this new expression. One can without problem apply the function develop and obtain another writing. NOTE : DEVELOP = EXPAND |
|
|
|
Let us notice that it preserves this coherence with variable X, applying the same type of writing and transformations. |
|
|
Derive carries out a development like previously. However, the software differently treats the case of a variable X and that of sqrt(2) |
The case of Maple is more complex especially with regard to the use by the software of the functions expand and Factor
We will see how much the difficulties of its use for classes of level college appear clearly on this example: little or not transformation of writing without indication, a use less " transparent " of certain commands.
|
|
without precise instruction, Maple does not have does not proceed to any transformation. However, as soon as one applies algebraic functions, its action can surprise, at least compared to the results which the TI-89 provides. Factor which corresponds to factorization should give a result in which the last operation is a multiplication or a division. But ... |
|
however one finds here a more " traditional " use of expand and Factor |
![]() |
With regard to the TI-89, the programmer had initially seemed to us to have chosen a more total coherence, while making some " concessions " with specificities of numerical calculation.
And yet... Let us examine the following screens ...
|
|
In the absence of numerical simplifications, very " logically ", there factorized form is stable here: no transformation of writing seems to be necessary. |
|
|
|
Quite relative stability, since, here, the computer changes of rule and develops. The simplification which follows seems rather normal. |
|
|
|
And yet with the usual algebraic tools, factorization seems less obvious. |
|
|
|
Logic, not? But, finally one does not understand any more very well how all that was conceived. |
|
|
|
Finally a better respected coherence: in the presence of integers, the square root forces the development. |
|
|
|
What is surprising here, it is that the computer does not have any problem of factorization. |
Let us return in Derive:

The software appears more homogeneous than the TI-89.
|
For Maple, one can see in this example the richness of the available tools ... transformations of writing not being carried out automatically, it becomes possible to act by " small keys " to modify the form of the expression. |
|
The processing of the square roots is varied on our three software: the preceding examples showed that none software seems completely free from inconsistency.
Now let us examine the consequences of the choices of the programmer in a particular case.
Let us examine this expression. (llok at the screen)
Which transformation undergoes in each software?
|
|
Result not too unexpected: the computer transformed into sqrt(7 – 4*sqrt(3)). |
|
Completely different choice for Derive. |
|
|
|
A third possibility chosen by Maple |
|
Three distinct choices which conditions later answers.
Let us notice that if the form returned by Derive is " stable ", it is not the case for the TI-89.
However the TI-89 " knows " to lead to the form suggested by Derive.
It is seen here that the choice of the programmer is to proceed in two times, but it is difficult to know if it acts is a teaching concern.
Always it is that these various forms of output of the result condition possible checks.
If for example one proposes to each software to test this equality : (look at the screen)
|
|
An equality is true or false. Here it is issued false. |

Much less difficulties for Derive which had led to this simplification from the beginning. The " developed " form is canonical and thus facilitates the comparisons.
|
|
Maple is more careful that the TI-89 by not giving an answer |
Apart from any later transformation of the expression, one can see that on the first level the choices of the programmer are not without consequence as for the tests which could be led to carry out a user (in particular in a program).
The passage to the approximate values bring only a little more confusion still: in our example there computer will turn over " false " once again.
|
|
Problems of round-off! Justifiably the TI-89 will think that the numbers are distinct. |
In other cases, it will be exactly the opposite:
|
|
The two expressions are quite different, but that is not visible in approximate values. |
One can also have a third problematic case:
|
|
The first result is given in exact mode, the second in approximate mode. |
What to retain of all that? The processing of the square roots is certainly problematic for all computer algebra systems. At the interior of the same software, it takes different forms according to whether one works with integers or letters and more generally with the symbols like p for example.
Specific algorithms apply in each situation; they are not always easily interpretable for the user.
|
|
p is thus assimilated to a letter, just like would be ln(5) or sin(1). Only integers (or the rationals) have a different processing. |
On the example above, one can think that the choices of the programmer have a teaching intention since, as one said it in the old problems of the BEPC, it often acts to make a denominator rational (and even integer), which supposes that the term placed under the root is rational or an integer.
There does not remain true about it than these choices can disturb the pupils in quite particular situations like those of the checking of a result. A true training is necessary, a good knowledge of the tool is essential.
Let us finish however on a " positive " report: it is necessary to make confidence to the computer when it analyzes like "true" an equality in exact mode. In all the other cases, that it regards it as false in exact mode, or for any response in approximate mode, it is better to be wary.
Rather general report besides in all the situations of symbolic calculation : even if it is not exactly in the form until we wait, the result that the computer (in exact mode) turns over is right.