m...@t...pl wrote:
>
>> Proponowałbym Prolog. Dlaczego? Jest zupełnie inny niż C/C++ .
> A Python? Słynie z tego ze się w nim popełnia mało błędów.
> Prologa nie znam (pythona zresztą też nie), czy prolog nadaje
> się w ogóle do rzeczy typu: sortowanie tablicy, mnożenia macierzy?
... moge sie pod tym podpisac, ale sa rozne zdania na ten temat;-)
Z powazaniem
Adam Przybyla

do góry

> On Sat, 13 Aug 2011 21:09:15 +0200, "Marszalkowski" <m...@t...pl>


> Przygotuj po prostu dane wejsciowe i popatrz czy dane wyjsciowe sie
> zgadzaja. W koncu chyba blad jest pojeciem obiektywnym w stosunku do
> przetwarzania danych.
Bym chcial...
Pozdrawiam


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> m...@t...pl wrote:

> >>> W C i w C++ od dawna jest arytmetyka wskaźników, polega ona np. na
> >>> dodaniu do wskaźnika zmiennej typu int. Od zawsze w programach
> >>> wymagających wydajności znajdowały się w nich ujemne wartości
> >> Bzdura
> > To że Panu nie przyszedł do głowy żaden pomysł na wykorzystanie
> > ujemnych indeksów nie oznacza jeszcze że to jest bzdurą :)

> Kwestia ujemnych/dodatnich indeksów to tylko kwestia czysto kosmetyczna.
> Nie wpływa na wydajność. Tutaj akurat, wyjątkowo, z A.L. się zgadzam.
Kompilator i mój stoper od pomiaru czasu wykonania nie zgadzają się z Wami
Panowie. Jeśli algorytm produkuje czasami ujemną liczbę to zawsze szybciej
jest użyć ujemnego indeksu niż testować ifem czy zakres jest dodatni. Tyle
że pod ujemnym indeksem nie może być śmieci...
Pozdrawiam




--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On Tue, 16 Aug 2011 23:24:28 +0200, m...@t...pl wrote:

>> On Sat, 13 Aug 2011 21:09:15 +0200, "Marszalkowski" <m...@t...pl>
>
>
>> Przygotuj po prostu dane wejsciowe i popatrz czy dane wyjsciowe sie
>> zgadzaja. W koncu chyba blad jest pojeciem obiektywnym w stosunku do
>> przetwarzania danych.
>Bym chcial...

Jezeli nie jestes w stanie tego zrobic, to znaczy, ze program jest
nieweryfikowalny jako taki. Napisanie drugiego programu niewiele tu
poprawi, beda dzialaly tak samo, lub roznie, to wszystko czego sie
dowiesz.

milego dnia, hej
--
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

do góry

> On Tue, 16 Aug 2011 23:24:28 +0200, m...@t...pl wrote:

> >> Przygotuj po prostu dane wejsciowe i popatrz czy dane wyjsciowe sie
> >> zgadzaja. W koncu chyba blad jest pojeciem obiektywnym w stosunku do
> >> przetwarzania danych.
> >Bym chcial...

> Jezeli nie jestes w stanie tego zrobic.
Jestem w stanie, ale bym musiał zbyt długo patrzeć zanim bym wykonał w
myślach miliony operacji arytmetyczno-logicznych.
Pozdrawiam


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On 2011-08-16 22:27, Maciej Sobczak wrote:
> On Aug 16, 8:27 am, Michal Kleczek<k...@p...onet.pl> wrote:
>
>> Dobre.
>> Ale nieprawdziwe :)
>
> Sprawdziłeś?
>
>> Java rzuci ClassCastException na pierwszym add (fakt - w runtime).
>
> To ja mam zepsutą Javę (1.6.0), bo u mnie rzuca dopiero na drugim add.
>
>> 1. Wymaga tego specyfikacja TreeSet.add()
>
> Wg. dokumentacji (6) wyjątek leci "if the specified object cannot be
> compared with the elements currently in this set ". Czyli jeśli zbiór
> jest pusty, to ma nie lecieć.
>
>> 2. Zweryfikowalem zrodla
>
> W jakiej wersja Javy?

