Java - jak vymazat z ArrayListu množinu položek

[Standa Blábol]

dlouhá diskuze, zatím tu nezanělo žádné krátké řešení s vytvořením nového arraylistu. Rád bych viděl jednořádkový Java kód, který dělá to stejné co moje řešení v Kotlinu.

Kód: [Vybrat]

ArrayList<String> strings = new ArrayList<>(Arrays.asList("a", "b", "c", "d", "e"));
Set<Integer> indexes = new HashSet<>(Arrays.asList(2,3));

List<String> filteredStrings = IntStream.range(0, strings.size()).filter(i -> !indexes.contains(i)).mapToObj(i -> strings.get(i)).collect(Collectors.toList());

System.out.println("Filtered list: " + filteredStrings);


[Reklama]

[raskal]

dlouhá diskuze, zatím tu nezanělo žádné krátké řešení s vytvořením nového arraylistu. Rád bych viděl jednořádkový Java kód, který dělá to stejné co moje řešení v Kotlinu.

Java:

val list = Arrays.asList("one", "two", "three", "four");
val toremove = Arrays.asList(1, 2);
val filteredIdx = toremove.stream().map(list::get).collect(Collectors.toList());
System.out.println(filteredIdx); // [two, three]

[raskal]

ConcurrentModificationException ale může vypadnout i v jednovláknové aplikaci. Připadá mi to jako dost základní znalost.

Jak by jste to jako zaridil? To do metody na promazani podle indexu chcete poslat roziterovany list?

Vy zase předpokládáte, že co nevidíte, to neexistuje. Já jsem tady ale modifikaci vašeho algoritmu popisoval.

Neco jste sem napsal, ale algoritmus to rozhodne nebyl. Tak se nestydte a sem s nim!

Já zase nevidím, že byste tu někde popisoval konkrétní benchmark. Původní dotaz byl velmi vágní, můžete vymyslet asi tak milion různých benchmarků, a každý vám vyjde jinak.

Rozhodne:
- velikost pole dat 5, 50, 500, 5_000, 50_000 , 500_000 a 5_000_000 zaznamu
- velikost pole indexu 1%, 5%, 10%, 20%, 50%, 70%, 90%, 95 a 99% velikost pole dat.
Porovnavam svuj (pro vas neefektivni) algoritmus s vasim efektivnim na zahrate JVM s primerenym poctem iteraci.
Je to pro vas dost zretelne?

Akorát potvrzujete, že vám výpočetní složitost mnoho neříká. Nejdřív jste přišel s obecným tvrzením, že váš algoritmus je maximálně efektivní (tedy ze všech možných hledisek a ve všech možných případech), a teď to chcete dokazovat jedním benchmarkem.

Já bych to uzavřel tím, že váš algoritmus je pro potřeby tazatele dobrý, a do dalšího teoretizování o něm se raději nepouštějte.

Jiste, cekam az mne poucite...

[raskal]

val filteredIdx = toremove.stream().map(list::get).collect(Collectors.toList());

Je tam otocena podmink. Takhle tedy ne, pardon.

[Filip Jirsák]

Jak by jste to jako zaridil? To do metody na promazani podle indexu chcete poslat roziterovany list?

Třeba. Nebo to podle vás nejde?

Rozhodne:
- velikost pole dat 5, 50, 500, 5_000, 50_000 , 500_000 a 5_000_000 zaznamu
- velikost pole indexu 1%, 5%, 10%, 20%, 50%, 70%, 90%, 95 a 99% velikost pole dat.
Porovnavam svuj (pro vas neefektivni) algoritmus s vasim efektivnim na zahrate JVM s primerenym poctem iteraci.
Je to pro vas dost zretelne?

Je zvláštní, že jste vynechal zrovna ten parametr, o kterém se celou dobu bavíme – tedy jaká je distribuce indexů určených ke smazání. Víte o tom, že třeba třídící algoritmy jsou různě efektivní v závislosti na tom, zda mají třídit náhodně seřazená data, už seřazená data, částečně seřazené data nebo data seřazená v opačném pořadí? I kdybych tu nepsal o algoritmu, který bude tím efektivnější, čím větší souvislé bloky se budou mazat, alespoň ta podobnost s řazením vás mohla trknout.

Jiste, cekam az mne poucite...

Dávno už se stalo.

[Reklama]

