Język C / C++ / C# / Java - pytania, problemy...

[Olamagato 3]

Dnia 24.06.2008 o 20:37, Logan10 napisał:

Ajjj przepraszam ,zapomniałem dodać że to co c++ sorki wielkie :/

Hehehe. No to nie stawiaj nigdy spacji przed pytajnikiem (to na marginesie jest błąd ortograficzny).

Skoro chodzi Ci o typy unsigned, to różnią się one tylko interpretacją drukowania. Typy signed i unsigned nie różnią się matematycznie niczym. Nawet dodawaniem ponieważ kod U2 ma to do siebie, że liczby ujemne oprócz ustawionego najstarszego bitu mają zasadniczo odwrócone wartości bitów. Zmiana znaku liczby polega na odwróceniu bitów oraz pojedynczej inkrementacji (działa to w obie strony). Operacje dodawania i odejmowania dają te same wyniki w bitach niezależnie od tego czy liczba jest interpretowana jako binarna bez znaku czy U2. Operacje mnożenia i dzielenia stałoprzecinkowego chyba również.

Gdybyś zwiększył liczbę 01111111 (127) o 1, to powstający kod 10000000 można interpretować zarówno jako 128 licząc wszystkie 8 bitów, albo -128 licząc 7 bitów ze znakiem.
Podobnie zwiększając liczbę 11111111 (255, albo -1 w U2) dostajemy [1]00000000 z czego nadmiarowe 1 albo jest odrzucane - i w arytmetyce 8-bitowej jest to zawsze zero - albo nie jest i jest to liczba 256 w arytmetyce 16-bitowej lub wyższej.

[Olamagato 3]

Dnia 25.06.2008 o 10:32, Nufiko napisał:

na 3 bitach 111 to -2^2+2+1=-4+3=-1 czyli ok

Wszystko OK. Trzeba tylko zwracać uwagę , że o ile w arytmetyce bez znaku oraz u liczb dodatnich można sobie skrócić wiodące zera bez szkody dla wartości, o tyle dla liczb ujemnych w U2 obcinać można tylko wiodące jedynki (bo dla liczb ujemnych w U2 nieznaczące są jedynki, a znaczące zera).

[LifaR 0]

Dnia 25.06.2008 o 10:32, Nufiko napisał:

Ja jednak twierdzę, że jest dobrze. Za twoim przykładem na 4 bitach: 1111 to -2^3+2^2+2+1=-8+7=-1 na 3 bitach 111 to -2^2+2+1=-4+3=-1 czyli ok

-2^2 = 4, a nie -4, bo -2* -2 = 4 :) No chyba ze ja jakos inaczej rozumuje Twoj zapis niz Ty, co tez jest mozliwe :)

Olamagato

Dnia 25.06.2008 o 10:32, Nufiko napisał:

Operacje dodawania i odejmowania dają te same wyniki w bitach niezależnie od tego czy liczba jest interpretowana jako binarna bez znaku czy U2. Operacje mnożenia i dzielenia stałoprzecinkowego chyba również.

- Nie, operacje mnozenia i dzielenia staloprzecinkowego maja calkiem inne algorytmy dla dzialan w systemach uzupelnieniowych, w zwiazku z czym moga dawac inne bitowo wyniki. Przyklad: 1101011*1000110, w NKB daje wynik 1110101000010, a w U2 daje wynik 10011000010. Bierze sie to stad, ze wazne jest rozszerzenie nieskonczone liczby, ktore w NKB jest zawsze 0, a w U2 jest czasem 0, czasem 1 i trzeba to uwzglednic wykonujac dane dzialanie.

>Gdybyś zwiększył liczbę 01111111 (127) o 1, to powstający kod 10000000 można interpretować zarówno jako 128 licząc wszystkie 8 bitów, albo -128 licząc 7 bitów ze znakiem.
- Nie wiem dlaczego chcialbys liczbe w systemie U2 na 8 bitach, traktowac jako znak+7bitow - to nie jest reprezentacja typu znak-modul, lub inna podobna. Poza tym, 01111111 + 01 w systemie U2, da bitowo wynik 10000000, ale dodatkowo ustawi flage nadmiaru, bo przeniesienie na dwoch najwyzszych pozycjach jest rozne, wiec zinterpretowanie wyniku jako -128 bedzie swiadczylo o duzym niechlujstwie programisty (i taka interpretacja doprowadzi po prostu do otrzymania blednego wyniku).

