zoom dans le flocon de Koch

Rousseau-Wallon shared this question 2 years ago
Answered

Mettons qu'on a dessiné le flocon (ou une autre fractale) en profondeur 6, flocon visible entièrement dans la fenêtre GeoGebra.

Un tracé par itération.

On zoome sur (x,y).

est-il possible de tracer la partie du flocon vue par ce zoom, dans une profondeur dont le visuel est équivalent au premier tracé - c'est dire une profondeur supérieure - cela en limitant les itérations à la partie visible après ce zoom ?


cela a-t-il déjà été fait sur GeoGebratube ? J'ai fouillé mais je n'ai rein trouvé.

A mon avis c'est possible à condition de trouver la bonne approche

Comments (17)

photo
1

here is my first attempt. it needs more softness. I prefer to use MM (attachcopy) than corners and calculus.

photo
1

Ci-joint le fichier zoom infini manuel qui montre que ça doit être possible automatiquement.

1 - cliquez sur initialiser pour avoir le triangle équilatéral de départ (au besoin dézoomer pour le mettre au centre)

2 - cliquez sur fractaliser pour obtenir le flocon au niveau supérieur

3 - zoomez, déplacez la figure

4 - cliquez sur éliminer pour enlever de la liste les points hors écran

5 - recliquez sur fractaliser

(ne pas fractaliser si la longueur de la liste (voir menu algèbre) est supérieure à 1000, éliminer avant)

photo
1

voilà un second fichier avec zoom automatique

pour l'instant je gère mal les points hors-cadre

il est peut-être aussi possible de réduire les calculs


question : quel est le calcul qui donne la profondeur N du flocon à tracer pour que le rendu visuel soit stable, c'est à dire pour la longueur écran d'un côté du flocon ne varie pas trop ?

en fonction de xcoin1, xcoin2, ... xcoin5 et du côté du triangle équilatéral de départ (ici racine de 3)

je propose une valeur pour N qui marche pas trop mal mais peut-on faire un calcul exact ?


hum maintenant que ça fait deux jours que je suis dessus je sens qu'on va me dire qu'il y a un moyen bien plus simple de faire ce zoom, à l'image du tweet, impressionnant, de Zbynek pour dessiner le triangle de Sierpinski :

Compactée(Polygone(v),v,Itération(Unir(Compactée(Compactée((t+p)/2,p,t),t,p)),p, {{{(0,0),(5;0°),(5;60°)}}},5))

photo
1

Ci-joint le fichier zoom auto 2, plus de bug hors écran car j'ai modifié la définition de "liste" en mettant la commande GardeSi en dernier. Le problème c'est que la première liste calculée est plus longue, mais ça marche pas trop mal quand même, jusqu'à un zoom trop puissant.


J'ai partagé le flocon en trois, comme ça une seule liste de points est calculée, les autres sont déduites par rotation de 120° autour de l'origine.

Allez je vais me coucher

photo
1

voilà qui est mieux :smile:

ici on peut zoomer autant qu'on veut et l'affichage est instantané

j'ai du supprimé le javascript sur coin2 car j'ai créé un bouton INIT et je m'y suis sans doute mal pris ça m'a planté GeoGebra et je n'ai jamais pas pu réouvrir ma figure..

maintenant quand on ouvre GeoGebra il me semble que ça tient bien quand même, sans doute du fait que j'ai changé 2 3 paramètres pour zoomer, le réglage est ok

dans cette figure il y a fractalisation (passage au niveau supérieure du flocon) dès que la longueur-écran d'un côté du flocon dépasse 4 pixels, autant dire qu'on ne voit pas la transformation


pour le zoom out... je ne sais pas si c'est possible. Il faudrait garder la trace du zoom, une toute petite trace, mais laquelle et comment je ne sais pas

photo
1

amélioration du fichier :

- bouton init,

- affichage de la profondeur, du nombre de segments dessinés, et de la longueur-écran d'un de ces segments (c).

- simplification du calcul de cette longueur

- passage au niveau supérieur lorsque c > 3 pixels

Files: zoom.ggb
photo
1

Bonjour,

Je suis bien content d'avoir désormais le zoom OUT dans le flocon de Koch :smile:


jusqu'à une profondeur 9, après ça ralentit, il me semble à cause des calculs ? (pourtant la longueur des listes est assez petite)

je comprends mal le réglage de la "fenêtre" à l'extérieur de laquelle les points doivent être supprimés.

il faudrait que cette fenêtre s'adapte à la profondeur (au début il ne faut pas supprimer bcp de points, après si)

Je maîtrise mal les scripts GeoGebra, rien qui vous choque dans celui qui fonctionne par actualisation (objet "script") ?

photo
1

zomm in out en profondeur 10 avec fenêtre réduite indiquant la position du zoom

https://www.geogebra.org/m/yf6beybu

je pense qu'on peut faire bcp mieux (vitesse, profondeur) mais je vais en rester là

photo
1

on est bien là non ? merci rami & N. Lambert !

- problème du zoom < 1 réglé

- stabilisation de la mini fenêtre lors d'un zoom élevé

- dézoome désormais sans accoup : la condition complète pour que l'itération se fasse étant :

lnzoom > n_{old} ∨ n_{old} + 1> lnzoom

