Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:hldk9t$khp$1@news.onet.pl...
> bartekltg pisze:
>> Podawalem juz kod ktory wypelnia ta tabelke tak samo
>> a nie mazga bez sensu strtofloat. Uzywa az jednej zmiennej
>> dla dowolnie dlugiej tabeli (a mimo to zapewne takze zuzywa
>> mniej pamieci bo ine ma tylu tymczasowego smiecia).
>>
>> Kazdy grupowicz ma Ci napisac lepszy kod?
>>
>
> Ten pajac chwali się ile to będzie zarabiał jako klepacz_w_bcb i miał nadzieję, że
wszyscy zaczną mu zazdrościć... Nie dociera, że
> tylko dał o sobie świetne świadectwo, a jego zarobki wszyscy mają gdzieś.
>
> Proponuję olać - na początku był zabawny, ale każdy wioskowy głupek po dłuższym
czasie nuży.

Zauwaz, ze na tej grupie glownie dyskutujemy.
Chamskie odzywki sa rzadkosica.
Trzymaj sie standardow.

do góry

Bastion pisze:
> Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:hldk9t$khp$1@news.onet.pl...
>> bartekltg pisze:
>>> Podawalem juz kod ktory wypelnia ta tabelke tak samo
>>> a nie mazga bez sensu strtofloat. Uzywa az jednej zmiennej
>>> dla dowolnie dlugiej tabeli (a mimo to zapewne takze zuzywa
>>> mniej pamieci bo ine ma tylu tymczasowego smiecia).
>>>
>>> Kazdy grupowicz ma Ci napisac lepszy kod?
>>>
>> Ten pajac chwali się ile to będzie zarabiał jako klepacz_w_bcb i miał nadzieję, że
wszyscy zaczną mu zazdrościć... Nie dociera, że
>> tylko dał o sobie świetne świadectwo, a jego zarobki wszyscy mają gdzieś.
>>
>> Proponuję olać - na początku był zabawny, ale każdy wioskowy głupek po dłuższym
czasie nuży.
>
> Zauwaz, ze na tej grupie glownie dyskutujemy.
> Chamskie odzywki sa rzadkosica.
> Trzymaj sie standardow.

Mogłeś napisać "Jestem kiepskim programistą a będą mi płacić w kolejnych
n miesiącach 4k*(1.1)^n, możecie mi zazdrościć" - byłoby to tylko
żałosne, ale ty wrzuciłeś bardzo kiepski kod, a jak cię zjechano za jego
jakość próbowałeś się nieudolnie bronić pogrążając jeszcze bardziej -
tak zachowujących się ludzi określa się często mianem wioskowych głupków.

A ponieważ większość grupowiczów nie załapała twojej przechwałki
postanowiłeś znowu odgrzać to samo co na początku - ja to nazywam
pajacowaniem.

P.S.
1.
Tak się podniecasz tym 4k PLN - jesteś na 4 roku studiów, czy co?
2.
Alebyśmy mieli ubaw jakby Cię wylali po 2 miesiącach za kod którego
współpracownicy nie są w stanie czytać, ale obawiam się że na post:
"Mój znienawidzony kod"
void __fastcall TForm1::BitBtn1Click(TObject *Sender)
{
UznanieSzefaTextBox->Text=FloatToStr(StrToFloat(Floa
tToStr(StrToFloat(FloatToStr(StrToFloat("0"))))));
StringGrid1->Cells[1][0]=FloatToStr(4000*StrToFloat(
UznanieSzefaTextBox->Text));
for(int i=1; i<21;i++)
{
StringGrid1->Cells[0][i]=FloatToStr(2010+i);
StringGrid1->Cells[1][i]=FloatToStr
(
StrToFloat(StringGrid1->Cells[1][i-1])
+StrToFloat(StringGrid1->Cells[1][i-1])*0.1
);
}
}
Nie mamy co liczyć.


--
Pozdrawiam
Michoo

do góry

In the darkest hour on Tue, 16 Feb 2010 00:35:42 +0100,
Bastion <b...@m...pl> screamed:
>> O ile tylko do Ciebie w koncu to dotrze.
>
> Do minie nic nie dociera... Kod ktory napisalem
> jest fajny, optymistyczny i poprawny:
>

Z punktu widzenia składni tak.

> Jezeli potrafisz napisac to lepiej to jestem bardzo ciekawy, Twojego rozwiazania.
>

Nie trzymałbym danych do obliczeń w warstwie prezentacji.

Przy okazji ustaw MIME, bo wysyłasz śmieci: http://www.grush.one.pl/mime

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:239B ]
[ 08:12:52 user up 12351 days, 20:07, 1 user, load average: 0.50, 0.81, 0.99 ]

I refuse to answer that question on the grounds that I don't know the answer.

do góry

W dniu 2010-02-11 08:57, Wojciech "Spook" Sura pisze:
> Bastion wrote:

>> Kolego, ja tak nie pisze tylko przedstawiam rozwiazanie pewnego
>> problemu. Laskawie pochyl glowe i zastanow sie jak w 5 linijkach kodu
>> lepiej mozna zwizualizowac rozwiazanie. Czekam na kod...
>
> Zacznijmy od tego, że nawet nie zabierałbym się do projektowania aplikacji
> myśląc panicznie, żeby zmieścić się w n linijkach. Płacisz podatek od każdej
> napisanej linii kodu? Jeśli radość sprawia Ci upychanie programu w
> niewielkiej przestrzeni, to raczej wyślij Twój pomysł na IOCCC niż chwal się
> na grupach.

Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował w
czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)