[LifaR 0]

Dnia 25.06.2008 o 13:38, LifaR napisał:

Przyklad: 1101011*1000110, w NKB daje wynik 1110101000010, a w U2 daje wynik 10011000010.

- Oczywiscie popelnilem blad :) Brakuje zera przed liczba w U2, pomnozenie dwoch liczb ujemnych powinno dawac liczbe dodatnia ;)
Prawidlowa wersja:
Przyklad: 1101011*1000110, w NKB daje wynik 1110101000010, a w U2 daje wynik 010011000010.

[Nufiko 0]

Dnia 25.06.2008 o 13:38, LifaR napisał:

> Ja jednak twierdzę, że jest dobrze. Za twoim przykładem na 4 bitach: 1111 to -2^3+2^2+2+1=-8+7=-1
na 3 bitach 111 to -2^2+2+1=-4+3=-1 czyli ok
-2^2 = 4, a nie -4, bo -2* -2 = 4 :) No chyba ze ja jakos inaczej rozumuje Twoj zapis
niz Ty, co tez jest mozliwe :)

Mnie zawsze uczyli że -2^2 jest różne niż (-2)^2, bo z pierwszego wyjdzie (-1)*2^2=(-1)*4=-4 a z drugiego wyjdzie (-2)*(-2)=4

[LifaR 0]

Dnia 25.06.2008 o 16:15, Nufiko napisał:

Mnie zawsze uczyli że -2^2 jest różne niż (-2)^2, bo z pierwszego wyjdzie (-1)*2^2=(-1)*4=-4 a z drugiego wyjdzie (-2)*(-2)=4

- Rozne szkoly matematyczne ;) Ja jestem przyzwyczajony do tego, ze jesli chcemy zanegowac jakies dzialanie, to by zapis byl jednoznacznie interpretowalny, bierzemy to dzialanie w nawias, wiec odpowiednio byloby to -(2^2). A jak mnie uczono, nie powiem, bo nie pamietam, zaliczylem w swoim zyciu kilka szkol w zwiazku z przeprowadzkami, ale na pewno w ktorejs pojawila interpretacja podana przez Ciebie :)
W takim razie przepraszam, jesli przyjac Twoja interpretacje to wzor faktycznie byl dobry.

[Olamagato 3]

Dnia 25.06.2008 o 13:38, LifaR napisał:

Przyklad: 1101011*1000110, w NKB daje wynik 1110101000010, a w U2 daje wynik 010011000010.

Tak. Tyle, że jeżeli mówisz o arytmetyce binarnej i jako przykład podajesz mnożenie dwóch liczb siedmiobitowych, to trzymaj się tych siedmiu bitów - dokładnie tak jak robi to procesor.
A procesor pracuje na ograniczonej liczbie bitów. W przypadku przykładu, który podałeś po obcięciu wyniku do siedmiu bitów wyniki w obu interpretacjach są identyczne. Oczywiście, że występuje nadmiar, który jest sygnalizowany na flagach procesora. Tylko znajdź mi kompilator, który generując kod z zasady nie olewa rejestru znaczników. A o ile znam standardy języka C, C++, Javy - żaden z nich nie uwzględnia tego typu informacji. Ba, w ogóle nie informuje programisty, że dzieje się coś złego. W każdym z języków ordynarnie obcina się bity do konkretnej ilości i nic więcej.
Dlatego będąc praktykiem i rozmawiając w praktycznym wątku twierdzę, że operacje dają te same wyniki bitowe niezależnie od interpretacji tych bitów. To jest dokładnie taka sama arytmetyka. Procesor nie różnicuje tych operacji - są one maszynowo identyczne, a wyniki są interpretowane przez program albo jako liczba ze znakiem, albo "nieco szersza" bez znaku. Fakty jakie pojawiają się w maszynach potwierdzają to co napisałem. Generalnie masz rację - tyle, że w arytmetyce o nieskończonej liczbie bitów (precyzji). A takiej języki o której rozmawiamy nie udostępniają w standardzie. Można je dopiero uzyskać za pomocą bibliotek - nawet standardowych takich jak klasa BigInteger w Javie.
Arytmetyka w U2 musi odnosić się do stałej i tej samej liczby bitów ponieważ bez uwzględniania tego warunku wszelkie interpretacje tracą sens. Masz rację co do teorii, ale w komputerze - szczególnie w odniesieniu do języka C/C++, Javy i C# stosuje się praktykę taka jaka ona jest.

