numerikus matematikara gondolsz?
kozelitve elmeletileg nyilvan barmit, lasd epszilonhoz delta keresese anal I-en

[ Szerkesztve ]

Igen, még inkább egész számosra gondolok .

jaj :
lasd epszilonhoz delta keresese anal I-en
, ezt legjobb lesz ha te linkeled be nekem !

A gázt is és a féket is egyszerre nyomni nem menő dolog !

Ha elmondod mi a feladat, akkor jobban tudunk segíteni.
Mert az, hogy "egész számokra gondolok", és a sokadfokú+ad hoc az úgy nem annyira fog menni egyszerre reálisan nézve. Persze lehet ilyen mázlid, de valószínűtlen.

Leginkább arra számíthatsz ilyen módon, hogy még komplex gyökei is lesznek az egyenletnek.

Ha te magad akarsz olyan magas fokszámú egyenleteket, amiknek a megoldása egész, akkor inkább csináld fordítva. Szorozz össze olyan alacsonyabb fokszámúakat, amiknek ki tudod számolni (sőt, ránézésre látszik) a megoldását.

például (x+1)(x-4)(x^2-1)(x-3)(x+10)(x+4) = x^7 + 8 x^6 - 40 x^5 - 166 x^4 + 407 x^3 + 638 x^2 - 368 x - 480 = 0
Ránézésre látszanak a megoldások, hiszen akkor lesz nulla, ha a szorzat bármelyik tagja nulla: -1, 4, +-1, 3, -10, -4

[ Szerkesztve ]

Ha elmondod mi a feladat, akkor jobban tudunk segíteni.

Hiszen te magad mondtad el helyettem is :
például (x+1)(x-4)(x^2-1)(x-3)(x+10)(x+4) = x^7 + 8 x^6 - 40 x^5 - 166 x^4 + 407 x^3 + 638 x^2 - 368 x - 480 = 0

Pontosan ilyesmik érdekelnek ! - persze nem csak ez az 1 db kifejezés, hanem a többi hasonló általad le nem írtak is . Mit tudtok róluk ?

A gázt is és a féket is egyszerre nyomni nem menő dolog !

Ha tudsz angolul, [stackexchange link] érdekes lehet számodra. Én nem vagyok jártas a témában, de viszonylag gyorsan találtam választ “optimal integer polynomial factorization”-re keresve a googleben.

Már vége az Én hozzászólásomnak? Mi lesz ez után velünk?!?!

Nem tudom mennyire jó helyen van itt a kérdés, de a szegedi levelező matek bsc-ről vagy úgy a szegedi matekról tud valaki valamit?
Van, aki oda járt esetleg? Jó hely? Jól oktatnak?
A matek szakokkal kapcsolatban egész meglepően kevés információ van a neten
Mindenki antiszociális.

Ha nem érdekel a papír, akkor én az open MIT kurzusait ajánlanám. Fent vannak a videók, jegyzetek, házik, minden.

[ Szerkesztve ]

Sziasztok,

talán ide befér ez a feladat, ami kissé megrágta már az agyam
Van ezer kártyalapom, amiből 900-nak piros a hátulja, 100-nak kék. Mekkora a valószínűsége annak, hogy 50 vakon húzott kártyából:
a) 25-nél kevesebb lesz kék,
b) pont 25 lesz kék?
Minden segítséget köszönök

Ez egy hipergeometrikus eloszlás lesz.

N: 1000 - az összes darab szám
M: 100 - a speciális tulajdonságú elem darabszáma (kék)
n: 50 a kihúzott elemek száma
k: 25 és <25 - a keresett darabszám

Kezdjük azzal, hogy pont 25 darab lesz kék (k=25)
1, M alatt a k: Tehát kiválasztok 25 kéket a 100-ból, ezt 100 alatt a 25 féle képpen tehetem meg.
2, N-M alatt az n-k: Mellette még ki kell választanom a (N-M) 900-ból - (n-k) 25-t, ami 900 alatt a 25.
3, N alatt az n: 1000-ből 50 kártyát (N) 1000 alatt az (n) 50 féle képpen választhatunk ki.

