[JAVA] Lengte van meerdimensionale array

[Oogst]

Het is vast heel erg gemakkelijk te vinden, maar ik heb geen idee met welke zoektermen (array levert alleen info over de klasse array), dus ik vraag het maar gewoon.

Ik heb een 2-dimensionale array gemaakt in JAVA:

int [] [] array = new int [500] [300];

En daarvan wil ik de breedte en de lengte te weten komen, dus zoiets als:

array.length;

Maar daarmee wil ik dus ene keer de 500 te weten komen en de andere keer de 300. Hoe krijg ik dat?

^{Nogmaals: het is vast heel erg gemakkelijk, maar ik kan het dus niet vinden.}

[frapex]

geloof dat de een dus was .. array.length (zoals je zelf al zei) en de andere array[0].length

[Glimi]

Kijk uit waar je mee bezig bent! Met arr[0].length bevind je je op glad ijs. Neem dit volgende stukje (smerige!) code

Java:

public class Test {

        public static void main( String[] args ) {

                // create our array
                Object[] arr = new Object[10];

                for( int i = 0; i < arr.length; i++ ) {
                        
                        arr[i] = new Object[i];
                }
                
                // Now print length's
                for( int i = 0; i < arr.length; i++ ) {
                        
                        Object[] arrVar = (Object[])arr[i];
                        System.out.println( arrVar.length );
                }
        }
}

Gebruik aub ArrayLists, LinkedLists en HashMaps waar dat kan en array's zo weinig mogelijk

[hammerhead]

Glimi schreef op 06 July 2003 @ 22:02:
Kijk uit waar je mee bezig bent! Met <code>arr[0].length</code> bevind je je op glad ijs. Neem dit volgende stukje (smerige!) code

<... knip ...>

Gebruik aub ArrayLists, LinkedLists en HashMaps waar dat kan en array's zo weinig mogelijk

Maar als je hem zelf instantieert en je zeker weet dat je daar verder niets aan verandert is het toch niet zo erg? Moet zelf op zich ook wel gebruik maken van arrays op dit moment en ik weet gewoon dat bij sommige arrays idd de tweede dimensie per index een andere lengte kan hebben. Zolang ik dit niet vergeet () blijft alles wel goed gaan (oh ja... en is trouwens ook nog wel gedocumenteerd )

Zijn normale arrays overigens niet sneller dan elk van de andere opties die jij noemt?

[Soultaker]

hammerhead schreef op 06 juli 2003 @ 23:50:
Zijn normale arrays overigens niet sneller dan elk van de andere opties die jij noemt?

Waarschijnlijk wel, maar waarom zou je je als Java-programmeur zorgen maken over snelheid? Ik bedoel dat niet als sneer; blijkbaar heb je goede redenen om voor het Java platform te kiezen en je bent bereid om daar executiesnelheid voor in te leveren (want laten we wel zijn, Java is traag). Waarom zou je je nu druk maken over het marginale snelheidsverschil tussen arrays en Collection classes?

Waar denk je die arrays voor te gebruiken? Denk je dat je een merkbaar verschil in executiesnelheid gaat krijgen? Er zijn natuurlijk scenario's te construeren waarin dit wel het geval is, maar waarschijnlijk is jouw situatie daar niet één van.

[hobbit_be]

Oogst schreef op 06 July 2003 @ 21:02:
int [] [] array = new int [500] [300];
En daarvan wil ik de breedte en de lengte te weten komen, dus zoiets als:

word of warning: Java is geen C - omdat je [][] wil dit niet zeggen dat je een rechthoekige array hebt. (WEL als je hem zoals hierboven def) maar een x[][] kan ook
[[1,2],[1,2,3],[1,2,3,4]] zijn.

wel grappig vind ik dat je de width+heigth wil hebben terwijl je die klaarblijkelijk al kent. (ie 500x300).

Tis allemaal wat je wil doen met je array. Als je een bitmap hebt zou ik alvast geen [][] doen maar een [offset*y+x].

[Glimi]

hammerhead schreef op 06 July 2003 @ 23:50:
Maar als je hem zelf instantieert en je zeker weet dat je daar verder niets aan verandert is het toch niet zo erg? (...)

Je, je, je. Je moet generieke code schrijven en niet zulke aannames maken Anders is uw code niet goed herbruikbaar. Aannames moet je anders afdwingen maar dan met zo'n controle ben je ook O(n) tijd kwijt (worst case), dus sneller zal het niet echt zijn (wel in z'n constante )

Zijn normale arrays overigens niet sneller dan elk van de andere opties die jij noemt?

