Tiedän että kukaan ei osaa auttaa :(

On tosiaan vaikee. Mutta itse aikanaan päättötyötä tehdessäni törmäsin OpenGL -nimiseen ohjelmointirajapintaan. Sieltä voisi lähteä manuaalien avulla etsimään mahdollista ratkaisua. Toinen keino on kylmästi etsiä jostain vertaisverkosta vastaava ohjelma ja palautta se, sekä kertoa, miten lähdekoodit ovat vain joutuneet hukkaan

Auttaa miestä mäessä kirjoitti:

On tosiaan vaikee. Mutta itse aikanaan päättötyötä tehdessäni törmäsin OpenGL -nimiseen ohjelmointirajapintaan. Sieltä voisi lähteä manuaalien avulla etsimään mahdollista ratkaisua. Toinen keino on kylmästi etsiä jostain vertaisverkosta vastaava ohjelma ja palautta se, sekä kertoa, miten lähdekoodit ovat vain joutuneet hukkaan

Lue lisää

...niin tuollaisen ohjelman voi ostaa hyvin varustelluista tietokonekaupoista. Markkinoilla on eräs Java-toteutuskin, mutta se toimii vain Windowsin Professional-versioissa ongelman vaativan luonteen takia.

Yleensä nämä myydään samassa hyllyssä kuin CAD-ohjelmat. Lisenssen hinnat lähtevät noin kymmenestä tuhannesta euroista per prosessori. Halvimmat versiot eivät osaa käyttää virtuaalimuistia, joten niillä ei voi laskea kovin suurien ympyröiden pinta-aloja tai kehien pituuksia.

Vuoden alusta on tullut valikoimaan myös nopeusoptimoidut versiot, joille voi täytyy halkaisijan sijaan syöttää ympyrän säde. Nämä versiot laskevat kehän pituuden aavistuksen verran halkaisijaan pohjautuvia hitaammin, mutta hakkaavat mömmöt ulos niistä, kun mitataan pinta-alan laskentanopeutta.

Minkä ikinä ostatkin, valitse eurooppalainen versio. USA:ssa piin arvo on nimittäin noin 0,005926535897932384626 hpk (halkaisijaa per kehä) pienempi kuin Euroopassa.

(DI) S. Formation kirjoitti:

...niin tuollaisen ohjelman voi ostaa hyvin varustelluista tietokonekaupoista. Markkinoilla on eräs Java-toteutuskin, mutta se toimii vain Windowsin Professional-versioissa ongelman vaativan luonteen takia.

Yleensä nämä myydään samassa hyllyssä kuin CAD-ohjelmat. Lisenssen hinnat lähtevät noin kymmenestä tuhannesta euroista per prosessori. Halvimmat versiot eivät osaa käyttää virtuaalimuistia, joten niillä ei voi laskea kovin suurien ympyröiden pinta-aloja tai kehien pituuksia.

Vuoden alusta on tullut valikoimaan myös nopeusoptimoidut versiot, joille voi täytyy halkaisijan sijaan syöttää ympyrän säde. Nämä versiot laskevat kehän pituuden aavistuksen verran halkaisijaan pohjautuvia hitaammin, mutta hakkaavat mömmöt ulos niistä, kun mitataan pinta-alan laskentanopeutta.

Minkä ikinä ostatkin, valitse eurooppalainen versio. USA:ssa piin arvo on nimittäin noin 0,005926535897932384626 hpk (halkaisijaa per kehä) pienempi kuin Euroopassa.

Lue lisää

Piin arvo jenkeissä vain tuon verran pienempi?! Mulla nyt sitten meni pohja koko oman yrityksen toiminnalta. Mä kun olin täysin siinä käsityksessä että jenkit lähtisivät toteuttamaan piin tulkintaa Raamatun pohjalta ja julistaisivat sen arvon olevan tasan kolme. Meillä oli tarkoitus iskeä tähän markkinarakoon tulevaisuudessa; yksikään nykyinen markkinoilla järjestelmä ei osaa hallita tilannetta jossa piin arvo onkin kolme.

Meidän yrityksellä oli tosiaan tarkoitus tehdä kevyempi versio ympyrän kehän laskentajärjestelmästä, joka soveltuu kansainväliseen toimintaan... mutta nyt sitten homma kasahti tuohon! :( Miten ihmeessä me voidaan selittää Tekesille ja muille rahoittajille että tuli tehtyä tämmöinen kupru...

Mutta tuo laskentatehon vaatimukset on ihan totta. Meillä on onneksi ollut mahdollisuus käyttää top500 listalta löytyvää kahta palvelinjärjestelmää meidän oman ohjelmistoarkkitehtuurin testaamiseen.

Tuo on kyllä ihan mielenkiintoinen idea käyttää sädettä halkaisijan sijaan. Olisiko sinulla jotain tutkimustuloksia aiheesta? Tai olisiko mahdollista käyttää halkaisijaa laskettaessa sädettä ja pinta-alalaskussa sädettä? Siinä tapaukessa pitäisi vaan kehittää jokin tarpeeksi tehokas algoritmi jolla selvitetään haluaako käyttäjä säteen vai halkaisijan.

Vielä on tosiaan paljon tutkittavaa kehän pituus ja pinta-alalaskentatieteessä. Kyllä olen tyytyväinen että tajusin erikoistua hajautettujen järjestelmien sijaan tähän!

Nimimerkki kirjoitti:

Piin arvo jenkeissä vain tuon verran pienempi?! Mulla nyt sitten meni pohja koko oman yrityksen toiminnalta. Mä kun olin täysin siinä käsityksessä että jenkit lähtisivät toteuttamaan piin tulkintaa Raamatun pohjalta ja julistaisivat sen arvon olevan tasan kolme. Meillä oli tarkoitus iskeä tähän markkinarakoon tulevaisuudessa; yksikään nykyinen markkinoilla järjestelmä ei osaa hallita tilannetta jossa piin arvo onkin kolme.

Meidän yrityksellä oli tosiaan tarkoitus tehdä kevyempi versio ympyrän kehän laskentajärjestelmästä, joka soveltuu kansainväliseen toimintaan... mutta nyt sitten homma kasahti tuohon! :( Miten ihmeessä me voidaan selittää Tekesille ja muille rahoittajille että tuli tehtyä tämmöinen kupru...

Mutta tuo laskentatehon vaatimukset on ihan totta. Meillä on onneksi ollut mahdollisuus käyttää top500 listalta löytyvää kahta palvelinjärjestelmää meidän oman ohjelmistoarkkitehtuurin testaamiseen.

Tuo on kyllä ihan mielenkiintoinen idea käyttää sädettä halkaisijan sijaan. Olisiko sinulla jotain tutkimustuloksia aiheesta? Tai olisiko mahdollista käyttää halkaisijaa laskettaessa sädettä ja pinta-alalaskussa sädettä? Siinä tapaukessa pitäisi vaan kehittää jokin tarpeeksi tehokas algoritmi jolla selvitetään haluaako käyttäjä säteen vai halkaisijan.

Vielä on tosiaan paljon tutkittavaa kehän pituus ja pinta-alalaskentatieteessä. Kyllä olen tyytyväinen että tajusin erikoistua hajautettujen järjestelmien sijaan tähän!

Lue lisää

Solfwramin lupaama miljoonapalkinto houkutteli meidän tutkimusryhmämme pahamaineisen säteen ja halkaisijan ongelman pariin. Jos toisen perusteella voisi ratkaista toisen, olisi välittömästi mahdollista tehdä alkuperäisen kysyjän haaveilema sovellus, joka laskisi polynomiaalisessa ajassa samalle ympyrälle sekä kehän että pinta-alan vain yhden parametrin perusteella. Sovellusmahdollisuudet olisivat valtavat, mutta varjopuolena kummitteli se, että löytö veisi pohjan internetissä yleisesti käytetyistä kryptografisista algoritmeista (ymmyrkäisillä käyrillä salatut viestit olisi purettavissa silmänräpäyksessä).

Huomasimme kuitenkin nopeasti ongelman vaikeuden. Säteen ja halkaisijan väliin jäävästä kulmasta johtuva vapausaste teki upotti nopeasti haaveemme analyyttisestä ratkaisusta. Kylmälaboratoriossa suoritetut mittaukset auttoivat meitä vähän eteenpäin ja havaitsimme kulman kvantittuneen luonteen (raportoitu alunperin Mature-lehdessä 1999, ennen kuin y2k muutti M:n N:ksi). Seinä nousi kuitenkin lopullisesti vastaan tutkiessamme säteen ja halkaisijan käyttäytymistä ympyrän keskipisteen lähellä (Uno Eight-Zeron paradoksi).

Pyyhkäisyelektronimikroskoopilla saadut kuvat nimittäin osoittivat säteiden lähtevän keskipisteestä lähes joka suuntaan (kulman kvantittumisen takia mahdollisia suuntia ei tietenkään ole loputtomasti), mutta aina pois päin keskipisteestä. Sen sijaan halkaisija, joka teoriassa lävistää pistemäisen keskikohdan, on jaettavissa kahteen osaan. Toinen osista käyttäytyy kauniin sädemäisesti, mutta toinen osa, jota kutsumme antisäteeksi, tuleekin keskipisteeseen ulkokehältä päin! Antisäteen ja säteen välinen kulmakaan ei tottele empiirisin kokein löydettyä kulmakvanttia, vaan se on absoluuttisessa nollapisteessä tasan 180 astetta. Kulmakvantin takia sen olisi pitänyt osua 180,0059265358979 asteeseen tai johonkin muuhun sen lähimpään Sröd Ringin aaltofunktion huippukohtaan.

Nyt tutkimusryhmämme on hajallaan sekä henkisesti että fyysisesti. Raskaimmin paradoksin järkyttämät jäivät kiertelemään kuka Wieniin, kuka Haminaan. Itsekin olin ajautua kehä 3:lle, mutta rannalle päästyäni tulin järkiini ja palasin Tampereelle.

En ymmärrä, enkä enää haluakaan ymmärtää, millaista approksimointia nuo mainitsemani sovellukset käyttävät ratkaistessaan kehää ja pinta-alaa pelkästään halkaisijan (ja uusimmat säteen) avulla. Ja kehoitan muitakin ummistamaan silmät, painamaan nappia ja uskomaan tietokonetta. Minäkin olen viimeaikoina katsellut mieluummin hajautettujen järjestelmien suuntaan.

Kieltämättä aika hauskojen huumorin kukkien jälkeen: muistele yläasteen matematiikkaa. Ilmeisesti osaat Java-toteutuksen muilta osin :)

Vaikka ongelma voikin vaikuttaa yksinkertaiselta, on se syytä ratkaista huolellisesti.

Ensimmäiseksi on tutustuttava tapaan, jolla tietokoneet esittävä lukuja eli liukulukuihin. Koska tietokoneissa on aina rajallinen muistin määrä, ei niillä voida esittää kaikkia reallilukuja (joita on ylinumeroituvasti). Jo tästä seuraa, että tehtävää ei voi ratkaista täsmällisesti.

Toiseksi laskuissa voi esiintyä esim. katkaisuvirheitä. Kannattaa tutustua myös siihen, mitä IEEE-standardi sanoo pyöristyksistä.

Kolmanneksi tai ehkäpä ihan ensimmäiseksi voisi tutustua Peter R. Turnerin kirjaan Guide to Scientific Computing. Kirja on selkeästi kirjoitettu eikä vaadi lukiomatematiikkaa syvällisempiä taitoja, jotta siitä voisi nauttia.

Näiden taustatietojen hankkimisen jälkeen voi ryhtyä tarkastelemaan lähemmin yllä esitettyä ongelmaa.

lukion opettaja kirjoitti:

Vaikka ongelma voikin vaikuttaa yksinkertaiselta, on se syytä ratkaista huolellisesti.

Ensimmäiseksi on tutustuttava tapaan, jolla tietokoneet esittävä lukuja eli liukulukuihin. Koska tietokoneissa on aina rajallinen muistin määrä, ei niillä voida esittää kaikkia reallilukuja (joita on ylinumeroituvasti). Jo tästä seuraa, että tehtävää ei voi ratkaista täsmällisesti.

Toiseksi laskuissa voi esiintyä esim. katkaisuvirheitä. Kannattaa tutustua myös siihen, mitä IEEE-standardi sanoo pyöristyksistä.

Kolmanneksi tai ehkäpä ihan ensimmäiseksi voisi tutustua Peter R. Turnerin kirjaan Guide to Scientific Computing. Kirja on selkeästi kirjoitettu eikä vaadi lukiomatematiikkaa syvällisempiä taitoja, jotta siitä voisi nauttia.

Näiden taustatietojen hankkimisen jälkeen voi ryhtyä tarkastelemaan lähemmin yllä esitettyä ongelmaa.

Lue lisää

tarvitsen apua nyt koska työt palautetaan kohta ja jos ei ole valmiina niin kurssista hylsy ja sitä en halua,joten siksi kysyin täältä apua.

tarvitsen apua nyt kirjoitti:

tarvitsen apua nyt koska työt palautetaan kohta ja jos ei ole valmiina niin kurssista hylsy ja sitä en halua,joten siksi kysyin täältä apua.

Hylsyä odotellessa. Onneksi olkoon.

tarvitsen apua nyt kirjoitti:

tarvitsen apua nyt koska työt palautetaan kohta ja jos ei ole valmiina niin kurssista hylsy ja sitä en halua,joten siksi kysyin täältä apua.

[email protected]

lukion opettaja kirjoitti:

Vaikka ongelma voikin vaikuttaa yksinkertaiselta, on se syytä ratkaista huolellisesti.

Ensimmäiseksi on tutustuttava tapaan, jolla tietokoneet esittävä lukuja eli liukulukuihin. Koska tietokoneissa on aina rajallinen muistin määrä, ei niillä voida esittää kaikkia reallilukuja (joita on ylinumeroituvasti). Jo tästä seuraa, että tehtävää ei voi ratkaista täsmällisesti.

Toiseksi laskuissa voi esiintyä esim. katkaisuvirheitä. Kannattaa tutustua myös siihen, mitä IEEE-standardi sanoo pyöristyksistä.

Kolmanneksi tai ehkäpä ihan ensimmäiseksi voisi tutustua Peter R. Turnerin kirjaan Guide to Scientific Computing. Kirja on selkeästi kirjoitettu eikä vaadi lukiomatematiikkaa syvällisempiä taitoja, jotta siitä voisi nauttia.

Näiden taustatietojen hankkimisen jälkeen voi ryhtyä tarkastelemaan lähemmin yllä esitettyä ongelmaa.

Lue lisää

Mielestäni liukulukujen esitystapaan ja IEEE-754:ään tutustuminen ohjelmoinnin opiskelun alkuvaiheessa on hyvä ajatus vain siinä tapauksessa, että haluaa tappaa motivaation ohjelmoinnin opiskeluun heti alkuunsa. Alkuperäisellä kysyjällä ei tosin tainnut olla motivaatiota edes tapettavaksi, joten vahinkoa tuskin pääsi tapahtumaan.

Ohjelmoinnista on mahdollista ja tärkeää saada onnistumisen elämyksiä ja sitä kautta sytyttää into oppia lisää. Ohjelmoijan tiellä on vain muutamia miinoja, joista yhden muodostavat IEEE:n liukumii... liukuluvut.

Standardia tuntematon ohjelmoija pärjää hyvin niin pitkään, kun hän ymmärtää karttaa floatteja ja doubleja kuin ruttoa. Esimerkiksi se, että luvun esityksessä on desimaalierotin, kuten usein esimerkiksi tuotteiden hinnoissa, ei vielä tarkoita, että luku olisi liukuluku. Hinnoissahan tuo desimaalierotin ei ole liukuva (engl. floating point), vaan kiinteä (fixed point). Kaupassa se erottaa yleensä kaksi (no, polttoaineen tapauksessa kolme) viimeistä lukua kokonaisista euroista. Jos siis yksiköksi otetaankin sentin kymmenesosat, kauppojen hinnat ovatkin kokonaislukuja.

Kokonaislukutyypit ovat enimmäkseen mukavia, niitä kannattaa suosia. Kokonaislukuja voi laskea yhteen ja niitä voi järkevästi verrata vielä yhteenlaskun jälkeenkin. Liukuluvut eivät ole sellaisia. IEEE:n standardin mukaan laskiessa esimerkiksi 0,1 0,1 0,1 ei ole 0,3, vaan vähän enemmän. Kokeile itse:

System.out.println(0.1d 0.1d 0.1d > 0.3d);

Doubleilla virhe on luonnollisesti pienempi kuin floateilla. Seuraava rivi tulostaa myös "true":

System.out.println(0.1d 0.1d 0.1d < 0.1f 0.1f 0.1f);

Javassa liukulukujen kanssa pitää olla vieläkin tarkempana kuin useimmilla muilla ohjelmointikielillä. Ohjelma saattaa jakaa jopa luvun nollalla antamatta minkäänlaista virheilmoitusta. Kuka arvaa, mitä seuraava ohjelma tulostaa:

class Hello {

public static void main(String[] args) {

float nolla1 = 0.0f;

double nolla2 = 0.0d;

int nolla3 = 0;

int i = 44 (int)(1.0f/nolla1) (int)(2/nolla2) (int)(3.0d/nolla3) * (int)(0/nolla1);

System.out.println(i);

}

}

Liukuluvut ovat epätarkkoja ja jopa niiden laskentajärjestyksellä voi olla merkittäviä vaikutuksia tulokseen. Pysykää kaukana niistä.
(Ehkä havaitsemamme kulman kvantittuminen olikin softavika kylmälaboratorion laitteissa... ;)

Vain päälle 2w vanha topikki...

hei haloo kirjoitti:

Vain päälle 2w vanha topikki...

eikä vieläkään valmista vastausta, huono palsta :(

hopi. kirjoitti:

eikä vieläkään valmista vastausta, huono palsta :(

En nyt lukenu threadia ollenkaan, mutta nopeella googletuksella ja viikon ohjelmointikokemuksella:

import static java.lang.Math.PI;
import java.lang.Math.*;
import java.io.*;
import java.util.*;



public class ympyrälaskentaa {

public static void main(String args[]) {


System.out.println("Mikä on ympyrän säde?");
Scanner kysytäänsädettä = new Scanner(System.in);
int säde = kysytäänsädettä.nextInt();

System.out.println("metriä? dm? cm? mm?");
Scanner kysytäänyksikköä = new Scanner(System.in);
String yksikkö = kysytäänyksikköä.nextLine();

double kehä = säde * PI;

double sädePintaalaan = Math.pow(säde,2);
double pintaAla = sädePintaalaan * PI;

System.out.println("kehä: " kehä yksikkö);
System.out.println("pinta-ala: " pintaAla yksikkö "^2");
}

}

pööads kirjoitti:

En nyt lukenu threadia ollenkaan, mutta nopeella googletuksella ja viikon ohjelmointikokemuksella:

import static java.lang.Math.PI;
import java.lang.Math.*;
import java.io.*;
import java.util.*;



public class ympyrälaskentaa {

public static void main(String args[]) {


System.out.println("Mikä on ympyrän säde?");
Scanner kysytäänsädettä = new Scanner(System.in);
int säde = kysytäänsädettä.nextInt();

System.out.println("metriä? dm? cm? mm?");
Scanner kysytäänyksikköä = new Scanner(System.in);
String yksikkö = kysytäänyksikköä.nextLine();

double kehä = säde * PI;

double sädePintaalaan = Math.pow(säde,2);
double pintaAla = sädePintaalaan * PI;

System.out.println("kehä: " kehä yksikkö);
System.out.println("pinta-ala: " pintaAla yksikkö "^2");
}

}

Lue lisää

Ja kyllä: "double pintaAla = sädePintaalaan * PI;"
siinä käytetty väärää termiä. mutta tekee kuitenkin asiansa ^^

"kaavat:
kehä=halkaisija * PII
pinta-ala = PII * halkaisija potenssiin 2 "

pinta-ala = PII * SÄDE potenssiin 2, säde on taas halkaisija/2..