Bug for command Max[Function f, Number a, Number b]

Min-Ho shared this problem 3 years ago
Not a Problem

Problem description: The command Max[Function f, Number a, Number b] should give the maximum point for function f between a and b. It doesn't always do that, in fact it behaves strangely at times. See "steps to reproduce bug" below for an example.

OS: Windows 10 Education, version 1809, installed 2019-02-21, build 17763.737

Java version: 8 update 221 (build 1.8.0_221-b11)

Steps to reproduce bug (or open the attached file and go to step 5):

1) Make function f(x)=x^3-x^2

2) Make sliders a and b.

3) Enter command "A=max(f,a,b)".

4) Set a=0.2 and b=1.1.

5) Point A should be at (1.1, 0.121) but instead is found at (0.2, -0.03). When the slider a is set to a=0.3, point A jumps to the expected value.

Similar problem with command Min[Function f, Number a, Number b].

Comments (6)


In Denmark you should set a a=-0.2 and ask for: Ekstremum(f,a,b).

I don't know the english command.

It will give you Minimum and maximum.


It seems like it generally "fails" at a, if you use Max() to find a minimum or Min() to find a maximum.

Who is to blame?


The conditions on when it works are quite strict, see https://wiki.geogebra.org/e...


but condition is rigth so I have a question: does max(f,a,b) calculate local maximum or absolute maximum?

Calculates (numerically) the local maximum point of the function in the given interval. The function should be continuous and have only one local maximum point in the interval.
I sometimes use this trick

Files: foro.ggb

Excellent, thanks for the trick! It's a nice workaround.

I'd think that the "uppersum" command would somehow make use of "max", so it seems a bit backwards to me. I'd still like the "max" and "min" commands to work properly, though...


Thanks for your comments, much appreciated.

I might not have been completely clear on the problem, so I've made a quick video to show what I mean: http://youtu.be/W7SDONIh8VY?hd=1. There's no sound on the video, but the problem should be clear anyway. Notice the unexpected behaviour around 00:54 and 1:03. I used a different function to show that the problem is general.

© 2023 International GeoGebra Institute