Normale array's doen ook boundchecks, dus eigenlijk grofweg zit er alleen een methodcall tussen en enkele checks. Nou, da's nou niet echt zoveel werk hoor
Tevens gaat de resize ook maar soms door (1/N) keer en dat gaat in O(n) tijd. Als jij je N goed kiest (Max elems) dan gaat ook een ArrayList in O(1) tijd, net als een array

Soultaker schreef op 07 July 2003 @ 01:25:
[...]

Waarschijnlijk wel, maar waarom zou je je als Java-programmeur zorgen maken over snelheid? (...)

* Glimi agrees met Soultaker

hobbit_be schreef op 07 July 2003 @ 01:42:

*kuch* [rml]Glimi in "[ JAVA] Lengte van meerdimensionale array"[/rml]

[hammerhead]

Soultaker schreef op 07 July 2003 @ 01:25:
[...]
Waar denk je die arrays voor te gebruiken? Denk je dat je een merkbaar verschil in executiesnelheid gaat krijgen? Er zijn natuurlijk scenario's te construeren waarin dit wel het geval is, maar waarschijnlijk is jouw situatie daar niet één van.

Een scenario wat ik op zich wel kan bedenken is het gebruik maken van een array van integers. Als ik gebruik maak van een normale array is dit vermoedelijk sneller dan dat ik voor elk element een Integer object moet instantieren om in een ArrayList of elk van de andere mogelijkheden te zetten. Of je moet me nu een zeer goede tip kunnen geven wat sneller en beter is om te gebruiken om een 2 Dimensionale lijst van integers te representeren (grootte is ongeveer 150 x 40).

Glimi schreef op 07 July 2003 @ 09:50:
[...]
Je, je, je. Je moet generieke code schrijven en niet zulke aannames maken Anders is uw code niet goed herbruikbaar. Aannames moet je anders afdwingen maar dan met zo'n controle ben je ook O(n) tijd kwijt (worst case), dus sneller zal het niet echt zijn (wel in z'n constante )

Naar mijn mening is die code best generiek. De arrays worden bij de start van mijn programma geinitialiseerd met de juiste breedtes die uit het invoerbestand wordt gehaald. Deze breedtes lees ik zelf ook in een variabelen in dus het is vrij makkelijk bij te houden wat de breedte van een bepaalde regel in mijn array is.

[Glimi]

hammerhead schreef op 07 July 2003 @ 10:36:
Een scenario wat ik op zich wel kan bedenken is het gebruik maken van een array van integers. (...)

Is het dan mogelijk om niet-vierkant prim. array's te maken...

Naar mijn mening is die code best generiek. De arrays worden bij de start van mijn programma geinitialiseerd met de juiste breedtes die uit het invoerbestand wordt gehaald. (...)

Kijk verder dan je eigen code. Als ik een programma heb waarin ik een niet-vierkante array heb en gebruik uw code, dan zal het dus niet werken

[Soultaker]

hammerhead schreef op 07 July 2003 @ 10:36:
Een scenario wat ik op zich wel kan bedenken is het gebruik maken van een array van integers. Als ik gebruik maak van een normale array is dit vermoedelijk sneller dan dat ik voor elk element een Integer object moet instantieren om in een ArrayList of elk van de andere mogelijkheden te zetten. Of je moet me nu een zeer goede tip kunnen geven wat sneller en beter is om te gebruiken om een 2 Dimensionale lijst van integers te representeren (grootte is ongeveer 150 x 40).

Dat is inderdaad een zinnig scenario. Overigens illustreert dat meer de noodzaak voor programmeurs om om het brakke typesysteem van Java heen te werken, dan dat die array echt beter is dan een Collection object. Als er een IntVector zou bestaan (waar ik dus ints in kan mikken) zou ik die bijvoorbeeld liever gebruiken dan arrays van ints, maar ja... die zou je dan zelf moeten schrijven, en dat is ook weer zo wat.

Overigens vind ik het trouwens niet verkeerd om arrays te gebruiken voor de opslag van statische gegevens die niet verder bewerkt hoeven worden. Als je bijvoorbeeld een bitmap uit een bestand leest en de kleurwaarden in een array opslaat, lijkt me dat prima: je hebt nooit de intentie om de grootte van die array te wijzigen. Wil je echter elementen aan de collectie kunnen toevoegen, of eruit verwijderen, dan is een gewone array doorgaans ook geschikt, zeker als je geen van de operaties op Collection classes nodig hebt (zoals het sorteren van elementen, etc.).