[gill]

dlouhá diskuze, zatím tu nezanělo žádné krátké řešení s vytvořením nového arraylistu. Rád bych viděl jednořádkový Java kód, který dělá to stejné co moje řešení v Kotlinu.

Java:

val list = Arrays.asList("one", "two", "three", "four");
val toremove = Arrays.asList(1, 2);
val filteredIdx = toremove.stream().map(list::get).collect(Collectors.toList());
System.out.println(filteredIdx); // [two, three]

prvky z toremove naopak zachova.

[raskal]

Třeba. Nebo to podle vás nejde?

Jiste ze jde, ale tohle lze rict o kazde metode, ktera meni stav listu, napriklad ArrayList.remove(...).
Takze voda je morka, vitr fouka a vy jste mi vysvetlil, ze lze vyvolat vyjimku chybou v programu...

Je zvláštní, že jste vynechal zrovna ten parametr, o kterém se celou dobu bavíme – tedy jaká je distribuce indexů určených ke smazání. Víte o tom, že třeba třídící algoritmy jsou různě efektivní v závislosti na tom, zda mají třídit náhodně seřazená data, už seřazená data, částečně seřazené data nebo data seřazená v opačném pořadí? I kdybych tu nepsal o algoritmu, který bude tím efektivnější, čím větší souvislé bloky se budou mazat, alespoň ta podobnost s řazením vás mohla trknout.

Ne, pouze jsem nepredpokladal, ze vam ty % nebudou zrejme.
Proc jen jsou odstupnovane..? Tak zapojte hlavu a zkuste to vymyslet, at to to nemusim vysvetlovat zcela polopaticky.

Dávno už se stalo.

Nekolikrat jste napsal, ze jste neco dokazal. Ne.
Pouze jste jedno poprel a druhe se snazil odiskutovat. To ale neni zadny dukaz, to je tlachani.
Zadny aloritmus k porovnani jsem od vas nevidel a zadny zrejme ani neuvidim.

[Filip Jirsák]

vy jste mi vysvetlil, ze lze vyvolat vyjimku chybou v programu...

Nikoli, já jsem vám vysvětlil, že ConcurrentModificationException nemá nic společného s vícevláknovým přístupem. Ono je to s vlastně skoro opačně. ArrayList není bezpečné používat z více vláken bez explicitní synchronizace přístupu, a pokud se ho pokusíte používat z více vláken bez synchronizace, může se vám stát, že např. pokud budete v jednom vlákně iterovat a v druhém vlákně seznam modifikovat, výjimka ConcurrentModificationException nevypadne.

Sice jsem vám zase jen opsal to, co je napsané v JavaDocu, ale doufám, že to k něčemu bylo, ten JavaDoc si teď dostudujete a příště nebudete ArrayList a ConcurrentModificationException spojovat s více vlákny.

Ne, pouze jsem nepredpokladal, ze vam ty % nebudou zrejme.
Proc jen jsou odstupnovane..? Tak zapojte hlavu a zkuste to vymyslet, at to to nemusim vysvetlovat zcela polopaticky.

Dost ubohý pokus, já si pamatuju, o čem jsem psal, a kdybych si to nepamatoval, můžu si to přečíst. Psal jsem, že vám v tom přehledu benchmarků dost podstatná kategorie chybí. Což nezamaskujete tím, že se budete pokoušet vrátit k těm, kter jste vyjmenoval, a vymýšlet si, že je nechápu.

Nekolikrat jste napsal, ze jste neco dokazal. Ne.
Pouze jste jedno poprel a druhe se snazil odiskutovat. To ale neni zadny dukaz, to je tlachani.
Zadny aloritmus k porovnani jsem od vas nevidel a zadny zrejme ani neuvidim.

Problém je v tom, že nevíte, co je to algoritmus. Algoritmus je popis řešení problému určený pro lidi – a ten já jsem napsal. Na rozdíl od vás, vy jste napsal implementaci algoritmu, v konkrétním programovacím jazyce. Z vašeho kódu není tak těžké algoritmus odvodit, ale algoritmus to není.

