Matlab Display gradient in elliptical tube

Já jsem dostal výsledek v příloze
(přidal jsem do kódu saveas(gcf,'test.png') abych to nemusel dělat ručně, místo gcf (get current figure) by asi posloužila proměnná fig když na to koukám)
ani elipsa to teni, natož aby byla vybarvená jako v tom obrázku. Zadání se mi louskat nechce, možná později.
Pokud se vykreslujou kruhy nebo elipsy, nebo třeba bitmapy, je potřeba přidat příkaz

axis equal

aby z kruhu nebyla placka totiž elipsa. Tady se to asi řeší nastavením velikosti, ale kolikrát jsem potřeboval odlišit, jestli je elipsa opravdová, nebo se jenom tak jeví ve figru a přesně na to to slouží.

V matlabu se výborně ladí kód tím, že se dá krokovat a sledovat, jestli se výsledek vyvíjí přesně podle představ. Navíc se tohle krokování dá kombinovat s příkazovým řádkem, takže je možné různé varianty zkoušet za pochodu a pak si z historie příkazů vybrat tu nejlepší.

Jak si v tom tak v mezičase listuju, chápu správně, že ta podmínka if control... na řádku 13 ohraničuje tu elipsu, tím že vně elipsy dává NaN zatímco uvnitř nějaké hodnoty?

Pokud ano, tak to nefunguje, NaN se nepřiřadí nikdy a tudíž se pokreslí celá plocha. Sem bych zaměřil pátrání.

Vůbec ta podmínka je divná, (teda pokud to chápu správně) jejím výsledkem má být matice a provádí se jen jednou, tam bude potřeba zvolit nějakou jinou strategii, přičemž dva vnořené cykly for by byly asi tím nejhloupějším, ale funkčním řešením (matlab má různé techniky, jak mu říct, aby něco provedl pro každý prvek pole, s ohledem na použití operátorů ./ .^ o řádek výš to asi tušíte).

Jak si tak s tím hraju, asi jsem opravdu na správné stopě. Výsledkem toho porovnání (Control(...)>1) je pole logických hodnot, které tvoří pěknou elipsu. Ta říká, kde májí být hodnoty a kde nehodnoty. Ovšem je potřeba tu akci přiřazení hodnoty nebo NaN provést extra pro každý prvek pole (if kupodivu nepracuje maticově a pole hodnot asi bere v součtu, když to vyhodnotilo jako jedno jediné true). Kdyby šlo o nahrazení nulou, stačilo by to vynásobit element wise ( .* ), ale jestli tam má být NaN tak se bude muset použít jiná finta.

Ono tam asi bude ještě něco dalšího kromě tohoto "ořezu", protože obdržené obrázky nevypadají jako ty vzorové.

Nedalo mi to, a vyzkoušel jsem to s tím cyklem (řádky 15-30 obrázku v příloze), už je tam ten efekt eliptické trubky. Pořád si myslím, že bude existovat lepší řešení než ty explicitní cykly, mám takovou zkušenost, že pokud se nechá cyklus na matlabu (tzv. implicitní cyklus) je to řádově rychlejší (i když tady to bude úplně jedno). Nedávno jsem dělal nějaký celkem jednoduchý výpočet pro 10 milionů hodnot, s explicitním cyklem byl za tři dny v půlce, když se to napsalo bez něj (on tam implicitně je taky, pokud napíšete např. a+b a obojí jsou matice, musí někde uvnitř cyklus proběhnout, jen neni vidět) byl výpočet dílem okamžiku (řekněme 5-10 minut). Takový rozdíl mě překvapil, ale nenašel jsem tam žádný potenciální zádrhel, něco, co by ten cyklus zdržovalo.

Vypadá, že po zvolení správného typu grafu to bude ono, s tím už si hravě poradíte, pokud jde o 3D grafy, v tom se zas tak neorientuju, potřebuju to zřídkakdy, ale Matlab na to má obsáhlou nápovědu.