Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Fundamentalne tablice

1 view
Skip to first unread message

sw

unread,
Jul 3, 2008, 4:30:48 PM7/3/08
to
Witam,

Mam tablice:
String k_tab = new String[100][200][300];
int k_int = k_tab.length();

no wlasnie i co ja tu dostane?:)
A jak pobrac dlugosci innych wymiarow?


--
Pozdrawiam
SW

Grzegorz Brzeczyszczykiewicz

unread,
Jul 3, 2008, 4:35:10 PM7/3/08
to
sw wrote:

> no wlasnie i co ja tu dostane?:)

Ode mnie - w głowę albo po łapach :-)
Analizowałem kiedyś kod operujący na tablicach dwuwymiarowych.
Niezła masakra. A 3-wymiarowych? Nie chcę myśleć.

--
Grzegorz Brzeczyszczykiewicz
http://tnij.org/205cabrio

qwak

unread,
Jul 3, 2008, 4:47:40 PM7/3/08
to
sw pisze:

> Witam,
>
> Mam tablice:
> String k_tab = new String[100][200][300];
> int k_int = k_tab.length();
>
> no wlasnie i co ja tu dostane?:)

Błąd przy próbie kompilacji (niezgodność typów).

--
Piotr Beling
http://qwak.w8.pl
http://bcalc.w8.pl
http://warcaby.w8.pl

news.gazeta.pl

unread,
Jul 4, 2008, 2:46:01 AM7/4/08
to

"qwak" <qw...@stud.ics.p.lodz.pl> wrote in message
news:g4je03$1gk$1...@atlantis.news.neostrada.pl...


To było pytanie retoryczne dlatego z buzka. Ja dostaje tu zawsze rozmiar
pierwszego wymiaru - czyli w tym przypadku 100. Pytanie jest jak zczytać
pozostałe?

Pozdrawiam
SW

news.gazeta.pl

unread,
Jul 4, 2008, 2:48:10 AM7/4/08
to

"news.gazeta.pl" <s...@boos.com> wrote in message
news:g4kgvb$7uo$1...@inews.gazeta.pl...

pomylka, powinno byc tak: int k_int = k_tab.length;
Pozdrawiam
SW


redi

unread,
Jul 4, 2008, 3:03:11 AM7/4/08
to

int size1 = k_tab.length;
int size2 = k_tab[0].length;
int size3 = k_tab[0][0].length;
System.out.println("Size1: " + size1);
System.out.println("Size2: " + size2);
System.out.println("Size3: " + size3);

Ale stosowanie czegoś takiego nie jest chyba dobrym pomysłem.

Mikolaj Rydzewski

unread,
Jul 4, 2008, 3:13:26 AM7/4/08
to
redi wrote:
> Ale stosowanie czegoś takiego nie jest chyba dobrym pomysłem.

Owszem, jak zaimplementowac toString() dla takiego potworka? ;-)

Brzezi

unread,
Jul 4, 2008, 4:54:01 AM7/4/08
to
czw, 03 lip 2008 o 22:30 GMT, sw napisał(a):

> Mam tablice:
> String k_tab = new String[100][200][300];

Zacznij od poprawnego zadeklarowania tablicy, bo ten kod nawet sie nie
skompiluje...

Pozdrawiam
Brzezi
--
[ E-mail: brz...@enter.net.pl ][ A conclusion is simply the place where ]
[ Ekg: #3781111 ][ someone got tired of thinking. ]
[ LinuxUser: #249916 ][ ]

Mateusz Ludwin

unread,
Jul 4, 2008, 5:25:48 AM7/4/08
to
pl.comp.lang.java.getSenderByName("*Grzegorz Brzeczyszczykiewicz*").quote();

>> no wlasnie i co ja tu dostane?:)
> Ode mnie - w głowę albo po łapach :-)
> Analizowałem kiedyś kod operujący na tablicach dwuwymiarowych.
> Niezła masakra. A 3-wymiarowych? Nie chcę myśleć.

To jak proponujesz realizować przetwarzanie obrazu? Chyba nie przez metodę
set/getPixelValue(int x, int y)?
--
Omniscient, omnipotent, omnipresent, without judgment

Mateusz Ludwin mateuszl [at] gmail [dot] com

jolz