Mivel itt az eredmények elég nagy számok. Sajnos a kombinatorikában a faktoriális az elég könnyen megszalad. Az eredmény ilyen 10^-14-en nagyságrendű. Gyakorlatilag mondható rá, hogy nulla.
[https://www.wolframalpha.com/input?i=hypergeometric+distribution+%5B50%2C+100%2C+1000%5D+x%3D25]

A várható érték E(X) = n * M/N = n * p = 50 * 100/1000 = 5
A szórást meg: D(X)~= 2

A 25 azért elég messze van az 5-től, annak meg elég kicsi az esélye, hogy messze legyünk a várható értéktől.

Csebisev becslése szerint annak a valószínűsége, hogy a várható értéktől való eltérésünk nagyobb egy bizonyos számnál, az kisebbegyenlő, mint a szórás négyzete osztva az eltérés (=bizonyos szám) négyzetével.
Tehát 2/20 a négyzeten, ami 4/400. Ez felső becslés, tehát 1% alatti. Tehát ez is oda mutat, hogy valóban szinte esélytelen 25-t(, vagy többet) kihúzni.

A kisebb, mint 25-t pedig úgy kellene csinálni, hogy P(X < x) = P(X=1)+P(X=2)...+P(X=24)
Mivel a várható érték 5, a szórás 2, és a 25 darab kihúzásának már szinte nulla esélye van, ezért a kisebb, mint 25 valószínűsége az már mondhatjuk, hogy 1.
(ugye a 25 és feletti esélye kvázi nulla, tehát megfordítjuk és mekkora 1-mekkora eséllyel húzunk többet, így 1-0=1)

De itt megcsodálható grafikonokon minden szépen:
[https://www.wolframalpha.com/input?i=hypergeometric+distribution+%5B50%2C+100%2C+1000%5D&key=v1j5e]

Sajnos nem tudom, hogy kinek is válaszolok, a válasz első fele a kombinatorikus, az talán megérhető simán gondolkodással, hogy miért olyan. Aztán a várható értéktől kezdve viszont már egyetemi matek. De a fogadó oldal ismeretének hiányában így tudtam elmagyarázni.

[ Szerkesztve ]

Köszönöm szépen!
Mondjuk, hogy ugatom a témát, így nagyjából tudtam követni a levezetést Az egyetlen, amit nem biztos, hogy értek, az a kisebb mint 25-nél a valószínűségek összeadása, hogy nem fogunk-e ott nagyon gyorsan egy egynél nagyobb számhoz eljutni az X=5, tehát a várható érték környékén (mármint az összeadás miatt)?

[ Szerkesztve ]

Közben kipróbáltam és nem Köszönöm még egyszer a választ!

Kipróbálás nélkül is adnia kell magát.
Ugye ha egymást kizáró események, akkor A bekövetkezésük valószínüségét összeadhatjuk.
Formálisabban, ha Ai metszer Aj = üres halmas, ha i=/=j, akkor a P(szumma Ai) = szumma P(Ai)

Elképesztően rosszul írok kávé előtt, bocsánat
Remélem a lényeg azért érthető.

Jogos, köszi

lásd #89
Ez arról szól, hogy a valóságot egy nagy matematikai kifejezésbe tehetjük ♥

Várom a véleményeteket róla ? - kritikusok kíméljetek .

A gázt is és a féket is egyszerre nyomni nem menő dolog !

Csak pozitiv velemenyt vars? indits blog-ot ott te moderalhatod a hsz-eket, itt nem...

... csak mert egyesek azt hiszik, hogy ha tudnak valami hibát találni a tudományos művekben, akkor okosabbak annál !

Persze te mondhatsz bármilyen véleményt .

A gázt is és a féket is egyszerre nyomni nem menő dolog !

https://erdosattilask01.lapunk.hu/primszam-listaz-1213491

Egy új weboldalam, amivel prímszámos egyenleteket lehet futtatni !

Mit szóltok hozzá ?

A gázt is és a féket is egyszerre nyomni nem menő dolog !

Az komoly, hogy egyenletben egy jeloles egyszerre ket kulonbozo erteket takar? [n[19]=n[3]*n[3]*2+1]
Ertem en hogy a brute force megoldas se feltetlen trivi, de mint feladatgyarto akkor lenne erdekes, ha a megoldasnak lenne "szep" human behatarolasa is, az meg ebbol nem derul ki.
[ChatGPT-t kene megnezni, tud-e ilyet, amugy megoldani lehet, hogy wolframalpha is megoldja megfelelo keresessel es/vagy elofizuval]

[ Szerkesztve ]

Ez nem fut le:
[n[19]=n[3]*n[3]*2+1]

Ez lefut:
n = n*n*2+1
, és az n egyszerre csak 1 db értéket vehet fel, ezt sem te adod meg, csak az egyenlet két oldalát adod meg . A program gondoskodik a sorozatba fejtésről .

Túl komplikáltad a választ .

Az benne az érdekes, hogy az egyenlet két oldalát variálhatod .

"ha a megoldasnak lenne "szep" human behatarolasa is"
Ez egy matematikai játék . Prímszámokra . Mivel sorozatokat add eredményül, ezért feltehetően a ritka végesnek látszó sorozatok is végtelen hosszú sorozatok .

"Az komoly, hogy egyenletben egy jelöles egyszerre két különböző értéket takar?"
De a értékek listája ugyan az . Lehetne más lista is nem csak a prímszámok listája is, csak ahhoz egy picit babrálni kellene a kódhoz .

[ Szerkesztve ]

A gázt is és a féket is egyszerre nyomni nem menő dolog !

Rendben, kerdes: az n=n*n*2+1-nek, ha nalad az n csak ertekhalmaz barmely eleme, akkor a 31=3*5*2+1 miert nem jelolt megoldasa? A 31,3,5 eleme egyenkent...
Remelem nem azt akarod mondani hogy azt majd 'te tudod', hogy mikor melyik n azonos, melyik nem...
Ez igy nem matek.

PS. 1. [Az elozoben a szogletes zarojellel csak a megoldasban az adott n jel erteket, azok eltereset szemleltettem...]
PS. 2. Ha mar primeket keresel, miert nem p(,q,...) miert az n ami a natural numbert jelenti mindenhol mashol?

Ja, már értelek !
lásd:
https://forum.index.hu/Article/viewArticle?a=163716509&t=9035811

Szerinted ?

A gázt is és a féket is egyszerre nyomni nem menő dolog !

A 31,3,5 eleme egyenkent

Minden bizonnyal ez a sorozat is végtelen sok darab prímes, csak nagyobb tartományát kell alapul venni a prímszámoknak . A 2600 db helyet mondjuk 15 000 darab prímszámot kell futtatni erősebb gépen, csak ehhez a kódban le kell másolni az ottani 2600 db-ot 15 000 darabra, nem nehéz .

A gázt is és a féket is egyszerre nyomni nem menő dolog !

Konyorgom, miert azonos betu? Nem lehet azt mondani hogy n es m prim? Vagy n es m az adott halmazbol van? [Plane p1 es p2 ha primezel...]
Amugy meg algoritmusilag is veszett gyenge, ha eloallitod a halmazokat [k elemmel minimum O(k^2)], vagyis nem veletlen nem tud nagyobb szamossaggal menni [10 sec helyett hamar lesz 100 ev...]
2600->15000 eseten ez me'g kibirhato, de a skalazas nem itt kezdodik [es akkor me'g a szamabrazolasi problemakrol nem is beszeltunk... ami idobe es tarhelybe fordul at]
Nem lehetne hogy visszaadd a topikot az eredeti celjanak? Nem szeretnek TG-skedni pont itt.

Konyorgom, miert azonos betu? Nem lehet azt mondani hogy n es m prim?

De lehetne, én nem bánom .

Amúgy meg algoritmusilag is veszett gyenge,
Kérlek, akkor csináljátok át jobb algoritmusra . Majd én is azt fogom használni ♥

A gázt is és a féket is egyszerre nyomni nem menő dolog !

hm, szereptevesztesben vagy... munkaltatokent [kello suskaert] elvarhatnad, de en nem feladatot kertem, hanem hogy ne ide szemetelj foleg ami nem matek...

Hát azért a prímszámok az matek, és válogatás prímszámokon az is matek . Te pikkelsz rám ...

A gázt is és a féket is egyszerre nyomni nem menő dolog !

Nem pikkel rád, csak ő a topikgazda. És ez a fórum azért jött létre, hogy matematikai problémák megoldásában (és megértésében) segítsünk egymásnak.
Te viszont a saját szórakoztatásodra gyártasz elképzeléseket és módszereket, ami önmagában még nem lenne baj. Viszont ez a topik nem ezek reklámozására való. Ez a probléma.

[ Szerkesztve ]

Ubuntu MATE 20.04, hobbi cayenne termesztő

Én is így látom.

Life is too short to drive boring cars. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Szakmai kérdésekkel NE PRIVÁTBAN keress, annak a fórumon a helye! Köszönöm!

Sziasztok!

Egy olyan problémába futottam bele, hogy 2D-s térben levő téglalapokról meg kéne állapítanom, hogy "látják-e" egymást. Például van vízszintesen egymás mellett A B C (tegyük fel egyforma) téglalap, akkor ugye B kitakarja C-t. Nem vagyok matematikus, így legegyszerűbben úgy tudnám megfogalmazni, hogy A rálát B-re, de C-re nem.

Kiindulva a játékokból és grafikus programokból, ennek szerintem elég gyakori problémának kéne lennie, így biztos van rá képlet is, de nem tudom tudom milyen néven keressek rá és ebben kérném a segítségeteket.

Egyébként, ha ez segít valamit, akkor alapvetően egy gráfot szeretnék előállítani, hogy melyik téglalapnak mely téglalapok a szomszédai.

Pontosabban kellene megfogalmazni mi az, hogy "kitakarja". Melyik pontból melyik pontot? Naiv megoldásom első körben az lenne hogy a 2 kérdéses pontot összekötő szakasz metszi-e bármelyik másik téglalap bármelyik oldalát. Ez 2 szakasz metszéspontja.

[ Szerkesztve ]

Jester

Igazából nem szeretném túlbonyolítani, így arra gondoltam, hogy a kiindulópont mindig az aktuális téglalap közepe lehetne. A másik pont nehezebb kérdés. Lehetne a többi téglalap közepe (csak ez nagyon sok lesz). Esetleg második pont nélkül, az aktuális téglalap közepétől 15 fokonként elfordítva egy félegyenes. És az első téglalap az eredmény, aminek az oldala ezt metszi, ahogy írtad is.

De ezek csak ilyen saját ötletelések. Ha van rá implementáció, akkor az a legjobb, mert akkor package-ből be tudnám húzni a kódba

A "nagyon sok" az relatív. Szakasz metszéspont számítása elég egyszerű, néhány millió biztos megvan másodpercenként

Mondjuk a "szomszéd" is érdekes kérdés. Ha egy téglalap jó messze van de éppen egy lukon látszik akkor az szomszéd?

Jester

Igen, az fontos, hogy a távolság ne számítson. Ha éppen egy kis lyukon látszik az is valid, de igazából valamennyi hibahatár is belefér, így nem feltétlen lenne szükség minden szomszédra. Úgy számolom, ha mondjuk 45 fokonként (félegyenes féle verzió) vizsgálnám a jelölteket, akkor nagyjából megtalálnám a lényeget, ami az oldalsó, felső és kicsit rézsútos szomszédok. De ha tényleg gyors, nézhetem az összeset, tényleg nem számít, az sem, ha egy kis lyukon egy távoli jelöltet talál.

Egyébként ilyenkor látszik, hogy néha egy egy tök triviális dolog mennyire nem az. Például ha az élekről indítanék vonalat, akkor olyan téglalapokra is lenne rálátás, amire középről nincs. De ilyen mértékű pontosság most nekem nem kell szerencsére.

Ha jol ertem te tkp egy pontbol szeretned a 'latohataran' levo teglalapokat megtudni. Kesz megoldast exhas nem tudok, de ez nekem a latokor szakaszainak 'legkozelebbivel' fedeset sugallja. Persze ha nagyon amorf teglalapok is lehetnek, akkor darabolnek [kitakaras mogotti teglalapot h ne zavarjon be hogy a valodi csucsa messze van, az egyenese meg kozel, es akar 3 elotte allo miatt 4 darabja is latszik]
Amugy peldaul ha a teglalapok nem fedik sose egymast akkor lehet jatekgrafikai megoldas, de ha csak le vannak dobva a sikra, akkor mar ott kell kezdeni h a pont nem valamelyiken belul van-e es hogy hogyan ertelmezed azt, ha a hataran van.

Ha jol ertem te tkp egy pontbol szeretned a 'latohataran' levo teglalapokat megtudni.
Igen, pontosan

Nem fedik egymást és szabályos az alakjuk (nincsenek rotálva sem).

Ez áll legközelebb ahhoz, amit szeretnék, csak 2D-ben és mindenféle bonyolult alakzat, lencse és egyéb extrák nélkül:
https://github.com/isl-org/Open3D/issues/2906

Pontosabban ilyesmi lenne (random kép a netről):
https://i.stack.imgur.com/M7KL5.png

És akkor szépen egyesével megnézem, hogy melyik melyikkel szomszédos. Például a zöldnél kijönne, hogy a sárga, világos szürke és lilás/rózsaszínes a szomszédja.

[ Szerkesztve ]

Egyreszt sokat egyszerusodik ha minden oldal tengelyekkel hataros; masreszt nem kell a 'szomszedsag' szimmetrikus tulajdonsag legyen? A kis keknek a nagy zold szomszedja, a zoldnek a kicsi [felsorolasodbol es szemmertekre ha kozeppontbol nezem] viszont nem.
[A 'tengelyiranyu egyenes mas teglalap erintese nelkul osszekoti-e oket' az egy konnyen programozhato feladat, de ott meg a kek es szurke ha jol latom nem lennenek szomszedok ha kicsit szet vannak huzva a sarkok, szoval bar az szimmetrikus, masokat talal meg, pl. zold-piros is siman.]
Szoval a szomszedsag definiciojat at kell gondolni, de azt gyanitom egyszerubb az ilyen spec esetre megirni mint agyuval verebre valos matrixokkal dolgozo grafikai nagyagyu library-t bevetni. [Persze tevedhetek.]
Keresni is ugy probalnam h van-e ilyen [ha ezt a kozeppontos ralatast keresed], hogy nem szomszedsag hanem lathatosag vagy me'g inkabb kitakaras szamolasa.

Egyetértek axiomával, minden azon múlik, hogy hogyan definiálod a szomszédságot. Pl. ha úgy, hogy a vizsgált téglalapnak legalább egy pontjából látszik a másik téglalap legalább egy pontja, akkor a zöldnek mindegyik téglalap a szomszédja, hiszen még a bal felső pirosashoz is oda lehet látni a sárga és a kis kék közötti résen. Ha viszont úgy definiálod, hogy mindkét téglalap összes pontjából látszódjon a másik összes pontja, akkor a zöldnek a sárga sem szomszédja, hiszen a lila részben kitakarja a sárga jobb felső sarkát.

Amúgy a világos szürkén a türkizt érted?

Szemkímélő üzemmódban van a monitor, így már az is csoda, ha néhány színt eltalálok

"Ha viszont úgy definiálod, hogy mindkét téglalap összes pontjából látszódjon a másik összes pontja"
Ezzel az a problémám, hogy gondolom a sarkokban lesz egy-egy vakfolt. Tehát az átlójának vonalán elhelyezkedő téglalapokat nem találnám meg, ha azok széltében vagy hosszában nem nyúlnának túl a vakfolton.

"azt gyanitom egyszerubb az ilyen spec esetre megirni mint agyuval verebre valos matrixokkal dolgozo grafikai nagyagyu library-t bevetni"
Egyetértek, valami egyszerű és gyors kéne

"nem kell a 'szomszedsag' szimmetrikus tulajdonsag legyen?"
alapvetően igen de ezt már programkódban tudom kezelni, vagy betudom a hibahatár számlájára

Egyelőre nem tudom jobban definiálni a szomszédságot, mint ahogy a 3D-s ray tracing példában. Adott téglalap középpontjából "kilőtt" x darab ray (félegyenes, vagy kellően hosszú egyenes) és mindegyik legelső ütközése (ha egyáltalán van) az első szomszéd. És az az ütközés, ha szeli a másik téglalapot (esetleg érinti). Minél több a ray, annál nagyobb a pontosság.

Lehet van rá jobb megoldás is, ezt nem tudom.

[ Szerkesztve ]

Ha a raytracinges definíciódat nézzük, akkor az nem lesz szimmetrikus, hiszen a vizsgált téglalap melletti kisebb téglalap teljesen kitakarhat egy távolabbi harmadikat a középpontból nézve, ugyanakkor a vizsgált téglalapom széle kilóghat a kisebb mellett úgy, hogy a szélek látszódnak a harmadik középpontjából.

Ha ez nem probléma, akkor működhet egyfajta raytracing megközelítés. Pl. a vizsgált téglalap középpontját origonak véve a többi téglalap csúcsainak polárkoordinátáit veszed, ezeket rendezed irányszög alapján. Nem fog kelleni "végtelensok" ray, mivel két szomszédos irányszög között nem változik a kitakartság, tehát mondjuk a két irányszög felezője mentén vetített sugárra megnézed, hogy melyik téglalap mely oldalszakaszát metszi, és azok közül melyikkel való metszéspont van a legközelebb. Ha van ilyen oldalszakasz, akkor az adott szögtartományban az a téglalap lesz a "szomszéd".

Lényegesen egyszerűbb és szimmetrikus megoldás, ha mindkét vizsgált téglalaptól pusztán a középpontjaiknak a láthatóságát követeljük meg, azaz akkor látszik a másik téglalap, ha ennek a középpontjából látszik amannak a középpontja. Erre működik az a korábbi javaslat, hogy megnézed, vajon a két középpontot összekötő szakasz metszi-e bármely más téglalap valamelyik oldalszakaszát.

Köszönöm. Igazából lehet elkezdem az egyszerűbbel (középpontok láthatósága), aztán ha nem elég pontos az eredmény, akkor váltok a ray tracing-re.

Esetleg ezeknek a módszereknek/függvényeknek van valami megnevezése? Ha nem muszáj nem találom fel a kereket és nem programozom le fölöslegesen.

[ Szerkesztve ]

Szakaszok metszéspontjának a meghatározására találhatsz rengeteg példát és kódot a neten. Keress rá arra pl. hogy: intersection of two line segments
Vagy egyenes és szakasz metszéspontjához: line and line segment intersection

Derékszögű koordinátákat egyszerű átszámolni polárkoordinátákra:
irányszög = arctan(dy/dx)
távolság = sqrt(dx^2+dy^2) - habár ez talán nem is kell neked, elég a szög, utána a szakaszokkal úgyis ismét derékszögű koordináta-rendszerben számolsz.

Rendezésre a legtöbb programnyelvben van beépített függvény.

Nagyon köszönöm, sokat segítettetek! Hogy hogy fog sikerülni a kivitelezés, arra még kíváncsi leszek

Igazabol sokkal egyszerubb dolgod van igy, hogy minden a tengellyel parhuzamos. Gyakorlatilag sorba allithatod a letezo x es y koordinatakat, es azokon sorba allithatod a letezo vegpontokat (szakaszokat - mivel nem metszenek, a ketto ua). Ekkor csak a kozeppontok kozti letezo koordinatak listajaban kell megnezni, hogy a metszespont (ami ebben a formaban eleg egyszeruen szamolhato, aka'r ara'nyparral) egy szakasz belsejebe esik vagy sem. Ha pont 2-t talalsz (a ket teglalapnak aminek a kozeppontjabol indulsz a megfelelo oldala), akkor latjak egymast. [Ha az erintes is tartalmazas akkor figyelj hogy sarkok is bezavarhatnak, akkor kell tudni hogy melyik szakasz melyik teglalape). Menet kozben meg felhasznalhatod a mar meglevo infokat: ha egy pontnak van mar szomszedja, a szomszedok altali takarast erdemes elore venni a vizsgalatnal. Utana, ha iszonyat sok teglalapod lenne akkor az adott koordinatan belul mehetsz logaritmikus keresessel. (Igy erzesre az is jobb mint a heurisztika hogy a sorbarendezes az oldalhossz szerint van mert nagyobb oldal nagyobb esellyel kitakaras.)