1.7
TreeMap:
public V put(K key, V value) {
Entry<K,V> t = root;
if (t == null) {
compare(key, key); // type (and possibly null) check
...
}


>
>> ktorej put() w przypadku gdy mapa jest pusta probuje porownac klucz sam
>> ze soba (wlasnie w celu zweryfikowania typu).
>
> I to ma być "statyczna kontrola typów"? Porównywanie obiektu samego ze
> sobą w run-time?
> Ale jaja. :-D
>
>> API _zawsze_ mozna spieprzyc
>
> To nie jest kwestia API. TreeSet<NonComparable> jest bez sensui w
> poważnym języku można to sprawdzić *od razu*. Nawet bez dostępu do
> implementacji klasy TreeSet.

TreeSet<NonComparable> _nie_ jest bez sensu, bo mozna uzyc Comparatora
zeby porownac elementy. Problem lezy w tym, ze Klasa TreeSet istniala
przed wprowadzeniem generykow (i trzeba bylo zachowac konstruktory).

Wyobraz sobie, ze TreeSet wyglada tak:
public class TreeSet<T> {
protected TreeSet() {...}
protected TreeSet<Comparator<? super T>>() {...}

public static <T extends Comparable> TreeSet<T> make() {...}
public static <T> TreeSet<T> make(Comparator<? super T> comparator)
{...}
}

(fakt, ze mogliby dolozyc do Javy jakas mozliwosc dodawania "type
bounds" konstruktorom - byloby wygodniej)

lub ew. po prostu dwie rozne klasy TreeSet jak pisalem wczesniej.

Tyle, ze obydwie takie zmiany bylyby niekompatybilne z Java 1.4.

> Tak, właśnie np. Ada nie potrzebuje widzieć implementacji, żeby
> stwierdzić, że to jest bez sensu. I to jest właśnie statyczna kontrola
> typów a nie jakieś machanie rękami w run-time.
>

Java tez nie potrzebuje. Pod warunkiem, ze tworca API biblioteki dobrze
wykorzystal cechy jezyka. (Oczywiscie - Ada ma mocniejszy system typow,
ale akurat w tym wypadku to nie ma to znaczenia).

--
Michal

do góry

In the darkest hour on Sat, 13 Aug 2011 23:11:59 +0200,
Edek <e...@g...com> screamed:
>>> Ale jakiego zadania? Przecież nic nie opisałeś - wiadomo tylko, że dla
>>> danych wejściowych program ma wyprodukować wartości wyjściowe. I że
>>> jest text I/O.
>>> Wszystkie języki się do tego nadają.
>> Nie znam takich języków jak Prolog, Lisp, Python, Perl. Zastanawiam
>> się czy warto któregoś się pouczyć. Czy można tak ogólnie o którymś
>> z nich powiedzieć, że zapis typowych algorytmów niesie mniejsze ryzyko
>> pomyłki?
>
> Z powyższych, poprawnie używane C++. Z powodu pełnej kontroli typów
> podczas kompilacji.
>

To jest akurat marginalna zaleta. Podobnie sprawdzi się poprawnie
używany Python. Nie trzeba ludzi straszyć dynamicznie typowanymi
językami. https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:227B ]
[ 10:05:56 user up 12897 days, 22:00, 1 user, load average: 0.00, 0.18, 0.04 ]

Kennedy family favorite sexual position -- defendant.

do góry

On 2011-08-17, Michal Kleczek <k...@p...onet.pl> wrote:
[...]
> TreeSet<NonComparable> _nie_ jest bez sensu, bo mozna uzyc Comparatora
> zeby porownac elementy. Problem lezy w tym, ze Klasa TreeSet istniala
> przed wprowadzeniem generykow (i trzeba bylo zachowac konstruktory).

Przed wprowadzeniem machania rękami zwanego generykami, zapomniałeś
dodać. Generyki to tylko syntax sugar, *odrobinkę* ułatwiający życie
programiście, ale to nadal jest kontener trzymający elemety klasy
Object. Widać to choćby po bezparametrowej metodzie ArrayList.toArray().
I żeby nie być gołosłownym:
#v+
import java.util.ArrayList;

class test
{
public static void main(String[] args)
{
ArrayList al = new ArrayList();
ArrayList<Integer> ial = (ArrayList<Integer>)al;

al.add(new Integer(1));
al.add("foo");
al.add("bar");
al.add("baz");
al.add("nabla");

for (int i = 0; i < ial.size(); ++i)
System.out.println(ial.get(i));
}
}
#v-

Zgadnij, kiedy to się wywróci, o ile się wywróci? Java 6.26.

Przepraszam, ale w poważnym języku o statycznym systemie typów taka
głupota zostanie wykryta na etapie kompilacji. Java jest ewenementem, bo
to język o typowaniu statycznym ale dynamicznym.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 08/17/2011 10:12 AM, Artur M. Piwko wrote:
> In the darkest hour on Sat, 13 Aug 2011 23:11:59 +0200,
> Edek<e...@g...com> screamed:
>>>> Ale jakiego zadania? Przecież nic nie opisałeś - wiadomo tylko, że dla
>>>> danych wejściowych program ma wyprodukować wartości wyjściowe. I że
>>>> jest text I/O.
>>>> Wszystkie języki się do tego nadają.
>>> Nie znam takich języków jak Prolog, Lisp, Python, Perl. Zastanawiam
>>> się czy warto któregoś się pouczyć. Czy można tak ogólnie o którymś
>>> z nich powiedzieć, że zapis typowych algorytmów niesie mniejsze ryzyko
>>> pomyłki?
>>
>> Z powyższych, poprawnie używane C++. Z powodu pełnej kontroli typów
>> podczas kompilacji.
>>
>
> To jest akurat marginalna zaleta. Podobnie sprawdzi się poprawnie
> używany Python. Nie trzeba ludzi straszyć dynamicznie typowanymi
> językami. https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk
>

Nikogo nie straszę, znam zalety testów, w dowolnym języku da się napisać
dowolną ilość linijek.

Sprawa polega na czym innym, mówimy o wyższości jednego języka nad
drugim w kontekście ilości popełnianych błędów. Tu nie da się ukryć, że
tak czy inaczej testy są pomocne, że w każdym się robi błędy itd.
Potrzebna jest inna miara.

W moim osobistym przypadku, ja czasami sprawdzam, ile linijek kodu
(napisanego, średnio skomplikowanego, przetestowanego) tworzę średnio
na minutę. I - w moim przypadku - wynik jest następujący: w Pythonie
średnia jest nieco niższa (sam kod, nie liczę linijek testów) niż w C++
i niższa niż w Javie. Co mi sugeruje, że moje tempo pisania włącznie
z poprawianiem kodu jest podobne w Pythonie c++ i Javie, bo Python jest
bardziej zwięzły.

Ale, przy bardziej skomplikowanym kodzie, mam problem z Pythonem. Być
może jest to kwestia IDE, że pisząc coś większego muszę dużo uwagi
poświęcać na to, czy x to float, dict czy lista list, a nie na to, czym
ta zmienna jest. W c++ mogę otagować nawet floaty, czyli mieć typ
float-znaczysię-średnia i typ float-znaczysię-mediana, jeżeli tylko
chcę. Inaczej mówiąc, C++ pozwala tworzyć wiele kontrukcji na
poziomie typów, które służą poprawności. W Pythonie niby też
część z tych rzeczy jest możliwa, tylko implementuje się to inaczej,
ale walidacja ma miejsce w runtime, co a) powoduje, że to robi się
jeszcze wolniejsze b) trzeba faktycznie wykonać w testach każdą linijkę,
żeby w ogóle się dowiedzieć, czy nie pomyliłem w kodzie mediany ze
średnią. Oczywiście, tak jak 2/3 c++, nikt nikogo nie zmusza do
używania języka właśnie w ten sposób, można pisać w c++ np. bez
tworzenia template'ów i nawet często tak się właśnie robi. YMMV.

