Moro,
Olen tekemässä ohjelmistokomponenttia, jonka tehtävänä on näyttää kuvia vieritettävässä listassa (vain tietty osa kuvista näkyy kerrallaan). Olen toteuttanut komponenttiin suurennustoiminnon siten, että mitä lähempänä komponentin keskikohtaa kuva on, sitä suurempana kuva näytetään. Käytännössä siis kerron keskenään suurennuskertoimen ja kuvan normaalikoon.
Olkoon suurennusfunktio f(x), missä x on etäisyys keskikohdasta (origosta). Ongelmana on laskea tietyn kuvan etäisyys keskipisteestä ottaen huomioon tämän suurennusfunktion vaikutuksen etäisyyden muutokseen. Tätä tarvitaan, kun halutaan siirtää tietty kuva keskelle komponenttia.
Olen järkeillyt asiaa siten, että käytännössä kuva kulkee kohti keskipistettä funktion f(x) käyrää pitkin. Yliopistomatikasta muistan sen verran, että käyrän pituutta kahden pisteen välillä voidaan approksimoida integraalin avulla siten, että dx ~ integraali a,b sqrt( x'(t)^2 y'(t)^2 ), missä siis funktio on määritelty parametrimuodossa.
Onko tähän olemassa jotain järkevämpää tapaa, sillä minun tapauksessani funktio on muotoa f(x) = a * cos( pi/2 * (x / b)), ja tuosta tulee sen verran härski lauseke, etten osaa tuota aukaista. Tietysti johonkin näppärään koordinaatistoon siirtyminenkin varmasti helpottaisi, mutta pää on niin jumissa, ettei oikein enää rahkeet riitä :) Onko lähestymistapani ylipäätään oikea? Olisin kiitollinen kaikesta avusta!
Olen tekemässä ohjelmistokomponenttia, jonka tehtävänä on näyttää kuvia vieritettävässä listassa (vain tietty osa kuvista näkyy kerrallaan). Olen toteuttanut komponenttiin suurennustoiminnon siten, että mitä lähempänä komponentin keskikohtaa kuva on, sitä suurempana kuva näytetään. Käytännössä siis kerron keskenään suurennuskertoimen ja kuvan normaalikoon.
Olkoon suurennusfunktio f(x), missä x on etäisyys keskikohdasta (origosta). Ongelmana on laskea tietyn kuvan etäisyys keskipisteestä ottaen huomioon tämän suurennusfunktion vaikutuksen etäisyyden muutokseen. Tätä tarvitaan, kun halutaan siirtää tietty kuva keskelle komponenttia.
Olen järkeillyt asiaa siten, että käytännössä kuva kulkee kohti keskipistettä funktion f(x) käyrää pitkin. Yliopistomatikasta muistan sen verran, että käyrän pituutta kahden pisteen välillä voidaan approksimoida integraalin avulla siten, että dx ~ integraali a,b sqrt( x'(t)^2 y'(t)^2 ), missä siis funktio on määritelty parametrimuodossa.
Onko tähän olemassa jotain järkevämpää tapaa, sillä minun tapauksessani funktio on muotoa f(x) = a * cos( pi/2 * (x / b)), ja tuosta tulee sen verran härski lauseke, etten osaa tuota aukaista. Tietysti johonkin näppärään koordinaatistoon siirtyminenkin varmasti helpottaisi, mutta pää on niin jumissa, ettei oikein enää rahkeet riitä :) Onko lähestymistapani ylipäätään oikea? Olisin kiitollinen kaikesta avusta!
Vastaukset 12
Vanhimmat
Parametrimuotoon vieminenkö oli kompastuskivi? Voithan käyttää käyrän y = f(x) kaarenpituuden kaavan toista muotoa:
integraali a:sta b:hen funktiosta (sqrt{1 [f'(x)]^2}),
jossa sqrt{...} on tietenkin neliöjuuri.
Moi,
Ei ollut varsinaisesti ongelma, vaan ko. integraalin ratkaiseminen. Neliöjuuren sisällä olevat toisen potenssin sinit eivät ole meikäläisen integrointitaidoilla ratkaistavissa.
Kiitos kuitenkin! Mietin tässä välissä jo, että olisiko vain järkevämpää lähteä approksimoimaan tuota matkaa jakamalla tuo käyrä n osaan ja laskemalla yksinkertaisesti pisteiden x_i ja x_i 1 väliin jäävän hypotenuusan pituus ja summaamalla nämä yhteen. Tämä olisi ainakin ratkaisu, jonka osaisin toteuttaa saman tien.
Niin no, eipä tuo integraali mitenkään herkulliselta näytä. Arvaan, ettei sitä edes voi esittää alkeisfunktioiden avulla. Eli approksimoi ihmeessä!
Ryhdyin asiaa muistelemaan ja vielä tarkistin muistelokseni eräistä lähteistä. Tuo käyränpituuden integraali tuottaa tosiaan toisen lajin elliptisen integraalin, jota ei voida esittää alkeisfunktioiden avulla.
Elliptiselle integraalille on sarjakehitelmiä, mutta minulla on huonoja kokemuksia tuollaisten sarjojen suppenevuudesta. Joissakin tapauksissa edes 50 termiä ei tuottanut kuin vain muutaman desimaalin tarkkuuden.
Toimivin ratkaisu on laskea integraali suoraan numeerisesti. Tosin noiden jaksollisten funktioiden numeerisessakin integroinnissa saa olla tarkkana, jotta saavuttaa kunnon likiarvon.
Ei se kyllä minusta ole elliptinen integraali: tässä on sinin kertoimen edessä plus siinä missä elliptisessä integraalissa olisi miinus. Ks. esim. http://mathworld.wolfram.com/EllipticIntegraloftheSecondKind.html .
Mutta ehkä sitten on olemassa muitakin elliptisen integraalin määritelmiä kuin tuo Mathworldissä oleva. Valaisisiko nimimerkki Ratkoja asiaa?
(Onko tällä elliptisyydellä sitten mitään väliä kenellekään? On minulle! Haluaisin tietää, voidaanko olla varmoja siitä, ettei tuo integraalifunktio ole alkeisfunktioin esitettävissä. Jos kyseessä olisi elliptinen integraali, ehkä niiden teoria vastaa kysymykseen. Jos ei ole elliptinen, niin ei varmaankaan vastaa. Joku tietäväinen voisi kertoa, miten asia on. Kiitos!)
En ole mikään matemaatikko, olen pelkkä matematiikan soveltaja, ja niissä yhteyksissä olen tullut tutuksi elliptisten integraalien kanssa.
Yksi selitys tietysti tuohon merkkiristiriitaan olisi se, että k^2 voisi olla negatiivinenkin, jolloin kyseessä olisi kompleksifunktio. Tarkistin asian muutamasta lähteestä ja siellä elliptinen integraali oli määritelty siten, että k^2
Tällainen integrointi on suoritettava laskettaessa satunnaisen suorakuolmion sisäpisteen etäisyys suorakulkion satunnaisesta reunapisteestä. Vai mitä?
> Ongelmana on laskea tietyn kuvan etäisyys
> keskipisteestä ottaen huomioon tämän
> suurennusfunktion vaikutuksen etäisyyden
> muutokseen. Tätä tarvitaan, kun halutaan
> siirtää tietty kuva keskelle komponenttia.
Hmmm.... en käsitä, mikä on ongelma. Etäisyyshän on juurikin aina se, mikä se kulloinkin on? Kun siirrät kuvaa i yhden pikselin kohti keskipistettä, niin kaikkien kuvien koot muuttuvat, mutta etäisyys tietenkin vain sen yhden pikselin verran? Pidät kaikkien kuvien etäisyyttä keskipisteestä jossain taulukossa ja päivitä sen kokonaa aina kun näkymään tulee muutos. Toisessa taulukossa sinulla on kunkin kuvan kulloinenkin koko, joka sekin päivittyy jokaisessa muutoksessa.
Sinun ei siis tarvitse ollenakaan laskea mitään ihmeellisiä etäisyyksiä. Pidät vain huolen siitä, että ko taulukot ovat jatkuvasti sen hetkisen tilanteen mukaisesti koneen muistissa!
Interpoloitaessa "sopivilla" kantafunktiolla (bezier, splinit, useimmiten parametrisointi tehdään käyrän pituuden suhteen ja mitäs vielä. No tärkein asia lienee, että parametrisointi on monotoninen kuvaus. Monesti juuri laskemalla käyrän pituus analyyttisesti voidaan osoittaa tietyn kantafunktiotyypin olevan sopiva ongelman interpolaatio-ongelman ratkaisemiseen. Samalla voidaan myös testata muitakin ominaisuuksia 'yleisesti', vaikkapa onko interpolaatiofunktio muodonsäilyttävä yms.) Ja niin edelleen... Olisiko nyt annettu liian vähän tietoja, mistä on kyse...?
yksinkertaistaa kuin monimutkaistaa ohjelmoitaessa. Silloin myös jatkokehittely on helpompaa.
1) Aloita tapauksesta, jossa kaikki ovat saman kokoisia ja tee siitä toimiva ohjelma.
2) Tämän jälkeen kehitä edellistä siten, että kyseinen dynaamisesti muuttuva koko toteutuu.
Olen melkein 100% varma, että et tarvitse kyseistä ihmefunktiota. Ohjelma ratkaisee sen sivulausekkeessa lennossa, kun se päivittää näyttöä. Se ilmeisesti päivittää asioita näytöllä heti, kun saa jotain palautetta ja samalla ratkoo etäisyysfunktion ihan vaan summaamalla loopissa...
Ohjelmoinnin I pääsääntö:
"KISS - Keep It Simple Stupid!"
Tosiaan hommahan toimii kuin rasvattu jos kuvat ovat saman kokoisia (tietysti tämän version tein ensin) ja silloin yksinkertaisesti riittää vähentää kuvan keskipisteen koordinaatti keskipisteen (senhetkisestä) koordinaatista.
Kuitenkin siinä vaiheessa, kun kuvia skaalataan tuon skaalausfunktion avulla (eli tässä tapauksessa esim. kosini), ei etäisyyttä voidakaan enää laskea suoraan - sen kulkema matka ei ole lineaarinen vaan se itseasiassa kulkee käyrää pitkin. Näin olen ainakin asian järkeillyt ja debuggauslauseilla todennut. En ole oikeastaan vieläkään päässyt puusta pitkälle ongelman ratkaisussa, mutta yritän tänään myöhemmin uudelleen, josko vihdoin saisin homman pelittämään. Ajattelin lähestyä ongelmaa nyt aluksi numeerisesti jakamalla kuljettavan matkan äärelliseen määrään "välietappeja" ja mittaamalla geometrisesti näiden etäisyyden summan.
Mutta tosiaan jos sinulla olisi heittää jotain ideaa siitä miten itse lähestyisit ongelmaa, olisin tietysti kiitollinen :)
Kiitos kaikille muillekin kirjoittaneille!
Tutkiskelin jälleen hetken tätä pulmaa ja pääsin hieman eteenpäin. Ongelma ei niinkään ole sittenkään ko. etäisyyden laskennan tarkkuudessa, vaan sille onnistun luomaan tarpeeksi hyvän likiarvon. Ongelmaksi muodostuu nyt se, että kun siirryn etäisyyden verran lineaarisesti ei tietysti ko. kuva siirry samaa määrää "avaruudessa", vaan luonnollisesti suuremman määrän. Nyt pitäisikin enää laskea, monenko pikselin verran pitää vierittää näkymää, kun tiedetään, että kuvan pitäisi siirtyä etäisyys dx.
Takaisin miettimään.