Dnia 25.06.2008 o 13:38, LifaR napisał:

Nie wiem dlaczego chcialbys liczbe w systemie U2 na 8 bitach, traktowac jako znak+7bitow - to nie jest reprezentacja typu znak-modul, lub inna podobna.

Nic takiego nie napisałem. Jedynie to, że ustawiony najbardziej znaczący bit oznacza zawsze liczbę ujemną w U2 oraz jak najprościej odwracać znak liczby. Oczywiście zakładając, że liczbę traktujemy jako ze znakiem. Na przykład procesory RISC nie różnicują liczb binarnych na te ze znakiem i te bez. Operacje stałoprzecinkowe są te same.

Dnia 25.06.2008 o 13:38, LifaR napisał:

01111111 + 01 w systemie U2, da bitowo wynik 10000000, ale dodatkowo ustawi flage nadmiaru

Zgadza się. Ale pod warunkiem, że mówisz o procesorze 7-bitowym z czasów wprost starożytnych (dekada 1970). Flaga nadmiaru jest faktycznie ustawiana dopiero gdy musiałby być ustawiony bit poza rejestrem - w starszych procesorach bit ten był technicznie przedłużeniem akumulatora.
Jeżeli chciałbyś udowodnić, że masz rację, to musiałbyś napisać banalny programik, który inkrementuje w akumulatorze 0x7fff i następnie wyrzuca stan flagi nadmiaru (zależnie od procesora programik będzie się minimalnie różnił). Ja taki programik napisałem i niestety żaden ze współczesnych procesorów nie raportuje nadmiaru. Raportuje go dopiero przy inkrementacji 0xffff. Oczywiście żadna sprzętowa inkrementacja lub dekrementacja nie ustawia najczęściej żadnych flag (w większości procesorów i wszystkich do jakich obecnie mam dostęp). W tym celu zwyczajnie dodawałem lub odejmowałem 0x0001.

Dnia 25.06.2008 o 13:38, LifaR napisał:

zinterpretowanie wyniku jako -128 bedzie swiadczylo o duzym niechlujstwie programisty

Przecież wyraźnie napisałem, że chodzi o zmianę znaku, więc o żadnym niechlujstwie nie ma mowy. Programista może mieć jakieś powody, aby "w kółko" generować cykle -128..+127, które równie dobrze można interpretować jako 8-bitowe liczby bez znaku (128..127).

Dnia 25.06.2008 o 13:38, LifaR napisał:

(i taka interpretacja doprowadzi po prostu do otrzymania blednego wyniku)

O tym co jest błędnym wynikiem operacji, decyduje zawsze programista, a nie jakieś odgórne teorie.
Np. Z takiego właśnie powodu zamiast bardzo czasochłonnej operacji mov ax,0 używa się po prostu xor ax,ax.

[Olamagato 3]

Dnia 25.06.2008 o 16:47, LifaR napisał:

- Rozne szkoly matematyczne ;)

-x^2 ≠ -(x^2).

[LifaR 0]

> Tak. Tyle, że jeżeli mówisz o arytmetyce binarnej i jako przykład podajesz mnożenie dwóch liczb siedmiobitowych, to trzymaj się tych siedmiu bitów - dokładnie tak jak robi to procesor.
- ? Przeciez korzystajac z procesorow np. 32 bitowych mozemy mnozyc liczby 7 bitowe - oczywiscie zostana one odpowiednio rozszerzone, dla wygody pominalem nic nie znaczace rozszerzenia nieskonczone obu liczb.