Edek

do góry

On 2011-08-17 10:29, Stachu 'Dozzie' K. wrote:
> On 2011-08-17, Michal Kleczek<k...@p...onet.pl> wrote:
> [...]
>> TreeSet<NonComparable> _nie_ jest bez sensu, bo mozna uzyc Comparatora
>> zeby porownac elementy. Problem lezy w tym, ze Klasa TreeSet istniala
>> przed wprowadzeniem generykow (i trzeba bylo zachowac konstruktory).
>
> Przed wprowadzeniem machania rękami zwanego generykami, zapomniałeś
> dodać. Generyki to tylko syntax sugar, *odrobinkę* ułatwiający życie
> programiście, ale to nadal jest kontener trzymający elemety klasy
> Object.

Nie bardzo rozumiem dlaczego to problem z punktu widzenia statyczniej
weryfikacji poprawnosci programu.

> Widać to choćby po bezparametrowej metodzie ArrayList.toArray().

To fakt - tablice w Javie zawsze byly schrzanione jesli chodzi o
typowanie - generyki specjalnie tu nic nie zmienily.

> I żeby nie być gołosłownym:
> #v+
> import java.util.ArrayList;
>
> class test
> {
> public static void main(String[] args)
> {
> ArrayList al = new ArrayList();
> ArrayList<Integer> ial = (ArrayList<Integer>)al;
>
> al.add(new Integer(1));
> al.add("foo");
> al.add("bar");
> al.add("baz");
> al.add("nabla");
>
> for (int i = 0; i< ial.size(); ++i)
> System.out.println(ial.get(i));
> }
> }
> #v-
>
> Zgadnij, kiedy to się wywróci, o ile się wywróci? Java 6.26.
>
> Przepraszam, ale w poważnym języku o statycznym systemie typów taka
> głupota zostanie wykryta na etapie kompilacji.

Zostaje wykryta - ja dostaje warning w 1 i 2 linijce main()

Ignorujesz warning - to tak jakbys stosowal <reinterpret_cast> w C++ -
widocznie wiesz co robisz.

> Java jest ewenementem, bo
> to język o typowaniu statycznym ale dynamicznym.
>

Tzn chodzi ci o to, ze informacja o typie jest dostepna w runtime? Java
nie jest tu ewenementem.

--
Michal

do góry