Taki głos dziadka który postanowił ostatnio przyłączyć się do grupy by
podszkolić się w nowoczesnym programowaniu (bo obecnie jestem Fortranowy
i zaczyna mi to lekko przeszkadzać :) (oczywiście stare zabawki z 8
bitowców też mam w zanadrzu tyle że obecnie są całkiem nie przydatne )

Pozdrawiam
Qbab

do góry

Qbab denied rebel lies:

> Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
> upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
> bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował
> w czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)

Właśnie zniknąłeś segment embedded rynku. Gdzie też często ważniejsza
jest czytelność i przenośność (testowalność i inne -ności) niż
zaoszczędzony bajt RAMu.

> Taki głos dziadka który postanowił ostatnio przyłączyć się do grupy
> by podszkolić się w nowoczesnym programowaniu (bo obecnie jestem
> Fortranowy i zaczyna mi to lekko przeszkadzać :) (oczywiście stare
> zabawki z 8 bitowców też mam w zanadrzu tyle że obecnie są całkiem
> nie przydatne )

Czy ja wiem? Zależy czym się zajmujesz - czasem paranoja zasobowa się
przydaje (ale IMNSHO częściej przeszkadza. Jak to szło? "Premature
optimization"?)

--
<:> Roger, MoonWolf Out <:>|These are the looks that
(::) (::)|chill to the bone
(:) JID:m...@j...org(:)| http://karakkhaz.prv.pl

do góry

W dniu 2010-02-18 15:41, MoonWolf pisze:
> Qbab denied rebel lies:
>
>> Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
>> upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
>> bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował
>> w czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)
>
> Właśnie zniknąłeś segment embedded rynku. Gdzie też często ważniejsza
> jest czytelność i przenośność (testowalność i inne -ności) niż
> zaoszczędzony bajt RAMu.

Nie "zniknąłem", zdaję sobie sprawę z istnienia a nawet z powodów
istnienia różnych obszarów programistycznych, tak mi się po prostu ta
dyskusja skojarzyła z ostatnią dyskusją z kolegą z pracy o technologi
CUDA gdzie padł argument, że jak na razie mało przydatna bo zazwyczaj ma
się około jednego giga RAM'u do dyspozycji a to przecież mało :)

>
>> Taki głos dziadka który postanowił ostatnio przyłączyć się do grupy
>> by podszkolić się w nowoczesnym programowaniu (bo obecnie jestem
>> Fortranowy i zaczyna mi to lekko przeszkadzać :) (oczywiście stare
>> zabawki z 8 bitowców też mam w zanadrzu tyle że obecnie są całkiem
>> nie przydatne )
>
> Czy ja wiem? Zależy czym się zajmujesz - czasem paranoja zasobowa się
> przydaje (ale IMNSHO częściej przeszkadza. Jak to szło? "Premature
> optimization"?)

Nie mam paranoi zasobowej, na szczęście problemy które rozwiązuję
(fizyka) zazwyczaj mają ograniczenia wydajnościowe a nie pamięciowe (w
sensie zapotrzebowania na pamięć).

Pozdr
Qbab

do góry

Qbab pisze:
> Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
> upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
> bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował w
> czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)
Nie przesadzasz trochę? Niedawno pisałem na ATiny2313, który ma 128
bajtów ramu. W C++. Z klasami.

--
Pozdrawiam
Michoo

do góry

W dniu 2010-02-18 23:16, Michoo pisze:
> Qbab pisze:
>> Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
>> upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
>> bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował
>> w czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)
> Nie przesadzasz trochę? Niedawno pisałem na ATiny2313, który ma 128
> bajtów ramu. W C++. Z klasami.
>

chyba nie przesadzam, bo obstawiam że nie robiłeś na tym jakiegoś
skomplikowanego dema z grafiką wektorową, muzyką itp. a o takie rzeczy
mi chodziło. Wrzuć sobie na youtube i poszukaj dem z 8 bitowców, albo
choć rzuć okiem na pecetową produkcję z cyklu intro 64kb

http://www.youtube.com/watch?v=tCMo-bJQC8A

lub tą:

http://www.youtube.com/watch?v=SmVCfWjiVKo

obie mnie powalają :)

pozdr
Qbab

do góry

Qbab wrote:

>>> Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
>>> upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
>>> bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował
>>> w czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)
>> Nie przesadzasz trochę? Niedawno pisałem na ATiny2313, który ma 128
>> bajtów ramu. W C++. Z klasami.
>>
>
> chyba nie przesadzam, bo obstawiam że nie robiłeś na tym jakiegoś
> skomplikowanego dema z grafiką wektorową, muzyką itp. a o takie rzeczy
> mi chodziło.

Nawet biorac pod uwage takie rzeczy rozwiazanie autora watku jest
nieekonomiczne :) Pomysl o tej calej masie konwersji FloatToStr(StrToFloat()
+ StrToFloat()). Toz to paskudnie niewydajne jest :)

--
Michal Schulz

do góry

Michal Schulz pisze:

>
> Nawet biorac pod uwage takie rzeczy rozwiazanie autora watku jest
> nieekonomiczne :) Pomysl o tej calej masie konwersji FloatToStr(StrToFloat()
> + StrToFloat()). Toz to paskudnie niewydajne jest :)
>
i pieprzy zaokrągleniami, ale 'prawdziwy programista' itd...

do góry