is this a bug ?! incorrect position of X(506)

Anton Zakharov shared this question 1 month ago
Answered

I've been doing some amateurish 'research' on triangle centres and cubics.

To my amusement GeoGebra seems to think that X(7), X(506), X(507) is the exact same point ?!

I can be wrong, but it looks like a funny bug... Apparently GeoGebra command TriangleCenter(A, B, C, 7) shows X(7) absolutely correctly, but TriangleCenter(A, B, C, 506) and TriangleCenter(A, B, C, 507) both give the wrong result!

Comments (18)

photo
1

if you create a triangle ABC and apply

Setvalue(B,(0,0))

Setvalue(C,(9,0))

Setvalue(A,Intersect(Circle(B,6), Circle(C,13),1))

it can be seen that X(7), X(506), X(507) have the same coordinate, so that it must be the same point in the ETC

or something is wrong...

photo
1

According to the ETC

The first coordinate (of normalized trilinears) of X(7) evaluated at (a,b,c) = (9,13,6) is 0.79377171093999041241

For X(506) it mist be 1.37035254838230561916

For X(507) it must be 1.45019335404286626220

photo
1

If you're interested in helping check what might be wrong the code is here https://github.com/geogebra...


case 506:
return -((a + b - c) * (a - b + c) * p(a * (-a + b + c), 2 / 3));
case 507:
return -((a + b - c) * (a - b + c) * p(a * (-a + b + c), 3 / 4));

photo
2

he comprobado que estos (506 y 507) son los unicos que son iguales a otro de los centros que son calculados por GG

he revisado uno a uno mas de 200 textos p(.....), y he comprobado dentro de lo posible que 2/3 y 3/4 son los unicos numeros que aparecen en p(..... , 2/3) que son exponentes fraccionarios. los demás exponentes son naturales.

de eso deduzco, por la igualdad, que p(.....,2 / 3 ) y p(....., 3 / 4 ) son leídos como 1, o sea, exponente cero

no sé si deberían tener un parentesis como p(......, (2 / 3)) o evitar los espacios en blanco p(......, 2/3)

repito que son los unicos puntos en los que se usa el comando Math.pow con exponente fraccionario entre los casi 3000 puntos calculados


/A2A0xgGc01HMAAAAAElFTkSuQmCC

photo
2

Thanks, great detective work! Now I see the problem - in Java 2/3 and 3/4 are both zero (integer division) and they need to be changed to 2.0/3.0 and 3.0/4.0

photo
1

de nada

siento tanto no saber java

photo
1

@mathmagic: we've also had a bug report for X(600) - can you see what's wrong here?

case 600:
return a2 * (2 * a2 - a * b + 2 * b2 - 2 * c2)
* (2 * a2 - 2 * b2 - a * c + 2 * c2)
* (-(b2 * c2) + a2 * R);

photo
photo
1

X(600) equal to other or wrong?

the ETC says f(a,b,c) = a2 (bc + 2S) [abc(b + c - a) + 2(b2 + c2 - a2)S]


I must verify if the homogenus are equivalent. I can not to do today; tomorrow surely

photo
1

tienes una construccion del punto con el bug?

photo
1

Ah, looks like a mistake here

S = u((a + b + c) * (-a + b + c) * (a - b + c) * (a + b - c));
should be

S = u((a + b + c) * (-a + b + c) * (a - b + c) * (a + b - c)) / 2;
so that seems to give the right answer with your formula

photo
1

entonces hay que evaluar todos los centros que tienen S en su definicion?

además cambiar la definicion de S en GG no cambia la definicion de X(600), ¿o sí?

en ETC S es dos veces el area. en GG S es cuatro veces el area ¿debe ser S lo mismo en GG?

comprobaré otros centros que tengan S en su cuenta

si hay que modificar la definicion de X(600) pero los demás puntos con S en su definicion funcionan entonces habra que escribir f(a,b,c) = a2 (bc + 2S) [abc(b + c - a) + 2(b2 + c2 - a2)S] (dos doses quitados)

photo
2

un ejemplo es X(491)

bb383dffdefee8fd915ec1901741fc88

luego la formula correcta (si ETC no se equivoca) para X(600) es

a2* (b*c + S)* (a*b*c*(b + c - a) + (b2 + c2 - a2)*S) según la notación usada en GG

photo
1

Both problems fixed soon (v603 / v604)

photo
1

no están resueltos en 603

photo
1

v604 released now

photo
1

perfecto

cuando necesites un detective aquí estoy

photo
1

Thanks! :)

photo
© 2020 International GeoGebra Institute