unread,
Jul 4, 2008, 1:10:58 PM7/4/08
to
> Ale stosowanie czegoś takiego nie jest chyba dobrym pomysłem.

Najlepszym jaki znam. Ale trzeba pamietac ze:
- k_tab[0] moze rzucic ArrayIndexOutOfBoundsException
- k_tab[0].length nie musi byc rowne k_tab[1].length

Grzegorz Brzeczyszczykiewicz

unread,
Jul 4, 2008, 1:57:06 PM7/4/08
to
Mateusz Ludwin wrote:

> pl.comp.lang.java.getSenderByName("*Grzegorz
> Brzeczyszczykiewicz*").quote();
>
>>> no wlasnie i co ja tu dostane?:)
>> Ode mnie - w głowę albo po łapach :-)
>> Analizowałem kiedyś kod operujący na tablicach dwuwymiarowych.
>> Niezła masakra. A 3-wymiarowych? Nie chcę myśleć.
>
> To jak proponujesz realizować przetwarzanie obrazu? Chyba nie przez metodę
> set/getPixelValue(int x, int y)?

Przetwarzanie obrazu? Za pomocą kodu natywnego.

Mateusz Ludwin

unread,
Jul 4, 2008, 2:45:27 PM7/4/08
to
pl.comp.lang.java.getSenderByName("*Grzegorz Brzeczyszczykiewicz*").quote();

>> To jak proponujesz realizować przetwarzanie obrazu? Chyba nie przez metodę
>> set/getPixelValue(int x, int y)?
>
> Przetwarzanie obrazu? Za pomocą kodu natywnego.

I w tym kodzie natywnym jak sobie wyobrażasz odwołania do tablic? :>

Grzegorz Brzeczyszczykiewicz

unread,
Jul 4, 2008, 2:50:28 PM7/4/08
to
Mateusz Ludwin wrote:

> pl.comp.lang.java.getSenderByName("*Grzegorz
> Brzeczyszczykiewicz*").quote();
>
>>> To jak proponujesz realizować przetwarzanie obrazu? Chyba nie przez
>>> metodę set/getPixelValue(int x, int y)?
>>
>> Przetwarzanie obrazu? Za pomocą kodu natywnego.
>
> I w tym kodzie natywnym jak sobie wyobrażasz odwołania do tablic? :>

Tam można tak dziergać, ale to już raczej nie Java :-)

KosciaK

unread,
Jul 4, 2008, 3:00:22 PM7/4/08
to
Mateusz Ludwin pisze:

> pl.comp.lang.java.getSenderByName("*Grzegorz Brzeczyszczykiewicz*").quote();
>
>>> no wlasnie i co ja tu dostane?:)
>> Ode mnie - w głowę albo po łapach :-)
>> Analizowałem kiedyś kod operujący na tablicach dwuwymiarowych.
>> Niezła masakra. A 3-wymiarowych? Nie chcę myśleć.
>
> To jak proponujesz realizować przetwarzanie obrazu? Chyba nie przez metodę
> set/getPixelValue(int x, int y)?

A dlaczego nie?
Chyba lepiej opakować takie wielowymiarowe tablice w jakąś ładną klasę i
operować na metodach tej klasy. Przy okazji można porobić jakieś
Iteratory czy inne metody ułatwiające pobieranie, ustawianie podzbiorów
pikseli

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
KosciaK mail: kosciak1(at)gmail(dot)com
www : http://kosciak.blox.pl/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Mateusz Ludwin

unread,
Jul 4, 2008, 3:49:57 PM7/4/08
to
pl.comp.lang.java.getSenderByName("*KosciaK*").quote();

>> To jak proponujesz realizować przetwarzanie obrazu? Chyba nie przez metodę
>> set/getPixelValue(int x, int y)?
>
> A dlaczego nie?

Bo IMHO JVM w żaden sposób sobie tego nie zoptymalizuje, a obliczenia
macierzowe aż się proszą o zrównoleglenie.

Brzezi

unread,
Jul 4, 2008, 5:11:38 PM7/4/08
to
pią, 04 lip 2008 o 20:50 GMT, Grzegorz Brzeczyszczykiewicz napisał(a):

>> I w tym kodzie natywnym jak sobie wyobrażasz odwołania do tablic? :>
> Tam można tak dziergać, ale to już raczej nie Java :-)