> Tylko znajdź mi kompilator, który generując kod z zasady nie olewa rejestru znaczników.
- Tego nie wskaze, bo az tak sie tym tematem nie interesuje niestety. Mialem na mysli raczej programowanie niskopoziomowe, gdzie sobie odpowiednie flagi mozna samemu sprawdzac i interpretowac liczby zapisane binarnie tak jak nam sie tylko podoba, samemu wybierajac czy interesuje nas nadmiar, przeniesienie, przeniesienie polowkowe itp.

> Arytmetyka w U2 musi odnosić się do stałej i tej samej liczby bitów ponieważ bez uwzględniania tego warunku wszelkie interpretacje tracą sens.
- To rownie dobrze moglbys napisac, ze nie ma sensu mnozenie dwoch liczb np. 7-bitowych, bo wynik zawsze bedzie zapisany na wiekszej ilosci bitow, wiec srednio polowe informacji (bitow) tracimy :)

> Zgadza się. Ale pod warunkiem, że mówisz o procesorze 7-bitowym z czasów wprost starożytnych (dekada 1970). Flaga nadmiaru jest faktycznie ustawiana dopiero gdy musiałby być ustawiony bit poza rejestrem - w starszych procesorach bit ten był technicznie przedłużeniem akumulatora.
- Chyba mowimy o czym innym - bo czym innym jest nadmiar dla liczb zapisanych w U2, a czym innym przeniesienie dla liczb zapisanych w NKB. To ze musialby byc ustawiony w wyniku dzialania bit poza rejestrem oznacza przeniesienie dla liczb w NKB, ale nie musi oznaczac nadmiaru dla liczb w U2. A co do procesora - fakt, nie sprawdzalem na zadnej maszynie uzywanej wspolczesnie w domach, ale 8051 tez sie chyba liczy ? ;) - Ma rejestry akurat 8-bitowe :)
Bo jesli liczbe zapiszemy na wiekszej ilosci bitow to bedziemy miec 0...01111111+0...01 a w wyniku otrzymamy 0...010000000 i nie ma wtedy zadnego nadmiaru.

> Oczywiście żadna sprzętowa inkrementacja lub dekrementacja nie ustawia najczęściej żadnych flag (w większości procesorów i wszystkich do jakich obecnie mam dostęp).
- Ponownie jako przyklad moge podac byc moze znaczeniowo pomijalny 8051 ktory jednak to robi.

> Programista może mieć jakieś powody, aby "w kółko" generować cykle -128..+127, które równie dobrze można interpretować jako 8-bitowe liczby bez znaku (128..127).
- Owszem, przyznaje racje. Byc moze pominalem jakis fragment Twojej wypowiedzi i spojrzalem jedynie na dzialanie. I byc moze za bardzo skupilem sie na teorii :)

> O tym co jest błędnym wynikiem operacji, decyduje zawsze programista, a nie jakieś odgórne teorie.
- Przeciez napisalem to samo m.in. w kontekscie flag :)

[LifaR 0]

Dnia 02.07.2008 o 14:21, Olamagato napisał:

> - Rozne szkoly matematyczne ;)
-x^2 ≠ -(x^2).

- Taka tez interpretacje ja przeciez przyjalem - i jesli przyjac taka interpretacje, to Nufiko podal jednak wczesniej bledny algorytm, na wyliczanie wartosci liczby w U2, a poprawny jest dopiero po mojej korekcie :)

[Vel_Grozny 0]

Dnia 03.07.2008 o 12:32, LifaR napisał:

- Taka tez interpretacje ja przeciez przyjalem - i jesli przyjac taka interpretacje,
to Nufiko podal jednak wczesniej bledny algorytm, na wyliczanie wartosci liczby w U2,
a poprawny jest dopiero po mojej korekcie :)

-2^2 = -4.
Potęgowanie ma wyższy priorytet od odejmowania. (-2)^2 = 4 z kolei.

W Twoim wcześniejszym poście widzę, że podałeś odwrotnie.

[LifaR 0]

Dnia 03.07.2008 o 16:41, Vel Grozny napisał:

W Twoim wcześniejszym poście widzę, że podałeś odwrotnie.