- bouclage du flocon par ajout de la commande "If(Element[L0,1]==X,SetValue(L0,Append(L0,X)))" dans kockL0 (un petit doute encore sur ça, mais je n'ai pas vu de bug)


j'ai mis un délai à l'ouverture (iniTimeOut) avec un javascript, c'est juste ?

Files: zoom.ggb
photo
1

merveilleux.

-------------------------------------------------- --------------------------------------


iniTimeOut:

GGB 5 a une erreur.

Je ne trouve pas de solution de contournement.

Seule cette version démarre sans erreur (dans GGB 5), tant que vous n'enregistrez pas l'applet.

Voir aussi:globales JS und Skript iniTimeOut onUpdate

.

À l'intérieur / à l'extérieur de Windows

Je pense que dans certains cas particuliers, tous les objets intérieurs ne sont pas correctement reconnus.

Voir l'applet ci-joint.

photo
1

J'ai modifié l'outil KOCH : il renvoie la liste des 4 derniers points du motif de base, et non pas les 5. Ce qui permet de se passer de la commande UNIQUE dans la définition de KochL0.

Il y a un (petit) moins de calculs donc, c'est toujours bon à prendre.

Et plus besoin non plus de "If(Element[L0,1]==X,SetValue(L0,Append(L0,X)))" dans kochL0.


De plus je crois que cette modification élimine aussi un bug : quand on zoomait (en profondeur 6 ou 7) sur l'intersection d'abscisse négative du flocon avec (Ox), la ligne brisée se... brisait. Un bug graphique je pense car une modification manuelle de la fenêtre au coin2 reconstituait la ligne. J'avais résolu ça en augmentant de 5% la fenêtre K.


Dans quels cas particuliers certains objets intérieurs ne sont pas reconnus ? Et quels objets ?

Comment ça, "tant que vous n'enregistrez pas l'applet" ?

photo
1

quote: "Dans quels cas particuliers certains objets intérieurs ne sont pas reconnus ? Et quels objets ?"

dans la nouvelle version, je ne peux pas reproduire cette erreur.


24863527a26d3e5567a3a9b03570710c

.

Quote: "Comment ça, "tant que vous n'enregistrez pas l'applet" ?"

mean not save.

Mais le bug n"existe pas dans la nouvelle version (zoom0211). Je ne comprends plus rien.

Je pense que supprimer Global JS et iniTimeOut (testé, il fonctionne sans erreur)

photo
1

Il ne m'étonnerait pas que la commande UNIQUE précédemment utilisée soit pour bcp dans ces bugs. La méthode de calcul des commandes GeoGebra est-elle expliquée quelque part ?

photo
2

On peut aller beaucoup plus vite !!

Lorsque on zoome beaucoup la vitesse ralentit à cause de la boucle Répéter N fois. Or il est inutile de tout recalculer à chaque fois (ce sont les mêmes calculs)(*). Seule la dernière itération doit être calculée (une nouvelle liste L(k+1) = kochL0[L(k)]. Un zoom in-out automatique et instantané est donc possible. Et je pense qu'on a même pas besoin de script.

(*) un déplacement de la fenêtre nécessitera cependant le recalcul d'un nombre suffisant de listes.

photo
1

ça donne la figure suivante

ça ralentit un peu quand même, plus tard que zoom 0211, mais là c'est à cause de la longueur de la dernière liste L(N), trop longue à cause du fenêtre de tri mal réglée.

et elle ne marche pas si on déplace trop la fenêtre, c'est forcé car les listes ne sont pas recalculées

photo
photo
1

Nouvelle amélioration : j'avais observé qu'en zoomant le côté du flocon dessiné avait tendance à devenir de plus en plus petit. Pourquoi ? Car les itérations se faisaient trop vite.

Mon zoom est défini par : (xmax - xmin) / (x(Coin(3)) - x(Coin(1))) (xmax et xmin sont constants, ce sont les valeurs initiales de la fenêtre).

Je faisait une nouvelle itération (c'est à dire un remplacement de chaque côté du flocon par le motif de Koch), lorsque la quantité entière Q = floor(ln(zoom)) passait à la valeur supérieure. Erreur ! Car quand on fait une itération le côté du flocon est divisé par 3, alors que Q change lorsque le zoom est multiplié par exp(1). C'était donc la quantité floor(ln(zoom)/ln(3)) qui donnait le signal, le logarithme de base 3 du zoom.

J'aurais au moins compris ça, car la taille de la fenêtre de tri m'échappe encore. Elle aussi doit bien être divisée par 3 à chaque itération, mais je ne comprends pas pourquoi la longueur de ma liste de points diverge légèrement quand on zoooooooome fort (j'ai affiché les points de cette liste qui sont visibles dans la fenêtre, on voit qu'ils représentent une toute petite partie de la liste, on peut donc faire beaucoup mieux).

Voilà un fichier zoom 0411 pas mal. Seule la dernière itération est calculée à chaque coup, mais cela n'empêche pas de dézoomer. Par contre, un déplacement de la fenêtre en cours d'un zoom peut éventuellement poser problème (si on se décale trop), car les première listes (une par itération) ne sont pas recalculées. D'où cette question : peut-on bloquer ce genre de déplacement tout en autorisant le zoom ?

photo
1

Bonjour,

Autre amélioration ce matin : plutôt que de prendre comme fenêtre de tri initial le carré de côté 2 centré sur l'origine, j'ai pris le cercle unité.

Gain théorique = [aire(carré) - aire (disque)]/aire(carré) = (4 - pi)/4 ≈ 21%.


Cette fenêtre je la divise par 3 à chaque itération et vers la profondeur 20 l'image se met souvent à trembler. On a alors x(coin(1)) presque égal à x(coin(2)).

C'est combien la précision de GeoGebra, 10^(-15) ?

On peut augmenter cette précision ?

© 2021 International GeoGebra Institute