Naar mijn mening is die code best generiek. De arrays worden bij de start van mijn programma geinitialiseerd met de juiste breedtes die uit het invoerbestand wordt gehaald. Deze breedtes lees ik zelf ook in een variabelen in dus het is vrij makkelijk bij te houden wat de breedte van een bepaalde regel in mijn array is.

Afhankelijk van wat voor programma je gebruikt, zou ik zeggen dat je best als eis kunt stellen dat de array 'vierkant' moet zijn en meer dan 0 elementen moet bevatten. Dit moet je dan natuurlijk wel duidelijk documenteren. Je kunt (zeker in Java) nu eenmaal niet overal op gaan controleren, maar je kunt er wel goed voor zorgen dat je code consistent, helder en goed gedocumenteerd is. Op die manier kun je ook fouten uitsluiten.

Glimi schreef op 07 July 2003 @ 10:51:
Kijk verder dan je eigen code. Als ik een programma heb waarin ik een niet-vierkante array heb en gebruik uw code, dan zal het dus niet werken

Ik vind de waarheid van die opmerking nogal afhankelijk van de functionaliteit die de code aanbiedt. Als de functie een matrix inverteert, dan is het de vraag of het zinvol is om ondersteuning te bieden voor een niet-vierkante array, want die representeert eigenlijk geen goede matrix (tenzij je zelf met nullen gaat aanvullen maar dat is zeker verkeerd; motivatie op aanvraag beschikbaar). Ik vind het dan best redelijk om te stellen dat de functie een vierkante array vereist.

Uiteraard zou je de invoer kunnen controleren op geldigheid en een InvalidArgumentException kunnen gooien als je een verkeerde array binnenkrijgt, maar die controle is in veel situaties erg duur, en hoewel ik dat niet zo'n sterk argument voor het Java platform vindt (zie eerdere reacties ) is het natuurlijk wel jammer dat je zulke controles gaat invoeren, terwijl een OO-taal als Java een veel betere manier kent om consistente gegevens te garanderen: het schrijven van een klasse die de gewenste invariant forceert. Dat zou alle problemen eigenlijk oplossen, omdat de instanties van die klasse dan gewoon hun eigen breedte en hoogte kennen.

[ Voor 23% gewijzigd door Soultaker op 07-07-2003 11:13 ]

[hobbit_be]

Glimi schreef op 07 July 2003 @ 09:50:
*kuch* [rml]Glimi in "[ JAVA] Lengte van meerdimensionale array"[/rml]

snap het niet hoor? wat had mijn comment nou met jouw code te maken?

mijn persoonlijke ervaringen met [] == speed. gecombineerd met System.arraycopy enzovoorts is dit veel (VEEL) sneller dan het werken met collection-classes (maar natuurlijk veel minder 'handig'). Dat een [] ook wordt gebounds checked: idd maar wel op native niveau niet in java p-code. En daar is wel een enorm verschil in. en een array[index] is ook heel wat sneller dan een
Collecten.get(item). (als het een linkedlist is - oh boy).

Maar goed dit is voor een situatie waar speed een must is (en met java being quite slow dit is wel overal ). Zelf gebruik ik ook amper [] tenzij het een 'innerloop' is of als ik zeker weet dat het niet resized kan worden. ook het afgaan van een array is sneller dan iterator (zoals het hoort bij een collection). Maar als je maar 200 dingen hebt is het frigging pointless.

Ook hammerheads conclusie dat een Collection gevult moet worden met Objects is heel juist. Voor images is dit gewoon overkill.

Het echt enige jammer van Java + Imaging is het gebrek aan een 'unsigned'.

[Oogst]

Waar ik de array voor nodig heb, is voor een z-buffer. Het is dus een 2d-array met daarin integers die de afstand van een gerenderde pixel in een scanline 3d-engine opslaan. Inderdaad sla ik dus alleen integers op. Ik moet er snel bij kunnen, want voor iedere pixel die gerenderd wordt, wordt een vergelijking met een waarde in de z-buffer gedaan. In een complete beeldvullende scene met een scherm van 500*300 zijn dit dus 150.000 vergelijkingen en schrijvingen naar de z-buffer per frame.

De grootte van de z-buffer staat vast zolang het scherm niet geresized wordt, maar wanneer het scherm geresized wordt, of wanneer ik het scherm op een andere grootte laat initialiseren, dan wil ik graag dat daar automatisch goed mee omgegaan wordt. Bij een scherm-resize resize ik namelijk ook de z-buffer. Daarbij is het niet nodig oude waarden in de z-buffer op te slaan, dus dat doe ik dan ook niet.