- Czyli ostatecznie, Olamagato myli sie piszac -x^2 ≠ -(x^2) ? Banalny problem, a widac ze z banalami mam najwiekszy problem, niestety. A przyjalem odwrotnie bo nie odnosilem sie do jakiejs zmiennej, tylko konkretnej jej wartosci za ktora wzialem, byc moze blednie -2.

[Vel_Grozny 0]

Dnia 03.07.2008 o 20:17, LifaR napisał:

- Czyli ostatecznie, Olamagato myli sie piszac -x^2 ≠ -(x^2) ? Banalny problem,
a widac ze z banalami mam najwiekszy problem, niestety. A przyjalem odwrotnie bo nie
odnosilem sie do jakiejs zmiennej, tylko konkretnej jej wartosci za ktora wzialem, byc
moze blednie -2.

Jak za x podstawimy ujemną wartość, to wiadomo, że nie zostanie to rozbite i efekt będzie taki jakby napisać (-2) (x weźmie się "samo" w nawias)
Ale to nie jest to samo, co wzięcie x=2 i napisanie przed nim minusa.

[Olamagato 3]

Dnia 03.07.2008 o 12:29, LifaR napisał:

- Chyba mowimy o czym innym - bo czym innym jest nadmiar dla liczb zapisanych w U2, a czym innym przeniesienie dla liczb zapisanych w NKB.

Zgadzam się. Dlatego oba te stany są przedstawiane innymi bitami znaczników. Rzadko bo rzadko, ale może powstać sytuacja w której na ciągu operacji zostaną ustawione oba te znaczniki bez kasowania.

Dnia 03.07.2008 o 12:29, LifaR napisał:

Bo jesli liczbe zapiszemy na wiekszej ilosci bitow to bedziemy miec 0...01111111+0...01
a w wyniku otrzymamy 0...010000000 i nie ma wtedy zadnego nadmiaru.

Oczywiście. Bo nadmiar występuje dopiero gdy tracimy informację w wyniku operacji. Jeżeli operacja przebiegła bez jej utraty, to żadne znaczniki nie są ustawiane.

Dnia 03.07.2008 o 12:29, LifaR napisał:

- Ponownie jako przyklad moge podac byc moze znaczeniowo pomijalny 8051 ktory jednak to robi.

Jesteś tego pewien? Bo inne starożytne procesory 8-bitowe (Z80, Intel 8080) zasadniczo nie ustawiały flag na inc/dec z tego właśnie powodu, że operacje te były używane często jako elementy kilkuoperandowych operacji (w tym zmiany znaku - która z zasady nie ustawia flag).
Z tego co wiem, to również nie robią tego współczesne procesory 32/64-bitowe.
I tak na marginesie na czym Ci ten procesor działa? Jakiś kalkulator?

[Olamagato 3]

Dnia 03.07.2008 o 20:17, LifaR napisał:

> W Twoim wcześniejszym poście widzę, że podałeś odwrotnie.
- Czyli ostatecznie, Olamagato myli sie piszac -x^2 ≠ -(x^2)?

Masz rację - pomyliłem się. Z rutyny zasugerowałem się dwójką. Miałem napisać -x^y ≠ -(x^y). Wtedy dopiero jest to prawdziwe. Dla kwadratów i potęg parzystych jest to równość.

[LifaR 0]

Dnia 04.07.2008 o 09:44, Olamagato napisał:

Jesteś tego pewien?

- Nie, przepraszam za wprowadzenie w blad. Sprawdzilem i okazalo sie, ze nieumyslnie wprowadzilem Cie w blad, instrukcje inkrementacji i dekrementacji, nie zmieniaja flag przeniesienia i nadmiaru. Nie wiem skad mi sie wziela tam ta bledna informacja.

Dnia 04.07.2008 o 09:44, Olamagato napisał:

I tak na marginesie na czym Ci ten procesor działa? Jakiś kalkulator?

- Nie, taki w zasadzie dydaktyczny zestaw do nauki programowania mikrokontrolerow, podstaw asemblera itp. Choc kolega, wykorzystuje 8051 do budowy swojego domowego oscyloskopu ;)

