I'm experiencing a possible bug with Find Root in the Function app.

(Firmware version 2021 10 01)

Specify 3rd grade polynomial function

[

attachment=9915]

Set plot screen intervals

[

attachment=9916]

Show plot

[

attachment=9917]

Find root

[

attachment=9918]

Wrong root

[

attachment=9919]

Surely this cannot be right?

I understand that the minimum found is the closest thing to finding the root within this window, but I'd prefer a message "No root found" rather than the current solution.

Hello Stephan,

you simply must use a better starting point, select one to the right of the maximum and it will give you 12.437..., which is provided by zeros() from the Toolbox without plot.

HTH Arno

I'm aware that there are better ways to find roots of a function. For once, by making sure that roots are visible in de plot screen.

My issue is that a misleading result is given here.

I would argue that this may be a bug or something to be taken up as an enhancement.

[

attachment=9920]

[

attachment=9921]

Only when the cursor is at a slope wherein the root lies, it is actually properly found.

This helps me understanding the underlying algorithm and also helps my explaining things to my students.

But it still feels strange to me that when i issue a command Find root, that the calculator chooses to give me an extreme as a result. That's confusing to me and for sure for students who are trying to figure out how to work with a graphic calculator.

Things could be made more clear, e.g. by simply saying: No root found!

Well, you're right, it should say: No solution. But at least it is the same behaviour as my 50G shows when I solve this equation, so I am used to it and I think this even is explained in one of the manuals

Arno

(10-15-2021 03:20 PM)Arno K Wrote: [ -> ]But at least it is the same behaviour as my 50G shows when I solve this equation,

An error message indicating that you gave it a "bad initial guess" would be better, but at least the Prime tells you that it found an "Extremum" rather than a root. The 50g actually labels this incorrect point as a "Root".

On the 84+, a bad initial interval produces the error message: "ERROR: NO SIGN CHANGE" which probably isn't much help to a student who doesn't understand the basics of searching for roots.

The Nspire probably has the clearest error message: "Error: No zero found within the specified bounds."

On the Prime, the help screen says, "Root: find the root of the current function that is closest to the tracer". So perhaps the error message should say something like: "No root found near the tracer."

Example, F1(X) = X^2 - 2*X + 1

Depending on initiial guess around X=1, you might get root = 1, or extremum = 1

I would think returning extremum = 1 is better than "no root found"

(10-16-2021 01:59 PM)Albert Chan Wrote: [ -> ]I would think returning extremum = 1 is better than "no root found"

True, though it does seem like the solver should check to see if the extreme it found is actually a root.

(10-16-2021 01:31 PM)Wes Loewer Wrote: [ -> ] (10-15-2021 03:20 PM)Arno K Wrote: [ -> ]But at least it is the same behaviour as my 50G shows when I solve this equation,

An error message indicating that you gave it a “bad initial guess” would be better, but at least the Prime tells you that it found an “Extremum” rather than a root. The 50g actually labels this incorrect point as a “Root”.

Yes; when I was implementing this bit of the UI for the 39gII, I suggested the change in labeling. (To specifically call out that the root finder is returning an extrema.)

(10-16-2021 01:59 PM)Albert Chan Wrote: [ -> ]Example, F1(X) = X^2 - 2*X + 1

Depending on initiial guess around X=1, you might get root = 1, or extremum = 1

I would think returning extremum = 1 is better than “no root found”

Another example would be F1(X)=SIN(X)^2. From a floating-point perspective, what the numerical routines will generally (for X near non-zero multiples of π) observe is near misses (of zero) - extrema (minima, in this case).

(10-15-2021 02:23 PM)StephanP Wrote: [ -> ]Only when the cursor is at a slope wherein the root lies, it is actually properly found.

This helps me understanding the underlying algorithm and also helps my explaining things to my students.

But it still feels strange to me that when i issue a command Find root, that the calculator chooses to give me an extreme as a result. That’s confusing to me and for sure for students who are trying to figure out how to work with a graphic calculator.

Things could be made more clear, e.g. by simply saying: No root found!

There certainly are a few possible improvements that could be made here.

I, too, was surprised by the 39gs’s behaviour when I first encountered it (while implementing the Function app for the 39gII). While it may be obvious to us that a reported extrema is not a root, the root finding routine is unaware of the vertical scale of the plot. Where a root may exist if real arithmetic is used for evaluation, there may only be nearby extrema when floating-point arithmetic is used for evaluation. (Just a bit earlier, I gave the example of F1(X)=SIN(X)^2; there will generally be local non-zero minima near non-zero integer multiples of π for this function when viewed through a floating-point lens.)

Nothing is wrong with the HP50g:

Manual (AUR) explains ROOT:

"Root-Finder Command: Returns a real number xroot that is a value of the specified variable global for which the specified program or algebraic object most nearly evaluates to zero or a local extremum.