Kiedys widzialem jakies testy wydajnosci, i akurat java nie miala problemow
z operacjami na tablicach, mimo ze ma sprawdzanie przekroczenia zakresu...

Poza tym, uwazam ze stosowanie kodu natywnego to jest ostatecznosc, w
wyjatkowych sytuacjach, bo najczesciej przynosi wiecej szkody niz pozytku..
>

Pozdrawiam
Brzezi
--
[ E-mail: brz...@enter.net.pl ][ Boren's Laws: ]
[ Ekg: #3781111 ][ (1) When in charge, ponder. ]
[ LinuxUser: #249916 ][ (2) When in trouble, delegate. ]
[ (3) When in doubt, mumble. ]

Grzegorz Brzeczyszczykiewicz

unread,
Jul 4, 2008, 6:03:02 PM7/4/08
to
Brzezi wrote:

> pią, 04 lip 2008 o 20:50 GMT, Grzegorz Brzeczyszczykiewicz napisał(a):
>
>>> I w tym kodzie natywnym jak sobie wyobrażasz odwołania do tablic? :>
>> Tam można tak dziergać, ale to już raczej nie Java :-)
>
> Kiedys widzialem jakies testy wydajnosci, i akurat java nie miala
> problemow z operacjami na tablicach, mimo ze ma sprawdzanie przekroczenia
> zakresu...

Nie ma nic za darmo. Nie da się sprawdzić zakresu w zerowym czasie, więc
kod C, który tego nie robi, musi być szybszy.

> Poza tym, uwazam ze stosowanie kodu natywnego to jest ostatecznosc, w
> wyjatkowych sytuacjach, bo najczesciej przynosi wiecej szkody niz
> pozytku..

Jak już zaczynamy dziergać po wielowymiarowych tablicach, to dlaczego nie
iść na całość.

Grzegorz Brzeczyszczykiewicz

unread,
Jul 4, 2008, 6:04:18 PM7/4/08
to
Mateusz Ludwin wrote:

> pl.comp.lang.java.getSenderByName("*KosciaK*").quote();
>
>>> To jak proponujesz realizować przetwarzanie obrazu? Chyba nie przez
>>> metodę set/getPixelValue(int x, int y)?
>>
>> A dlaczego nie?
>
> Bo IMHO JVM w żaden sposób sobie tego nie zoptymalizuje, a obliczenia
> macierzowe aż się proszą o zrównoleglenie.

A jak będziesz jechał po tablicach to samo się zrównolegli?

Mateusz Ludwin

unread,
Jul 5, 2008, 5:16:11 AM7/5/08
to
pl.comp.lang.java.getSenderByName("*Grzegorz Brzeczyszczykiewicz*").quote();

>> Bo IMHO JVM w żaden sposób sobie tego nie zoptymalizuje, a obliczenia
>> macierzowe aż się proszą o zrównoleglenie.
>
> A jak będziesz jechał po tablicach to samo się zrównolegli?

To istnieje szansa że tak się stanie.

Brzezi

unread,
Jul 6, 2008, 12:39:44 PM7/6/08
to
sob, 05 lip 2008 o 00:03 GMT, Grzegorz Brzeczyszczykiewicz napisał(a):

>> Kiedys widzialem jakies testy wydajnosci, i akurat java nie miala
>> problemow z operacjami na tablicach, mimo ze ma sprawdzanie przekroczenia
>> zakresu...
> Nie ma nic za darmo. Nie da się sprawdzić zakresu w zerowym czasie, więc
> kod C, który tego nie robi, musi być szybszy.

nie musi, moze byc, moze nie byc, sprawdzenie raczej nie jest bardzo
kosztowne, zreszta kod programu to nie same operacje tablicowe, wplyw na
wydajnosc ma wiele wiecej czynnikow

>> Poza tym, uwazam ze stosowanie kodu natywnego to jest ostatecznosc, w
>> wyjatkowych sytuacjach, bo najczesciej przynosi wiecej szkody niz
>> pozytku..
> Jak już zaczynamy dziergać po wielowymiarowych tablicach, to dlaczego nie
> iść na całość.

Decyzji o zastosowaniu kodu natywnego nie podejmuje sie "o fajnie, kod
natywny jest szybki to go zastosujemy"

Jest wiele przypadkow kiedy wyeksportowanie kodu do kodu natywnego
przyniesie widoczny spadek wydajnosci...

Decyzje o zastosowaniu natywnych metod podejmuje sie po analizie i podjeciu
decyzji, ze to na pewno jest potrzebne...

poza tym, uzywanie tablic nie nazwalbym dzierganiem...

Pozdrawiam
Brzezi
--
[ E-mail: brz...@enter.net.pl ][ - Zycie jest jak kurwa, bo ciagle ]
[ Ekg: #3781111 ][ sie pierdoli. ]
[ LinuxUser: #249916 ][ ]

Grzegorz Brzeczyszczykiewicz

unread,
Jul 6, 2008, 12:52:45 PM7/6/08
to
Mateusz Ludwin wrote:

> pl.comp.lang.java.getSenderByName("*Grzegorz
> Brzeczyszczykiewicz*").quote();
>
>>> Bo IMHO JVM w żaden sposób sobie tego nie zoptymalizuje, a obliczenia
>>> macierzowe aż się proszą o zrównoleglenie.
>>
>> A jak będziesz jechał po tablicach to samo się zrównolegli?
>
> To istnieje szansa że tak się stanie.

Istnieje szansa, że kompilator C/C++/inny zrobi to samo co JVM.

Mateusz Ludwin

unread,
Jul 6, 2008, 12:58:33 PM7/6/08
to
pl.comp.lang.java.getSenderByName("*Grzegorz Brzeczyszczykiewicz*").quote();

>> To istnieje szansa że tak się stanie.
>
> Istnieje szansa, że kompilator C/C++/inny zrobi to samo co JVM.

To może wszystko piszmy w C++?

Grzegorz Brzeczyszczykiewicz

unread,
Jul 6, 2008, 1:02:27 PM7/6/08
to
Brzezi wrote:

> sob, 05 lip 2008 o 00:03 GMT, Grzegorz Brzeczyszczykiewicz napisał(a):
>
>>> Kiedys widzialem jakies testy wydajnosci, i akurat java nie miala
>>> problemow z operacjami na tablicach, mimo ze ma sprawdzanie
>>> przekroczenia zakresu...
>> Nie ma nic za darmo. Nie da się sprawdzić zakresu w zerowym czasie, więc
>> kod C, który tego nie robi, musi być szybszy.
>
> nie musi, moze byc, moze nie byc, sprawdzenie raczej nie jest bardzo
> kosztowne,

Nie musi trwać tak długo, aby to miało mieć znaczenie w większości
programów, ale niemożliwe jest sprawdzanie indeksów w zerowym czasie,
więc będę nadal twierdził, że kod ze sprawdzaniem _musi_ być wolniejszy.


> zreszta kod programu to nie same operacje tablicowe, wplyw na
> wydajnosc ma wiele wiecej czynnikow

W tym wątku najwyraźniej omawiamy problem, w którym operacje tablicowe
mają bardzo duże znaczenie optymalizacyjne.

>>> Poza tym, uwazam ze stosowanie kodu natywnego to jest ostatecznosc, w
>>> wyjatkowych sytuacjach, bo najczesciej przynosi wiecej szkody niz
>>> pozytku..
>> Jak już zaczynamy dziergać po wielowymiarowych tablicach, to dlaczego nie
>> iść na całość.
>
> Decyzji o zastosowaniu kodu natywnego nie podejmuje sie "o fajnie, kod
> natywny jest szybki to go zastosujemy"
>
> Jest wiele przypadkow kiedy wyeksportowanie kodu do kodu natywnego
> przyniesie widoczny spadek wydajnosci...

Jeśli do pisania w C biorą się ludzie, którzy dotychczas tylko Javę
widzieli, to z pewnością tak.

> Decyzje o zastosowaniu natywnych metod podejmuje sie po analizie i
> podjeciu decyzji, ze to na pewno jest potrzebne...

Nie jesteśmy na wykładzie z inżynierii oprogramowania. Mówimy o praktyce.
W praktyce napiszesz kod natywny dla kawałka, który:
1. wg. profilera zajmuje znaczną część wykonania programu
2. nie ma perspektyw na inny sposób optymalizacji
i sprawdzisz, czy to coś dało. Jak nie, to do kosza i szukamy dalej.

>
> poza tym, uzywanie tablic nie nazwalbym dzierganiem...

Kwestia umiejętności zobaczenia innych, bardziej eleganckich rozwiązań,
których wydajność nie zawsze jest znacząco gorsza (choć gorsza).

Michal Kleczek

unread,
Jul 6, 2008, 1:34:05 PM7/6/08
to
Grzegorz Brzeczyszczykiewicz wrote:

> Brzezi wrote:
>
>> sob, 05 lip 2008 o 00:03 GMT, Grzegorz Brzeczyszczykiewicz napisał(a):
>>
>>>> Kiedys widzialem jakies testy wydajnosci, i akurat java nie miala
>>>> problemow z operacjami na tablicach, mimo ze ma sprawdzanie
>>>> przekroczenia zakresu...
>>> Nie ma nic za darmo. Nie da się sprawdzić zakresu w zerowym czasie, więc
>>> kod C, który tego nie robi, musi być szybszy.
>>
>> nie musi, moze byc, moze nie byc, sprawdzenie raczej nie jest bardzo
>> kosztowne,
> Nie musi trwać tak długo, aby to miało mieć znaczenie w większości
> programów, ale niemożliwe jest sprawdzanie indeksów w zerowym czasie,
> więc będę nadal twierdził, że kod ze sprawdzaniem _musi_ być wolniejszy.

Dobry JVM potrafi wyeliminowac zbedne sprawdzanie indeksow.

Michal

Brzezi

unread,
Jul 6, 2008, 1:40:05 PM7/6/08
to
nie, 06 lip 2008 o 19:02 GMT, Grzegorz Brzeczyszczykiewicz napisał(a):

>> nie musi, moze byc, moze nie byc, sprawdzenie raczej nie jest bardzo
>> kosztowne,
> Nie musi trwać tak długo, aby to miało mieć znaczenie w większości
> programów, ale niemożliwe jest sprawdzanie indeksów w zerowym czasie,
> więc będę nadal twierdził, że kod ze sprawdzaniem _musi_ być wolniejszy.

wsystko zalezy, i nigdy nie pisalbym "musi", bo nie wiem jak to robi kod
skompilowany z innego jezyka, poza tym, moze zadzialac JIT/HOTSPOT, nie
wiem czy ma takie mozliwosci, ale strzelam: jezeli np. jest w stanie
przewidziec jakie wartosci sa uzywane jako indeksy, i jezeli jest pewny ze
indeksy mieszcza sie w dozwolonych granicach, to robi bezposredni dostep do
tablicy bez sprawdzania zakresu, zaznaczam ze nie wiem czy tak jest, Ty
pewnie tez, wiec uwazalbym z uzywaniem slowka "musi"...

>> Decyzji o zastosowaniu kodu natywnego nie podejmuje sie "o fajnie, kod
>> natywny jest szybki to go zastosujemy"
>>
>> Jest wiele przypadkow kiedy wyeksportowanie kodu do kodu natywnego
>> przyniesie widoczny spadek wydajnosci...
> Jeśli do pisania w C biorą się ludzie, którzy dotychczas tylko Javę
> widzieli, to z pewnością tak.

Tu nie chodzi o sam kod w C, bo nawet 100 razy wydajniejszy kod w C, po
zastosowaniu przez JNI moze bardzo wydatnie spowolnic aplikacje, nie
wszystko nadaje sie na wydelegowanie do kodu natywnego, poniewaz JNI ma
spory narzut wydajnosci...

>> Decyzje o zastosowaniu natywnych metod podejmuje sie po analizie i
>> podjeciu decyzji, ze to na pewno jest potrzebne...
> Nie jesteśmy na wykładzie z inżynierii oprogramowania. Mówimy o praktyce.
> W praktyce napiszesz kod natywny dla kawałka, który:
> 1. wg. profilera zajmuje znaczną część wykonania programu

nie zgodze, sie patrz co napisalem wyzej

> 2. nie ma perspektyw na inny sposób optymalizacji
> i sprawdzisz, czy to coś dało. Jak nie, to do kosza i szukamy dalej.

czasami, a nawet napisalbym ze czesto, przy najpopularniejszych aplikacjach
biznesowych, wazniejsze znaczenie ma czas wytwarzania aplikacji, niz
roznica na poziomie 5% w wydajnosci, oczywiscie nie mam na mysli skrajnego
przypadku gdzie liczy sie tylko czas klepania kodu bez uwagi na wydajnosc,
oraz gdzie wydajnosc jest wymaganiem systemu...

poza tym, zastosowanie JNI jest dosyc klopotliwe, na kazdy system, na kazda
architekture trzeba przygotowywac jak nie osobny, badz sprofilowany kod(bo
jak cos sie ladnie kompiluje pod linuxem, to nie znaczy ze ladnie sie
skompiluje pod win czy solarisem), to na pewno skompilowane natywne binarki
dla kazdego przewidzianego systemu...

kolejna sprawa, kod natywny srednio chyba nadaje sie do systemow
rozproszonych, tam problem wydajnosciowe rowziazuje sie inaczej niz przez
klepanie w C...

Ja zastosowalbym JNI, lub wrecz nawet zaczynal sie tym
interesowac dopiero tylko gdy:
1. Kluczowym wymaganiem jest wydajnosc
2. architektura sytemu zezwala na stosowanie JNI
3. jest wysoka szansa na znaczne przyspiesznie (a nie 5%)
wykrytego waskiego gardla wydajnosci...
4. trzeba zintegrowac sie z biblioteka ktora nie ma wersji javowej

Do tej pory raz MUSIALEM napisac kod w JNI, tylko w celach "naukowych", i
wiem ze to nie jest wygodne, i niesie ze soba wiele komplikacji...

moja rada: jezeli NIE MUSISZ pisac kodu w JNI, to najelpiej omijac to...

>> poza tym, uzywanie tablic nie nazwalbym dzierganiem...
> Kwestia umiejętności zobaczenia innych, bardziej eleganckich rozwiązań,
> których wydajność nie zawsze jest znacząco gorsza (choć gorsza).

byte[] buf = new byte[BUF_SIZE];
in.read(buf);

hmmm jak inaczej zastapic tutaj uzycie tablic? :)

Pozdrawiam
Brzezi
--
[ E-mail: brz...@enter.net.pl ][ ]
[ Ekg: #3781111 ][ ]
[ LinuxUser: #249916 ][ ]

Grzegorz Brzeczyszczykiewicz

unread,
Jul 6, 2008, 1:54:57 PM7/6/08
to
Mateusz Ludwin wrote:

> pl.comp.lang.java.getSenderByName("*Grzegorz
> Brzeczyszczykiewicz*").quote();
>
>>> To istnieje szansa że tak się stanie.
>>
>> Istnieje szansa, że kompilator C/C++/inny zrobi to samo co JVM.
>
> To może wszystko piszmy w C++?

Jeśli wydajność jest aż tak kluczowa, że musimy tworzyć potworki
w rodzaju wielowymiarowych tablic, to nie ma już żadnego powodu,
żeby pozostawać przy ładnej Javie.

Grzegorz Brzeczyszczykiewicz

unread,
Jul 6, 2008, 1:57:41 PM7/6/08
to
CIACH NA WSZYSTKIM :-)

Zaczęło się od tablic wielowymiarowych i związanych z nią zajebistą
wydajnością, która nie może być zmarnowana poprzez opakowanie tego metodami.

Nie zbaczajmy więc z tego tematu w kierunku normalności i nie zabijaj moich
argumentów normalnymi przykładami: zabij je takim potworkiem jak twórca
wątku.

Grzegorz Brzeczyszczykiewicz

unread,
Jul 6, 2008, 1:58:08 PM7/6/08
to
Michal Kleczek wrote:

Ale robi to w run-time'ie, czyli jakiś czas musi zmarnować.

Mateusz Ludwin

unread,
Jul 6, 2008, 2:04:17 PM7/6/08
to
pl.comp.lang.java.getSenderByName("*Grzegorz Brzeczyszczykiewicz*").quote();

>> To może wszystko piszmy w C++?


>
> Jeśli wydajność jest aż tak kluczowa, że musimy tworzyć potworki
> w rodzaju wielowymiarowych tablic, to nie ma już żadnego powodu,
> żeby pozostawać przy ładnej Javie.

A o obliczeniach numerycznych w Javie słyszałeś?

Michal Kleczek

unread,
Jul 6, 2008, 2:13:01 PM7/6/08
to
Grzegorz Brzeczyszczykiewicz wrote:

>>
>> Dobry JVM potrafi wyeliminowac zbedne sprawdzanie indeksow.
>
> Ale robi to w run-time'ie, czyli jakiś czas musi zmarnować.
>

Nie ma obowiazku robic tego w czasie wykonania.

Michal

Mikolaj Rydzewski

unread,
Jul 7, 2008, 2:58:09 AM7/7/08
to
jolz wrote:
> Najlepszym jaki znam. Ale trzeba pamietac ze:
> - k_tab[0] moze rzucic ArrayIndexOutOfBoundsException

Mozesz rozwinac? W ww przypadku k_tab[0] wskazuje na String[][].

artur.z...@gmail.com

unread,
Jul 7, 2008, 3:23:33 AM7/7/08
to
hpnx6125-laptop1% cat Foo.java
public class Foo {
public static void main(String[] args) {
String[][] a = new String[0][100];
System.out.println(a[0].length);
}
}
hpnx6125-laptop1% java Foo
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
at Foo.main(Foo.java:4)

Ktoś kodu takiego nie napisze ale rzucenie wyjątku jest możliwe ;-)

--
Pozdrawiam,
Artur

Mateusz Ludwin

unread,
Jul 7, 2008, 5:14:58 AM7/7/08
to
artur.z...@gmail.com wrote:

> hpnx6125-laptop1% java Foo
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at Foo.main(Foo.java:4)
>
> Ktoś kodu takiego nie napisze ale rzucenie wyjątku jest możliwe ;-)

Taki przypadek jak najbardziej może wystąpić (np coś się nie wczytało i
w efekcie macierz ma rozmiary 0x0).
--
Sprawdź, czy twój kot jest POLAKIEM!

Grzegorz Brzeczyszczykiewicz

unread,
Jul 7, 2008, 12:33:07 PM7/7/08
to
Mateusz Ludwin wrote:

> pl.comp.lang.java.getSenderByName("*Grzegorz
> Brzeczyszczykiewicz*").quote();
>
>>> To może wszystko piszmy w C++?
>>
>> Jeśli wydajność jest aż tak kluczowa, że musimy tworzyć potworki
>> w rodzaju wielowymiarowych tablic, to nie ma już żadnego powodu,
>> żeby pozostawać przy ładnej Javie.
>
> A o obliczeniach numerycznych w Javie słyszałeś?

A czym się one różnią od "obliczeń numerycznych" w dowolnym
innym języku?
I dlaczego zaszufladkowanie czegokolwiek pod słowo-wytrych miałoby
usprawiedliwiać brzydki styl kodowania bez zastanowienia się, czy wydajność
jest aż tak kluczowa?

Mateusz Ludwin

unread,
Jul 7, 2008, 1:35:01 PM7/7/08
to
pl.comp.lang.java.getSenderByName("*Grzegorz Brzeczyszczykiewicz*").quote();

>> A o obliczeniach numerycznych w Javie słyszałeś?
>
> A czym się one różnią od "obliczeń numerycznych" w dowolnym
> innym języku?

Ano tym, że możliwe jest przesyłanie do serwera obliczeniowego bytecodu
zawierającego zadania obliczeniowe.

> I dlaczego zaszufladkowanie czegokolwiek pod słowo-wytrych miałoby
> usprawiedliwiać brzydki styl kodowania bez zastanowienia się, czy wydajność
> jest aż tak kluczowa?

Powiedz jeszcze fortranowcom że mają brzydki styl programowania...

Grzegorz Brzeczyszczykiewicz

unread,
Jul 7, 2008, 1:43:36 PM7/7/08
to
Mateusz Ludwin wrote:

> Powiedz jeszcze fortranowcom że mają brzydki styl programowania...

Dlatego nie pisuję na pl.comp.lang.fortran.

Przemysław Kowalczyk

unread,
Jul 7, 2008, 1:38:09 PM7/7/08
to
On Mon, 07 Jul 2008 19:35:01 +0200, Mateusz Ludwin <n...@spamuj.org> wrote:
>
> Powiedz jeszcze fortranowcom że mają brzydki styl programowania...

a co, moze ladny? :)

pzdr
szeryf

--
Przemysław ,,Szeryf'' Kowalczyk :: http://szeryf.wordpress.com/

0 new messages