A co do dzialania -x^y ≠ -(x^y), z tego co pisze Vel Grozny, to jednak tez, tak jak i ja, nie masz racji. Latwo to zreszta sprawdzic w internecie - Vel ma racje, ze potegowanie ma pierwszenstwo przed znakiem "minus", a wiec:
-x^y = -(x^y) [bo dzialanie -x^y takze najpierw wykona potegowanie, a dopiero pozniej "dolozy" do wyniku "minus", zupelnie tak samo, jak wersja z nawiasami]. Moglem sprawdzic od razu, zamiast sie spierac :)

[Olamagato 3]

Dnia 04.07.2008 o 15:49, LifaR napisał:

-x^y = -(x^y) [bo dzialanie -x^y takze najpierw wykona potegowanie, a dopiero pozniej "dolozy" do wyniku "minus"

Sprawa rozbija się o interpretację zapisu. Mi pisząc -x^y chodziło ściśle o wyrażenie (-x)^y czyli o zanegowanie podstawy (a o to się przecież rozbija w U2). Natomiast w sensie kolejności działań Vel Grozny ma oczywiście rację.

Łatwo to sprawdzić dla y = 2:
x = 2: (-2)^2 = 4, a -(2^2) = -4. Nie ma tu równości. Przy x = -2: (-(-2))^2 = 4, a -(-2^2) = -4. Również nie ma.
Dla y = 3 mamy:
x = 2: (-2)^3 = -8, a -(2^3) = -8. Równość. Dla x = -2: (-(-2))^3 = 8, a -(-2^3) = 8. Równość.

Przy okazji oczywiście machnąłem się mówiąc, że (z poprawką zapisu) nierówność (-x)^2 ≠ -(x^2) jest prawdziwa dla parzystych. Jest dokładnie odwrotnie.

Zabawne te zadania z odwracaniem znaku. Pomylisz się nieparzystą liczbę razy i kicha, pomylisz się parzystą liczbę i też kicha - tyle, że trudniejsza do wykrycia bo wynik bywa ok.

Trzeba tylko życzyć konsekwencji maturzystom, którzy po 20 latach znowu będą mieli obowiązkową maturę z matmy. :)

[Olamagato 3]

Ciekawa alternatywa dla sprawdzenia czy jeden ze znaków (tu: /,-,=,:) znajduje się w tekście pod konkretnym indeksem. Przydaje się do parsowania. Tekst, to dowolny obiekt, który implementuje interfejs CharSequence lub pochodzi od klasy Segment.

Java:
Boolean czy_pod_indeksem_jest_jeden_ze_znaków =
"/-=:".indexOf(tekst.charAt(indeks)) >= 0;

Składnia nieco nieczytelna, ale pomysł polega na sprawdzeniu czy ciąg znaków, który wpisujemy jako stałą (a może być i zmienną) zawiera jeden konkretny znak w określonym miejscu tekstu. Bardzo to skraca różne konstrukcje z dotychczasowym użyciem instrukcji switch testującej konkretny znak w tekście.

W C++ podobna konstrukcja jest mniej wygodna i wymusza użycie jawnej zmiennej automatycznej (x):
string x("/-=:");
int czy_pod_indeksem_jest_jeden_ze_znaków =
x.find(tekst.at(indeks) != string::npos;

To już wygodniej jest użyć konstrukcji z gołego C:
int czy_pod_indeksem_jest_jeden_ze_znaków =
strchr("/-=:", tekst[indeks]) != NULL;

[Logan10 0]

Pojęcie "prog. obiektowe" od "strukturalnego" czym sie różni ?

[Olamagato 3]

Dnia 02.09.2008 o 19:52, Logan10 napisał:

Pojęcie "prog. obiektowe" od "strukturalnego" czym sie różni ?

Tym, że w strukturalnym kod operuje na zestrukturyzowanych danych, czyli danych zebranych w tablice, rekordy/struktury. A w obiektowym kod operuje zasadniczo tylko na danych swojego obiektu. Krótko mówiąc w strukturalnym dowolny kod może obrabiać dowolne dane, a w obiektowym konkretny kod może przetwarzać tylko konkretne dane. W ten sposób obiekty są zamkniętymi całościami. W programowaniu strukturalnym łatwiej się pomylić i jakiś kod może zacząć przetwarzać nie te dane, które powinien.