En de maten van de z-buffer meegeven vind ik niet echt netjes, want ik doe meerdere methode-aanroepen die hem nodig hebben en als ik die nu ook nog eens twee extre integers mee moet geven, dan zit ik naar mijn mening op onhandig veel parameters, zeker ook omdat de waarden die ik wil hebben al in de array zitten besloten.

De reden dat ik JAVA gebruik, is dat ik daar redelijk mijn weg in weet en dat ik het wel leuk vindt om mijn programmaatje in applet-vorm te maken, zodat ik het online neer kan zetten. Ik weet wel dat JAVA eigenlijk veel te traag is voor een 3d-engine, maar dit hele project is toch vooral bedoeld om ervaring op te doen met het schrijven van een 3d-renderer en mijn net opgedane kennis van lineaire algebra in de praktijk te brengen. Dat het niet een bruikbare snelheid haalt is dus niet echt erg.

[hobbit_be]

dan zijn [] de enige oplossing.

er bestaan trouwens al heelder software java-3d engines en die zijn best wel snel (geel fulsscreen he - applet size) maar de meeste zullen wel geen z-buffer approach gebruiken maar span-based rendering. (de laatste heeft 0-overdraw (tenzij je transparency hebt)) terwijl een zbuffer niet zo cpu vriendelijk is.

doe een paar tests om te kijken of:

array[10][10] = 0xFFFFF; sneller is dan array[10*w+10]. als het om realtime gaak moet je dit testen. Ook zou je best kijken naar Volatile Image enzovoorts. Ook ByteBuffers (NIO) zullen extra tijdwinst opleveren (deze zijn native arrays). Beslis ook dat met 16bit kleuren of 24(32) wil werken.

Enjoy... (je ZOU ook JavaOGL kunnen installeren )

[Oogst]

Ik ga eerst eens proberen het werkend te krijgen, want dat valt me al genoeg tegen, voor ik ga zoeken naar optimalisaties. Als ik probeer te optimaliseren voor ik alles goed genoeg werkend heb, dan gaat het zeker niks worden.

[hammerhead]

hobbit_be schreef op 07 July 2003 @ 12:58:
...
Ook ByteBuffers (NIO) zullen extra tijdwinst opleveren (deze zijn native arrays).
...

Is het zo dat indien ik voor mijn programma gebruik maak van vaste grootte arrays van integers met vrij kleine waarden ik nog een snelheidswinst zou kunnen halen met het gebruik van ByteBuffers?

[hobbit_be]

hammerhead schreef op 07 July 2003 @ 13:18:
[...]
Is het zo dat indien ik voor mijn programma gebruik maak van vaste grootte arrays van integers met vrij kleine waarden ik nog een snelheidswinst zou kunnen halen met het gebruik van ByteBuffers?

? integers met kleine waardes? <255 ofzo? ik denk niet dat het handig zou zijn om je int te gaan opsplitsen in 4 bytes en die dan samen te voegen (veel geshift en veel sign probs). IntBuffer ?

[hammerhead]

hobbit_be schreef op 07 July 2003 @ 13:33:
[...]


? integers met kleine waardes? <255 ofzo? ik denk niet dat het handig zou zijn om je int te gaan opsplitsen in 4 bytes en die dan samen te voegen (veel geshift en veel sign probs). IntBuffer ?

Misschien niet, maar ik heb even zitten kijken bij de API's van NIO en ik kwam tegen dat indien er gebruik gemaakt wordt van ByteBuffers het mogelijk is om deze Direct te maken waardoor de JVM zal proberen alle operaties die je erop uitvoert native te doen. Het lijkt me dat dat op zich wel wat kan schelen, maar geheel zeker weten doe ik dat niet. Daarom vroeg ik me dat dus af. Indien niemand het antwoord zo snel weet zal ik mijn programma als ik tijd heb eens om gaan schrijven om het zelf te gaan testen.

[Glimi]

hobbit_be schreef op 07 juli 2003 @ 12:35:
snap het niet hoor? wat had mijn comment nou met jouw code te maken?

offtopic:
Je word of warning

Soultaker
(...)Ik vind het dan best redelijk om te stellen dat de functie een vierkante array vereist.

Uiteraard zou je de invoer kunnen controleren op geldigheid en een InvalidArgumentException kunnen gooien als je een verkeerde array binnenkrijgt,

Mja ik ben toch eerder geneigd om te gaan voor het tegengaan van data-corruptie door een verkeerde invoer. Maarja daarom zou ik ook eigenlijk niet voor array's kiezen en en voor een class zoals je ook suggereert