Ten mnou popsaný algoritmus není nijak složitý, měl byste být schopen ten kód napsat sám. Zvlášť pokud chcete dělat jeho benchmark – udělat rozumný benchmark není nic snadného, není to jen změřit pár čísel, která nic neznamenají. Umět nějaký kód napsat je nutná podmínka toho, abyste na něj mohl udělat dobrý benchmark – protože tomu kódu musíte rozumět, musíte vědět, jaká jsou jeho slabá a silná místa. Jinak tím svým benchmarkem klidně změříte nějakou výjimečnou situaci, kde ten kód bude náhodou výjimečně efektivní nebo výjimečně neefektivní.

[raskal]

vy jste mi vysvetlil, ze lze vyvolat vyjimku chybou v programu...

Nikoli, já jsem vám vysvětlil, že ConcurrentModificationException nemá nic společného s vícevláknovým přístupem. Ono je to s vlastně skoro opačně. ArrayList není bezpečné používat z více vláken bez explicitní synchronizace přístupu, a pokud se ho pokusíte používat z více vláken bez synchronizace, může se vám stát, že např. pokud budete v jednom vlákně iterovat a v druhém vlákně seznam modifikovat, výjimka ConcurrentModificationException nevypadne.

Sice jsem vám zase jen opsal to, co je napsané v JavaDocu, ale doufám, že to k něčemu bylo, ten JavaDoc si teď dostudujete a příště nebudete ArrayList a ConcurrentModificationException spojovat s více vlákny.

Ne, pouze jsem nepredpokladal, ze vam ty % nebudou zrejme.
Proc jen jsou odstupnovane..? Tak zapojte hlavu a zkuste to vymyslet, at to to nemusim vysvetlovat zcela polopaticky.

Dost ubohý pokus, já si pamatuju, o čem jsem psal, a kdybych si to nepamatoval, můžu si to přečíst. Psal jsem, že vám v tom přehledu benchmarků dost podstatná kategorie chybí. Což nezamaskujete tím, že se budete pokoušet vrátit k těm, kter jste vyjmenoval, a vymýšlet si, že je nechápu.

Nekolikrat jste napsal, ze jste neco dokazal. Ne.
Pouze jste jedno poprel a druhe se snazil odiskutovat. To ale neni zadny dukaz, to je tlachani.
Zadny aloritmus k porovnani jsem od vas nevidel a zadny zrejme ani neuvidim.

Problém je v tom, že nevíte, co je to algoritmus. Algoritmus je popis řešení problému určený pro lidi – a ten já jsem napsal. Na rozdíl od vás, vy jste napsal implementaci algoritmu, v konkrétním programovacím jazyce. Z vašeho kódu není tak těžké algoritmus odvodit, ale algoritmus to není.

Ten mnou popsaný algoritmus není nijak složitý, měl byste být schopen ten kód napsat sám. Zvlášť pokud chcete dělat jeho benchmark – udělat rozumný benchmark není nic snadného, není to jen změřit pár čísel, která nic neznamenají. Umět nějaký kód napsat je nutná podmínka toho, abyste na něj mohl udělat dobrý benchmark – protože tomu kódu musíte rozumět, musíte vědět, jaká jsou jeho slabá a silná místa. Jinak tím svým benchmarkem klidně změříte nějakou výjimečnou situaci, kde ten kód bude náhodou výjimečně efektivní nebo výjimečně neefektivní.

S vama je to jak s malym chlapcem, ktery vsude byl a vsechno videl. Upozornujete na veci zrejme jako by v nich v kontextu tohoto fora slo o neco duleziteho a nehodlate pripustit celkem zakladni principy. Jste pro me jen ztratou casu.

[Filip Jirsák]

Upozornujete na veci zrejme jako by v nich v kontextu tohoto fora slo o neco duleziteho

Na vašem místě bych se radši zamyslel, proč vám někdo musí ty zřejmé věci vysvětlovat – že ConcurrentModificationException nijak nesouvisí s vícevláknovým přístupem, že efektivitu algoritmu lze měřit z různých hledisek, že efektivita algoritmu pracujícího s podmnožinou prvků seznamu závisí na tom, jak jsou rozložené prvky z té podmnožiny… To, že opravuju vaše chybná vyjádření, neznamená, že jsem všude byl a všechno viděl. Znamená to akorát to, že vidím chyby, které vy nevidíte. Když na sto metrech předběhnete kulhajícího důchodce, neznamená to, že jste mistr světa v běhu na sto metrů, ale jenom to, že jste alespoň o fous rychlejší, než ten kulhající důchodce.