Programozás segítség

 ( Adamyno | 2012. március 26., hétfő - 7:28 )

Elkéne egykis segítség :)
Ti ezt hogyan csinálnátok?

"Készítsünk függvényt az 10x10-es, valós típusú adatokat tartalmazó mátrix elemeinek beolvasására, egy másik függvényt az elemek táblázatos formában történő kiíratására. A dinamikusan foglalt."

C nyelven

Köszi!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ügyesen:) Azért ez elég alapfeladat.

Újabb, "hihetetlenül nehéz kötelező proramot kell készíteni" tárgyú téma!
Hogy segítsek: egy jó C könyv elovasása, megértése és a google a baarátod:)

/* main.c */

#include "my_solutions.h"

int main()
{
double* myArray = readArray();
printArray(myArray);
}

/*
neked már csak a my_solutions.{h, c} fájlokat kell megírni.
*/
----
Hülye pelikán

Troll on

valós típusú adatokat tartalmazó Ez mi? A következő feladatban valótlan típusú adatokkal kell dolgozni? A feladat kirója kicsit jobban is megerőltethette volna magát...

/Troll off

+1 :)

Nem is értem, ilyen feladat hogyan kerülhet elő páros félévben...

----------------
"Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders" +1

ha egesz tipusu adatok lett volna kiirva, akkor a kerdesed fel vagy harmad tipusu adatokra vonatkozott volna? :)

---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering

Nem látom a problémát. A magyar szaknyelv (mármint az iskolai (közép, általános)) az ilyen-olyan törtszámokat valósnak hívja, gondolom a pascalos beidegződés is segít. Az egy dolog, hogy valós számokat általánosan ábrázolni fizikailag is képtelenség, de nyílván a korlátokon belül.

Jah, és ez nem trollkodás, ez értelmetlen és jogtalan belekötés.
----
Hülye pelikán

gondolom attol furcsa a kifejezes, hogy nem valos tipusu szamrol, hanem valos tipusu adatrol beszel.

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

Az az igazság, hogy a számoknak nincs típusa. Egy szám valós, vagy nem valós (ezesetben legalább komplex, ha csak a hagyományos "hierarchiát" nézzük). Viszont az adat típusa lehet valós. Emellett lehet karakter, egész, referencia (meg még sok egyéb, nyelvfüggő).
----
Hülye pelikán

betegek ezek a kifejezesek, de nem tudok ellent mondani mert tenyleg van ilyen: http://en.wikipedia.org/wiki/Real_data_type

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

Rendben, ha nincs probléma a kiirással, akkor a megoldásom a következő.


#include

int(*matrix)[10][10] ;

void adatbe(int(*input)[10][10])
{
matrix=input;
}

void print_table(void)
{
int i, j;
printf("");
for(i=0; i<10; i++)
{
printf("");
for(j=0;j<10;j++)
{
printf("%i",matrix[i][j]);
}
printf("");
}
printf("");

}

int main(void)
{
static int dodo[10][10];
adatbe(&dodo);
print_table() ;
}

Kérdések:

  1. Erre gondolt a kiíró?
  2. Megfelel a megoldás a kiírásnak?

szerk.: ugyanez pastebin -en

Több soron rossz...
Kezdetnek: dinamikusan kéne allokálni a memóriát, valahogy be kéne olvasni azt a mátrixot, na meg szerintem (habár nem vagyok benne biztos, mert a tömböket gusztustalannak tartom és kerülöm ahol lehet) ez a kettő nem pont azt csinálja amire te gondolsz:
int(*input)[10][10]
int(*matrix)[10][10] ;

Oké, a dinamikusság tényleg kimaradt.

Amúgy mire gondoltam a váltózók definiálásánál, ami nem jó?

be kéne olvasni azt a mátrixot
Beolvassuk azt, a main függvénytől változóban. Vagy nem? Hogyan olvashatnánk még be egy másik függvénytől?

Amit írtál attól borsódzik a hátam:

- egy függvény hogy adatot tölts egy globális változóba
- egy másik void paraméterlistával ami ezt használja

Vond őket össze! MOST! ;)

Nem inkább vond őket VISSZA?
----
Hülye pelikán

A kiírással csak baj van. Én a "A dinamikusan foglalt." kitételt úgy dekódolom, hogy a tömb (mátrix) van dinamikusan lefoglalva. Feltételezem, hogy egy kétszer láncolt listát kéne csinálni vagy mit (utoljára kb. 20 éve láttam ezt leírva egy pascal könyvben).

Zokognék ha a kérdés arra irányulna, hogy hogyan olvassak be és írjak ki száz számot.

Mivel fix meretű a dolog, ezért nem szenvednék láncolt listával. calloc-kal allokálnék 100db float-nak helyet:
float* matrix = calloc(100, sizeof(float));
if(!matrix) return -1; // ha valami gond van, calloc NULL-t ad vissza
Aztán beolvasásnál és kiírásnál is egyszerűen egy matrix++-szal lépkednék végig az elemeken. (Értelemszerűen az eredeti pointert érdemes valahol tárolni. ;)) Aztán csak a biztonság kedvéért, a program végén egy free(matrix)-ot is beraknék, hogy nehogy belekössön bárki.

Najó, ezt vágom, csak ugye még mindig remélem, hogy a feladat nem száz szám beolvasása majd kiíratása. És itt egyetlen nehézséget látok, hogy milyen megoldást használ a dinamikus memóriafoglalásra.

Egy 10x10-es mátrix csak 100 szám. A többi már csak attól függ, hogy hogyan értelmezed azokat a számokat.

Hogy kerül HTML kód a C-be?

Táblázatos kiíratásnak jó az nem?

valos szamokkal (valos tipusu adat) kell dolgozzon, nem egeszekkel.

Az int ugyan úgy a valós számok egy részhalmazát képezi le mint a lebegőpontos számábrázolás. Amúgy ebben az esetben az int -et fixpontos törtszámok ábrázolására használom, csak a számítások nem látszanak. Így sem elég valós? ;)

a kifejezés, amit kerestél, az "elkelne egy kis segítség"

na de egyszerre csak egy nyelvet, még a végén összezavarodsz :3

mert eladja, vagy mi? miert kelne el az a segitseg? es ha reszerol elkelne, tehat o adja el, akkor tulajdonkeppen most o akar segiteni?

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

de pihentek vagytok :'D

Én ezt úgy csinálnám, hogy az első függvénybe teszek egy for ciklust(aminek 'i' a változója), 0-tól 9-ig számolva, ezen belül egy másik for ciklust(aminek 'j' a változója), szintén 0-tól 9-ig. A belsejében bekérek egy karaktersorozatot billentyűzetről, ellenőrzöm, hogy valós szám-e, majd beleteszem a tömb (i,j)-edik "fiókjába".

A második függvény belülről ugyanez, kivéve, hogy ott kiíratás történik. A belső ciklusban minden egyes kiírt érték után egy \t-t írnék, a külső ciklusban a belső for után pedig egy \n-t. Így lesz táblázatos.

A main()-ben meg meghívnám egymás után a két függvényt.

Remélem, ez megfelelő válasz volt a "Ti ezt hogyan csinálnátok?" kérdésre. Konkrét megoldásért úgy gondolom más fórumon kell kérdezősködnöd, vagy egy kisebb összeget felajánlani(nem nekem, én nem vagyok C guru) :)

A belső ciklusban minden egyes kiírt érték után egy \t-t írnék

Az utolsó után minek?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Rövidítendő a kódot. Kinek fáj az?
----
Hülye pelikán

Ronda.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

attol fugg honnan kell beolvasni :)

fopen/fread esetleg open/read (talan az elobbivel egyszerubb, de mindenesetre hordozhatobb)

amugy meg scanf/printf fuggvenyek, esetleg strod scanf helyett, valamint malloc memoriafoglalashoz, arra vigyazz, hogy tobbdimenzios tombot dimenzionkent kell mallocolni (kiveve, ha utana nem tombkent hasznalod, hanem pointer artimetikazol, de szerintem nem fogsz kezdokent).

--
NetBSD - Simplicity is prerequisite for reliability

tobbdimenzios tombot dimenzionkent kell mallocolni

Nem muszáj,

#include <stdlib.h>

int
main(void)
{
  int (*k)[3][4][5];

  k = malloc(sizeof *k);
  if (0 != k) {
    (*k)[2][3][4] = -1;
  }

  return 0;
}

kiveve, ha utana nem tombkent hasznalod, hanem pointer artimetikazol

Találós kérdés: az alábbi programban van pointer aritmetika vagy nincs?

#include <stdlib.h>

int
main(void)
{
  int k[3][4][5];

  k[2][3][4] = -1;

  return 0;
}

Ja, a lényeget kihagytam:

scanf

Tilos használni.

int (*k)[3][4][5];

Wow. Ezt a szintaxist most látom először, tud valaki valami hívószót adni rá, amivel rá tudok keresni?
----
Hülye pelikán

Ebben megtalálod ;)

Keress "pointer to an array" -ra.

A scanf()-et miért tilos használni?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

buffer overflow?

megfeleloen hasznalva nincs azzal gond

A scanf()-et miért tilos használni?

Mert

the result of the conversion shall be placed in the object [...] if the result of the conversion cannot be represented in the space provided, the behavior is undefined

Például nem tudsz vele egész számokat megbízhatóan beolvasni -- akármekkora típust használsz is (pl. intmax_t), az undefined behavior kizárólag a user input-on múlik (pl. "18446744073709551616" 64 bites (u)intmax_t-nél).

És akkor mi a helyes megfejtés?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

És akkor mi a helyes megfejtés?

strtoimax() és társai.

Az előjel nélküli típusra konvertálókat (= strtoul(), strtoull(), strtoumax()) ezek közül sem szeretem általában, mert a negatív egészt leíró bemeneti sztringet automatikusan "modulo 2^N" konvertálják. Más szóval nem biztosítható, hogy a konverzió pontosan azt adja vissza, amit a felhasználó benyomott. Példa:

/* gcc -ansi -pedantic -Wall -Wextra -o strtoul strtoul.c */

#define _XOPEN_SOURCE 500 /* SUSv2 -- UNIX(R) 98 */

#include <errno.h>  /* errno */
#include <stdlib.h> /* strtoul() */
#include <stdio.h>  /* fprintf() */

int
main(void)
{
  long unsigned lu;
  char *endptr;

  errno = 0;
  lu = strtoul("-1", &endptr, 10);

  (void)fprintf(stdout, "errno=%d endptr=\"%s\" lu=%#lx\n", errno, endptr, lu);
  return EXIT_SUCCESS;
}

Kimenet (LP64):

$ ./strtoul
errno=0 endptr="" lu=0xffffffffffffffff

Lásd még itt a hup-on: Hogyan olvassunk be overflow nélkül?

Köszönöm. Mentségemre szolgáljon, nem vagyok programozó, C-ben alig írtam valamit is. Elsősorban alacsony szintű, többnyire assembly-ben elkövetett dolgaim vannak. Nyilván nem PC-re.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

mindig tanul valami ujat az ember, koszonom

--
NetBSD - Simplicity is prerequisite for reliability

de itt rögzített a dimenziók mérete.
dinamikusra is van ilyen okosságod? amúgy ez nagyon tetszik :)

I. Ahhoz, hogy a tömb egyben ábrázolható legyen egyáltalán, a méretének kifejezhetőnek kell lennie size_t-ben. Ezért size_t-ben összeszoroznám a dimenziók szerinti méreteket, egyben allokálnám, és az indexeléshez kézzel szoroznék.

Itt további kérdés, hogy a dimenziók darabszáma fix-e, vagy az is dinamikus. Ebben a Usenet post-omban (*) leírok egy módszert, amivel egy K dimenziós tömböt N db közel egyenlő részre lehet szétosztani (N db thread általi párhuzamos bejárásra) -- a most éppen érdekes szorzás a get_maxflat() függvényben van.

(*) Message-ID: <Pine.LNX.4.64.1009062343000.32316@login03.caesar.elte.hu>


II. C99-ben lehet VLA-kat is használni (típusdefinícióra is), csak annak az a baja, hogy a függvény hatásköréből (scope) maga a típus nem tud kijönni. Ilyenkor a (void *)-ot oda-vissza kell cast-olni ugyanerre a (pointer-to-VLA) típusra, ahol csak használni akarjuk, ami elég nyűg, és könnyen el lehet rontani.

/* gcc -o vla -std=c99 -pedantic -Wall -Wextra vla.c */

#include <stdlib.h>
#include <stdio.h>

struct ia3d
{
  size_t dim0,
      dim1,
      dim2;
  void *arrptr;
};

static int
ia3d_init(struct ia3d *ia3d, size_t dim0, size_t dim1, size_t dim2)
{
  /* Check for expressibility of full size in bytes. */
  if (0u < dim0 && 0u < dim1 && 0u < dim2
      && dim0               <= (size_t)-1 / dim1
      && dim0 * dim1        <= (size_t)-1 / dim2
      && dim0 * dim1 * dim2 <= (size_t)-1 / sizeof(int)) {
    int (*tmp)[dim0][dim1][dim2];

    tmp = malloc(sizeof *tmp);
    if (0 != tmp) {
      ia3d->dim0 = dim0;
      ia3d->dim1 = dim1;
      ia3d->dim2 = dim2;
      ia3d->arrptr = tmp;

      return 0;
    }
  }

  return -1;
}


static void
ia3d_uninit(struct ia3d *ia3d)
{
  free(ia3d->arrptr);
}


static inline int *
ia3d_ref(struct ia3d *ia3d, size_t ofs0, size_t ofs1, size_t ofs2)
{
  return &(
    *(int (*)[ia3d->dim0][ia3d->dim1][ia3d->dim2])ia3d->arrptr
  )[ofs0][ofs1][ofs2];
}


int
main(void)
{
  int ret;
  struct ia3d my;

  ret = EXIT_FAILURE;
  if (0 == ia3d_init(&my, 3u, 4u, 5u)) {
    size_t ofs0,
        ofs1,
        ofs2;

    /* populate */
    {
      int i;

      i = 0;
      for (ofs0 = 0u; ofs0 < my.dim0; ++ofs0) {
        for (ofs1 = 0u; ofs1 < my.dim1; ++ofs1) {
          for (ofs2 = 0u; ofs2 < my.dim2; ++ofs2) {
            *ia3d_ref(&my, ofs0, ofs1, ofs2) = i++;
          }
        }
      }
    }

    /* use */
    for (ofs0 = 0u; ofs0 < my.dim0; ++ofs0) {
      (void)fprintf(stdout, 0u == ofs0 ? "" : "\n");
      for (ofs1 = 0u; ofs1 < my.dim1; ++ofs1) {
        for (ofs2 = 0u; ofs2 < my.dim2; ++ofs2) {
          (void)fprintf(stdout, "%s%2d", 0u == ofs2 ? "" : " ",
              *ia3d_ref(&my, ofs0, ofs1, ofs2));
        }
        (void)fprintf(stdout, "\n");
      }
    }

    /* done */
    ret = EXIT_SUCCESS;

    /* cleanup */
    ia3d_uninit(&my);
  }

  return ret;
}

Ennyi erővel szerintem jobb szorozni (size_t túlcsordulást szintén ellenőrizve a kezdeti allokációnál, amikor meghatározzuk a teljes elemszámot ill. a teljes méretet byte-ban -- ezt a Usenet post-omban elhanyagoltam). Ráadásul az megy C89-ben is.


III. A kérdésed egyébként egy gyakori C kérdés (C-FAQ 6.16).

tehát az n>1 dimenziós tömbömet foglaljam le egyetlen, nagy, sorfolytonos tömbként. végülis :-)

Végülis :) igen.

A fentin egyébként "stiláris" szempontból még lehetne reszelni -- ha meg akarjuk tartani a szokásos k[2][3][4] szintaxist a sajátos (*k)[2][3][4] helyett, ahhoz annyi kell, hogy a "k" ne az egész tömbre mutasson, hanem annak csak első elemére, egy int[4][5]-re.

#include <stdlib.h>

int
main(void)
{
  int (*k)[4][5];

  k = malloc(3u * sizeof *k);
  if (0 != k) {
    k[2][3][4] = -1;
    free(k);
  }
  return 0;
}

Ez valamivel hívebb az "igazi tömbszemlélethez", amikor is van egy elemtípusod, meg abból egy egydimenziós tömböd, és a fenti mintát alkalmazod (pointer az elemtípusra, és malloc-ban elemszámmal szorozzuk az elemméretet). Ennek a fenti egy speciális esete, amikor az elemtípus egy N dimenziós tömb; így végül N+1 dimenziósat kapunk.

typedef struct{
          int number_of_rows;
          int number_of_columns;
          int alloc_state=0;
          double **elemek;
} matrix;

void matrix_inicializalas(const int rows, const int colums, matrix *matrica){
          matrica->number_of_rows = rows;
          matrica->number_of_colums = columns;
          matrica -> elemek = (double **) malloc(rows *sizeof(double*));
          for(int i=0; i< rows; i++) matrica->elemek[i] = (double *)malloc(columns*sizeof(double));
          matrica->alloc_state=1;
}

void matrix_felszabaditas(matrix *matrica){
         for(int i=0; i < matrica->nrows; i++) free(matrix->elemek[i]);
         free(matrix->elemek);
         matric->alloc_state=0;
}

main(){
      matrix alma;
      const int en=10;
      matrix_inicializalas(10,10,alma);
      printf("Matrix beolvasasa, johetnek az elemek: ");
      for(int i=0; i < alma->number_of_rows; i++) for (int j=0; j<alma->number_of_columns; j++) scanf("%lf", &alma->elemek[i][j]);
 
      printf("A matrix elemei:\n");
      for(int i=0; i<alma->number_of_rows; i++){
            for (int j=0; j <alma->number_of_columns; j++) printf("%lf\t", alma[i][j]);
            printf("\n");
      }
      matrix_felszabaditas(alma);
}

Nem próbáltam ki, kisebb hibák lehetnek benne. A lényeg, hogy próbáltam a mátrixnak létrehozni egy típust, amihez nem kell külön megadni a méretet. Előnye, hogy nem lehet eltéveszteni (melyik mátrix sorainak a számáról is van szó?) és emiatt segfaultolni, vagy memóriaszivárgást okozni.
Ha C++-ban írnád, akkor az egész lefoglalás mehetne a konstruktorba, a felszabadítás a destruktorba, és akkor a mátrix létrehozásakor már automatikusan le is foglalnád neki a tárterületet, és amikor a mátrix pusztul (pl. véget ér a hatásköre), akkor felszabadul a memória.
Ha komolyabb számoláshoz akarnád használni, akkor még persze hibakezeléssel kellene ellátni: a matrix_inicializalas()-ban, ha nem sikerül a lefoglalás (pl. nincs annyi memória), akkor amit már addig lefoglalt, azt fel kellene szabadítani, és az alloc_state-et 0-ra állítani; a mátrix használatakor pedig meg kellene nézni, hogy az alloc_state 1-e.

Na én meg így csináltam:

#include
#include
float m[10][10];

void read()
{

for(int i=0;i<10;i++)
for(int j=0;j<10;j++)
scanf("%f",&m[i][j]);
}

void write()
{
for(int i=0;i<10;i++)
{
for(int j=0;j<10;j++)
{
printf("%f\t",m[i][j]);
}
printf("\n");
}
}

int main(int argc, char *argv[])
{
printf("adja be a szamokat");
read();
system("cls");
write();
return 0;
}

Működik. Köszönöm mindenkinek az ötleteket!

Ebben persze nincs dinamikus foglalás.
----
Hülye pelikán

system("cls");

Szuper. Éljen. Gratula. :-(

Nincs is cls parancs, olyan BASIC-ben volt. :) Esetleg clear az, amire gondolhatott.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

dos/windows command line :)

---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering

Már csak a system("pause"); hiányzik :D
----
Hülye pelikán

Na igen, az meg a masik gyakran latott kedvenc :D

#ifndef _WIN32
system("alias pause='echo A folytatashoz nyomjon entert && read'");
#endif

:D:D

Hozzáteszem: ez a hozzáállás irgalmatlanul szokott zavarni:

"Fogalmam sincs az egészről, de nézzen ki jól."

Kezdő a gyerek. Itt a hupon sajnos divat az embereket magyarázat nélkül körberöhögni.

Leírom röviden, hogy miért rossz parancssoros alkalmazásoknál a
- képernyő törlés
- várakozás billentyűre
- kurzor pozícionálás
...

Egy programnak be/kimenete van, amit át lehet irányírani. Az egyik program kimenetét egy másik program bemenetére küldheted.

for i in `ls *.txt`; do cat $i; done

A fenti parancs kiírja az összes txt fájl tartalmát a képernyőre (cat *.txt bonyolultan).
Az "ls" kimenetét megkapja a "for", az darabokra szedi és továbbadja a "cat"-nak.
Ha történetesen van 500 fájlod és a "cat" megállna egy billentyűre várakozásra, akkor a scripted futásánál 500-szor le kell ütnöd egy billentyűt, ami úgy hülyeség ahogy van.

Shellből kell a problémát normálisan megoldani, nem pedig beledrótozni a programodba:

#!/bin/bash
clear
sajatprogim
echo Nyomj enter-t!
read

szerencsere az ilyen kerdeseket stackoverflow-n 5 perc alatt bezarjak.

Két sörért/Milka csokiért/usw.

Házit nem illik sem megkérdezni, sem pedig megoldani másnak errefelé...

Az ilyen topikok egyébként komolyan elszomorítanak. Komolyan ezeket kell egyetemre engedni? Valószínűleg a középiskolát is így vészelték át, cserébe aki nem csal az nem jut be sehova, mert a szar felvételi rendszerben az egyetemek nem tudnak csak pár szám alapján dönteni...

Ez még annál is gázabb, hogy operációs rendszerekből úgy kaptam A-t, hogy egy C-t vagy TALÁN B-t adtam volna magamnak. 12 főt engedtek át C-vel. Nekem ezekkel az emberekkel kell majd dolgoznom. Szerintem pályát váltok és elmegyek ácsnak.

Az ácsok között ugyanannyi cintányéros van. Ez szakmafüggetlen tulajdonság. És nem, ott sem derül ki előbb, és ugyanúgy együtt kell dolgozz, ha nem is az emberrel, de a munkájával.
----
Hülye pelikán

lehet, de egyre jobban úgy érzem, hogy hígul a szakma

hmmm, nagyon diplomatikusan fogalmaztál :)
Egyre több hozzáértő semmit nem tudó barbár.
Hibakezelés nulla, átgondoltság nulla, tartalékolás nulla.
Valami alapértéken épphogy megy akkor kész.

Sajnos ez mindenben látszik, még nagynevű gyártók termékén is sajnos.

Mérnökinfót tanultam addig, ameddig ki nem buktam, a meglátásaim:
- Sok végzős UNIX rendszert alig látott az életében, használni abszolút nem tudja
- Sokan egy processzort nem tudnak kicserélni egy Desktop PC-ben
- Sokan egy SOHO routert nem tudnak beállítani
- Logikus gondolkodás meg... valahol a béka feneke alatt van.

Megtörtént esetek:
- Másodéves mérnökinfós haver mondta: Fúúú, de utálom a linuxot, nagyon rossz rendszer, de Google OS-t majd használni fogja biztosan.
- A laptop processzora RealTemp alatt 90 fokot mutatott és sorozatosan újraindult a laptop, mondtuk a srácnak, hogy szétszedjük, teszünk pasztát a processzor hűtő és a processzor közé és akkor nem fog újraindulni, de mondta, hogy áááá... biztosan nem az a gond
- Egyik ismerős azon nyavalygott, hogy nem tud Prog1-re gyakorolni, mert nem működik neki az XP-je (mert csak azon futott a Turbo C) és csak a Windows 7 fut normálisan és hogy a szervizesek is azt mondták, hogy erre a gépre nem lehet XP-t rakni, 2 órán belül feltelepítettem az XP-t és minden illesztőprogram tökéletesen működött

Ahogyan észrevettem, sok emberrel az a gond, hogy csak az elméletet tanulja, meg is vannak neki a vizsgái, de az elméletet a gyakorlatban nem használja és ezért egy idő után teljesen elfelejti, meg ha megvan a vizsga, utána pár napon belül azt se tudja, hogy mit tanult.

+1. Sajnos. Ahogy mondani szoktam, a friss diploma azt jelenti, hogy (talán) képes elfogadható időn belül elsajátítani, és gondolkodva alkalmazni a feladataihoz szükséges tudást és gyakorlatot. Tisztelet a kivételnek, az oktatás is arrol szól nagyon sok helyen, hogy mi az, amire oktató van, és nem arról, hogy mire van szükség kint, az "iparban". Sarkos vélemény, tudom, de egyetemen/főiskolán oktatni csak több éves, egyetemen kívüli, "ipari" gyakorlattal engednék, legalábbis szakmai tárgyakból mindenképp.

Értem én, hogy szar az oktatás, tapasztalom én is a frissen végzetteken, de nem látom be, miért kéne UNIX rendszert látni, processzort cserélni vagy SOHO rútert konfigolni egy programozónak. Én sem láttam még UNIX rendszert (hazudok, szekrényt is láttam, meg ha jól rémlik 5 percig ssh-n is bennt voltam eggyen), amíg nem próbáltam, nem tudtam hogy tudok-e procit pakolgatni (voltak kétségeim), rúterkonfigban pedig a portforward a legjobb teljesítményem eddig. A szoftverfejlesztő nem hardveres, nem szoftver üzemeltető és nem IT support, hanem elsősorban szoftverfejlesztő. Azaz a gépnél minden szempontból FELHASZNÁLÓ.
Az egy másik dolog, hogy a legtöbbünk nyílván más területen is képzettebb az átlagnál, de nem lehet általános képzettséget elvárni.

Mondom, alapvetően egyetértek, csak a példáig meg az egész szöveged olyan, hogy korrekcióra szorul.
----
Hülye pelikán

Egyetertek veled. Szerintem inkabb az a gond, hogy arra is keptelenek, hogy (amikor kell) elsajatitsak ezeket, illetve gyakran nem hiszik el, hogy nem ertenek valamihez.

Meselek is egy sztorit:
Intel ISEF, egy VPN protokollal voltam jelen (NEM Magyarorszagot kepviselve, de ez egy masik tortenet). Az egyik (elvileg ehhez erto) biro:
o: Szoval latom, hogy UDP-t hasznaltal.
en: Igen, az Ethernet csomagokat UDP csomagokban tovabbitom.
o: Mi tortenik ha elveszik egy csomag?
en: Semmi, az ilyen esemenyeket a magasabb halozati retegeknek kell lekezelnie.
o: Mi van akkor ha egy program feltetelezi, hogy minden csomag megerkezik?
en: Nem feltetelezheti, mert erre az Ethernet sem ad garanciat, igy nem erdemes az ujrakuldest ezen a szinten kezelni.
o: Na de mi van ha megis feltetelezi?
en: De nem teheti, mert akkor kabelen sem mukodne rendesen.
o: De miert nem?
en: Mert az Ethernet sem garantalja, hogy a csomagok megerkeznek.
... es ez meg igy ment egy darabig... Egy ponton ra is kerdezett, hogy minek a roviditese az UDP, es a User Datagram Protocol nem tetszett neki. Ki is javitott, hogy Unreliable Datagram Protocol... hat nem...

A végzett informatikusok között volt, aki nem tudott olyan programot írni tetszőleges nyelven, hogy 1-10-ig kiírja a számokat.

Ez a gond, nem a router konfigurálás...

Mert te még nem tudod, hogy a BSc az elméleti alapozó hivatalosan... (ellenben a közvélekedéssel, hogy gyakorlatot ad és az elméletet majd MSc-n)
De rációt ne keress benne.

Amit írtál, azzal nagyon nem értek egyet. Az a programozó, aki nem tudja, hogy lényegében a hardware-t vezérli, s nem tudja, hogy hogyan, az nem fog tudni optimalizálni sem. Ebből jönnek az olyan ámokfutások, hogy foglaljunk le még 20 MB RAM-ot, meg kit érdekel, mi hány órajel. Tudom, magas szintű nyelveknél ezt nem is lehet számolgatni, nem tudod, a kód mivé fordul, ráadásul fene tudja, a cache-ben van-e az adat, vagy egy memória olvasás birst-tel be kell-e rántani előbb a cache-be, stb.

Ugyanakkor nem adnék diplomát programozónak addig, amíg valamennyire nem tanul meg mikrokontrollerre assembly-ben programozni. Nagyon szemléletformáló tud ám lenni, ha néhány tíz vagy néhány száz byte - nem kilo, nem mega, nem giga - RAM áll a rendelkezésedre, s így kell megoldani a feladatot. Vagy netán van néhány tíz órajeled, s meg kell vele küzdeni.

Félelemetes, hogy egyesek mit művelnek programozás néven. Ők azok, akik felhasználók a gépen, s homályos sejtésük sincs arról, mi történik a géppel a programjuk hatására.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyet értek.Nekem tetszik is az assembly nyelv, volt is olyan óránk, de már vége. De elég keveset tanultunk belőle, tényleg csak az alapokat, meg régebben PIC-et "programoztam", de úgy, hogy már meg volt írva, csak értelmeznem kellett és pár apróságot módosítottam.

Igazából én nem szeretem ezeket a magas szintű programnyelveket... pont azért, mert nem tudom mi történik a géppel. Hardveres oldalról szeretem megközelíteni a dolgokat. Én is járta mérnök infóra 1 évig, de a mai napig nem tudom mit tanítanak ott, hogy konkrétan miről szól, mert ott van minden mint egy szemétdombon. Egy kis matek, egy kis jog, mellé némi villamosság, hozzá egykis programozás, de legyen még szoftvertech meg architektúra, politológia, kommunikáció meg ilyen szarok...

Hát ebből a mateknak volt valami értelme, a jognak is, de az nem tartozik a műszaki területhez, viszont általános alap dolgokról volt szó, amivel szerintem mindenkinek jó tisztában lenni. A programozás semmit nem ért, gyakorlatra a tanár nem nagyon járt be, az elméleti oktató meg bolond volt, (stand up comedy volt egy előadás) de legalább írt egy könyvet :P Szoftvertechnológia egy érdekes dolog, de szerintem túl részletesen kérik, miközben a tanár mindig hangsúlyozza, hogy a való életben ez nem így van... (de azért ezt tanuld meg :P) Egyébként egy az egyben Steve Ballmer hasonmás tartotta az órát :D

Architektúra volt a kedvenc tárgyam, azt most is tanulok, csak egyetemen az volt a baj, hogy a tanár össze-vissza dadogott, semmit nem lehetett érteni abból amit mond, nem tud hangsúlyozni. De szerencsére ott is volt könyv és azt nem magyar ember írta, tényleg jól érthető, levizsgáztam belőle simán... nem is 2-esre :)

Villamosságtan. Na ez ami még rohadtul érdekelt VOLNA... de megint csak a tanár :P Aki megmondta, hogy az infósok félévkor megbuknak. (mert együtt voltunk a villanytanosokkal előadáson) Vegyük úgy, hogy kb. 400-an vagyunk együtt, abból kb 200 infós. Félévkor 8-an mentek át. A villamosmérnökök kaptak valami user/pass kombót egy weboldalra, ahol voltak feladatok, ha beadták kidolgozva, kaptak rá pontokat, amik a ZH-nál is számítottak, így már eleve 2-esről vagy 3-asról indult nekik. Szóval ha csak a nevét írja rá, akkor sem 1. Nekünk ilyen nem volt :P
Aztán ők is a felsőbb évesekkel csináltatták.

Volt még digitális hálózatok. Na ott a tanár is egy eszméletlen nagy arc volt, meg maga a tárgy is nagyon érdekes, szerettem is, jó is lettem belőle :)

Szerintem egyetemen sokminden múlik a tanáron is... főleg azon, hogy mennyire tudja érdekesen előadni az anyagot. Jogon valami csaj volt, mindig figyeltem, mert jól nézett ki. Kommunikáción többet hiányoztam a kelleténél, de megoldottuk a tanárral a dolgot, picit többet kért tőlem, 1-2 éjszakába fájt a dolog, de végülis elfogadta.

Na de lényeg az, hogy direkt nem programtervező informatikusnak vagy matematikusnak vagy programozónak vagy valami ilyesminek jelentkeztem, mégis ezekből a tárgyakból volt a legtöbb, amit kicsit furcsálltam. Szóval ha még valamikor lesz rá lehetőségem (ami elég kétséges), akkor egy villamosmérnököt célzok meg inkább, mert mondhatni, az az életem. Minden amiben áram folyik... de leginkább amiben gyenge áram :) Meg a telekommunikációs hálózatok, internet, telefon, műholdas kapcsolat, stb... ha jól tudom villamosmérnök szakon van ahol van olyan, hogy infokommunikációs szakirány. Ez valami ilyesmit takar, azt hiszem.

Az volt a baj, hogy anno, nem tudtam hova jelentkezek, így 1 évem elment majdnem teljesen feleslegesen.

Bizony, amiben áram folyik, az csak jó lehet! :) (Villamosmérnök vagyok, így aztán elfogult némileg.)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Te nagyon kevered a dolgokat szerintem. Ha az ember Java programozó lesz, vagy Lisppel foglalkozik, köze nem kell hogy legyen a hardverhez. Nagyon csúnya példákat láttam pont Java kódban, amikor C-s szemlélettel esnek neki a dolognak.

Minden helyzetre megvan a megfelelő eszköz, ez az elvakult dolog, hogy MINDENKI programozzon assemblyben (amivel egyetértek, hogy nagyon hasznos tudás HA az ember hardverközelbe kerül), szóval ez káros. Nem optimalizálni tanít meg, csak a gép gépközeli működésére.
Nem véletlenül mondják, hogy először írj elegáns kódot (egyrészt a maintenance sokkal több pénz, mint a fejlesztés, másrészt bízz a fordítóban, a nyelvet úgy tervezték, hogy ami szép benne az általában jó is), aztán ha lassú akkor MÉRJ és úgy optimalizálj. Nagyon ritka az, hogy a közvetlen hardveres ismeret hasznos optimalizáláskor.
----
Hülye pelikán

Felreertetted. Nem azert kell assemblyben programozni, hogy ertsd mi tortenik a geppel, hanem hogy erzekeld azt, hogy a memoria meg a processzorido az nem olyasmi, amibol egy vegtelen, kimerithetetlen kut all rendelkezesre. En Java-ban is lattam mar rohadtul OOP es baromi lassu alkalmazast. Mert nem optimalizaltak le, minek, a processzor meg a memoria mindent elbir, nem? Hat nem.

En ugyan nem tudok PC-re assemblyben programozni, de Z80-ra tanultam. Nem konnyu eset, es nem is tanultam meg rendesen, de tudom ertekelni azt, hogy a programom nem 80MB-ot eszik csak 75-ot.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem látom az összefüggést. A legtöbb nyelven az elegáns kód egyben hatékonyt is jelent. Nem jó, ha assemblys tudás alapján akarok Javazni, vagy akár C-zni, egész egyszerűen hibás és ronda optimalizálások lesznek belőle. Bízni kell a fordítóban.
Az, hogy sok a pazarló program, nem az assembly oldaná meg.
----
Hülye pelikán

A fordítóban ugyan lehet bízni, de ha rosszul szervezed a brogramod, a fordító nem fogja azt újraírni helyetted. Szóval nem ártana a fordító keze alá dolgozni.

Lehet, hülye példát mondok, de ha páratlan címre allokálsz longot, az elég szerencsétlen bír lenni. Ha látod, hogy ezt csak több gépi ciklussal lehet elhozni, szemben azzal az esettel, hogy a változód címe mod 4 = 0, amikor is ugyanazt a változót egy ciklussal is elhozhatod. Nyilván nem az abszolút címet mondod meg, de az alignment-et már igen, valamint a struktúrában a változóid elhelyezkedését szintén.

Hasonlóképpen nem mindegy, hogy futásidő-igényes dolgot megszakítás rutinba teszel, vagy netán a megszakításba a legszükségesebbet írod, s alap szinten végzed a feldolgozást.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez a rosszul szervezés pontosan a nem-elegáns kódot jelenti. C/C++ alatt érdemes odafigyelni az alignmentre, hogy struktúráknál ne váltogasd az inteket meg a charokat, mert rengeteg kihasználatlan helyed lesz, de amúgy pont azért vannak a magasszintű nyelvek, hogy ezekre ne kelljen odafigyelni.

A példa tényleg hülye, mert azt, hogy hova allokáljak, nem én mondom meg jó esetben, hanem a fordító/runtime (attól függ, hogy allokáltam).

Az meg, hogy milyen procedúra hova kerül, végképp a fordító dolga. Ezekbe jobb bele se ütni az orrod, mert többet árthat, mint amennyit használ. A fordító jobban tudja, hogy használja ideálisan a regisztereket, jobban tudja, mikor inlineosítson, jobban tudja mikor hogy alakítson át egy ciklust (gcc O3 csodákat tud művelni, pontosabban nagyon át tudja szabni a kódot).
Röviden a programozó koncentráljon a karbantartható kódra, figyeljen oda az alapelvekre (pl C/C++-nál a struktúrákon belüli elhelyezés), és minden rendben lesz. Viszont ezeket az alapvelveket meg minden nyelvről szóló könyvbe le kéne írni, hogy az adott nyelvben mire kell figyelni.
----
Hülye pelikán

Nagyon hülye példát mondasz, mert a a malloc pl. garantálja, hogy jó lesz az alignment. Java-ban meg semmi közöd hozzá.

És ha statikusan foglalok egy struktúrában longot, char-t, long-ot? Vagy lyukas lesz, mint a sajt, vagy kellemetlen címre fog esni. És itt jutottunk el ahhoz, hogy mégis jó némi hardware ismeret az illető platformról. 8 bites CPU-nál például ez nem gond, ott mindenképpen 4 ciklus lesz 4 byte elhozása, vagy írása. Továbbá nem árt ismerni már csak azért sem a platformot, mert ha tudod, hogy nincsenek gépi szinten 4 byte-os utasítások, akkor nem fogsz egy kis egészt 4 byte-on tárolni, hanem beéred egy vagy két byte-tal. Rengeteg futásidőt visz majd el az, hogy átvitelt kell képezni a felső byte-okra, helyet is pazarolsz, csak minek.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

kerlek, soha ne nyulj Java kodhoz. egyel kevesebb kokler. koszonom!

Nem terveztem. Nem is beszéltem Java-ról. Ugyanakkor kicsit bővebben kifejthetnéd véleményedet, netán érvelhetnél is, mert ez így ebben a formában nem több cinikus személyeskedésnél.

Hallgatlak. Hol a hiba a fenti okfejtésemben?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ott a gond, hogy mint Java koder, engem baromira nem erdekel, hogy a CPU mit csinal. oszinten, tenyleg, magasrol teszek ra. majd a JVM megoldja nekem.

ha valaki nem ilyen szemlelettel ir Java kodot, valoszinuleg sosem fog jo kodot irni.

raadasul: Premature optimization is the root of all evil.

Érdekes érvelés. Éppen az ellen a szemlélet ellen írtam a fentebbiket, amelyet képviselsz. Magasról teszel rá, viszont meglátásom szerint ez nem helyes. Arról különben nem beszélve, hogy én általánosságban írtam a programozók jelentős részének azon szemléletéről, hogy mindent utálnak, amiben áram folyik, holott a hardware az, ami a kókálmányukat futtatja. Közel sem szűkíteném le a programozói tevékenységet Java kódolásra. Olyannyira nem, hogy az érdekességek nem is ott vannak. Izgalmasabb a dolog, amikor megszakításokat kell kezelned, nincs oprendszered, vagy ha úgy tetszik, te írod azt a réteget, amelyik elfedi előled a hardware-t, és így tovább.

Különben éppen arról beszéltem, hogy az általad is képviselt, bevesszük a leszarom tablettát, nem érdekel, az a compiler dolga, etc. szemlélet miatt tartunk ott, hogy a programok zabálják az erőforrásokat, sok 10 MB-ot foglalnak le indokolatlanul, nem takarékoskodnak a CPU idővel, a gépen belüli sávszélességgel, gondolok itt a felesleges adatmozgatásokra. Igaz, hogy nagyon absztrakt a kód, de nagyjából ez az egyetlen jó tulajdonsága.

Különben az sem véletlen, hogy a Linux kernel nagy részét C-ben írták, s nem C++-ban.

Elfogadom, hogy én nem fogok jó Java kódot írni, de ezzel a szemlélettel az a gyanúm, hogy hardware közeli kódot neked nem sikerül majd jól írnod.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

szerintem menj vissza PIC-eket programozni (vagy whatever, hidd el, annyira nem erdekel), a szakma tobbi reszet meg hagyd meg a hozzaertoknek. koszonom, megegyszer!

Most jön az a rész, hogy te eldöntöd, ki a hozzáértő, s mihez, továbbá ki mihez szólhat hozzá? :D


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

a Te esetedben eleg vegigolvasni amit itt muvelsz, miota reggeltel.

Miért, én eldöntöttem, hogy ki a szakértő, s miben? Megint megtudtam magamról valamit.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

nem, arra gondoltam, hogy siman le lehet vonni, hogy Te melyik kategoriaba tartozol. innentol pedig skippelni a hozzaszolasaidat.

Mik a lehetséges kategóriák?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Haaat, nezzuk csak, milyen kategoriakba lehet besorolni a huppereket:

Spammer - nemelyik ugy trollkodik, mint barki mas, nemelyik pedig csak az ingyenreklamjai posztolasaert regisztralt ide. Elso hangzasra az utobbit gondolnank rosszabbnak, de a tapasztalat ennek az ellenkezojet mutatja a hupon.

Ubuntu.hu-rol attevedt troll - par hete probalta ki az Ubuntut egy 3 eves gepen, de jobban tudja, hogy miert nem mukodik a 10 eve Linux es Unix rendszereket uzemelteto hupper gepen rendesen a Gentoo, mint barki mas (legalabbis szerinte). Talan naluk a legalacsonyabb a tudas/arcmeret keplettel szamolt valtozo. Altalaban hamar eltavoznak "hattyu halala" es egy "itt mindenki hulye MS berenc" mondat kozepette, extrem esetben nem onszantukbol.

Offseeker troll - neki legalabb onkritikaja van: mivel mar korabban tobbszorosen belatta, hogy az IT-hez o segghulye az itteni tobbseghez kepest, vegtelen okoskodasi vagyat mashol kell kielnie. Mivel altalanos muveltseggel eleg tagan rendelkezik, amint megjelenik egy off szal, o azonnal ra tud repulni, es ott meg akar igaza is lehet. Ha meg sincs, akkor is kisebb az eselye, hogy lesz valaki az oldalon, aki ezt tudja, mint egy IT-s temanal, igy akar okosnak is tunhet azok szamara, akik csak par topikot olvasnak el.

Autoszerelo - mindenki csak sejti, hogy hogy kerultek ide, de senki nem mer beszelni rola. Altalaban az eggyel fentebbi kategoriahoz hasonloan az offtopikokban a leginkabb megtalalhatoak, mert ok is szeretnenek elni az okoskodasi jogukkal, nekik koszonhetoek a "milyen autot" topikokban az 500. utani kommentek, IT-s temahoz ritkan szolnak hozza, es akkor altalaban egy autos hasonlattal mutatjak be teljes merteku inkompetenicajukat.

A humortalan barom - ha valaki viccel, o tuti nem fogja erteni, es bele fog kotni, meg ha mindenki mas szamara nyilvanvalo is a komment humorossaganak tenye. Termeszetesen szemelyeskedve szokta szamon kerni, hogy miert mondott az illeto ekkora marhasagot

Ideologista politikus - a szakmai vitakat - tudasa hijan - messzirol keruli, de eloszeretettel nyitogatja a mire keszul a kormany, mit csinal az ellenzek, milyen uj torveny/ado lesz, stb. topikokat, es ezeknek a topikoknak aktiv kommenteloje is velemenygladiator poziciojaban. Van ebbol extremebb eset is (alairasban politizal), de akire ez jellemzo, azt mar egy fentebbi kategoriaba betettem, igy nem reszletezem.

Wikifreak - baratnoje a Wiki (mint sok mas informatikusnak is), de o olyan extrem eset ezenbelul is, hogy meg megcsalni se szokta ot. Mindig minden komolyabb vitaban tobbszor ervel wikipedias linkekkel, ott megjelolt forrasok minosegetol fuggetlenul.

Ekezetnaci - ha nem tetszik neki amit irsz, megnezi, hogy irsz-e ekezetet, es ha nem, akkor annak a hianyaba is belekot

Anti-MS troll/GNU ideologista - egy gyakori reteg itt, akiknek nem lehet megmagyarazni, hogy nem felhasznalobaratabb bash scriptet iratni a userrel, mint kettot kattintatni vele. Agyukat teljesen elontotte az ideologia, javithatatlanok, egyetlen jogos ervuk az az, hogy a Windows-ert a Linux-szal ellentetben tenyleg fizetni kell, minden mas ervuk a teves ideologiajuk es a mosott agyuk kovetkezmenye.

Anti-Apple troll - egyszer 4-5 eve elvesztettek egy vitat, ami abbol allt, hogy nem tudtak a Mac Mini araert egy Mac Minit PC alkatreszekbol osszerakni, azota sajnos nem jutottak el pszichologushoz, ennek kovetkezteben rendszeresen rarantanak a pereskedos hirek olvasasa kozben, hogy nekik 5 eve igazuk volt, hogy az Apple rossz ceg.

Google fobias - rendszeresen hangoztatja, hogy a Google az marpedig mindent tud rola, bizonygatja mindenkinek, hogy a Google az nem jo ceg, sokszor osszeeskuves elmeleteket gyart, hogy a Google meg fogja tamadni az egesz vilagot a hadseregevel, es egyeb fantaziadus jovokepeket rajzol.

A profeta - elmejet wishful thinking vezerli, 5-10 evre elore tudja, hogy melyik termek es melyik multi fog csodbe menni, jellemzo joslas reszukrol az ARM CPU-k vegso gyozelme az x86 folott "elobb utobb meg szerveren is". Ha megmelited neki, hogy ez marpedig nem igy lesz, hamar megbanod, varhatsz 5 evet, mire kiderul, hogy igazad volt.

Szakmai hupper - ritkan szolal meg, altalaban azt a megszolalast tobb rohogogorcs elozi meg reszerol, az evek soran mar kialakult benne, hogy hiaba van igaza, mindent 3-4 linkkel ala is kell tamasztania, hatha akkor csak ketten fognak neki visszapofazni.

Titokzatos szakmai hupper - lustabb a fentebbinel, szelmalomharckent vitatkozik az okoskodo trollokkal, de aki sokaig olvas figyelmesen hupot, elobb utobb eszreveszi, hogy neki osszessegeben mindig igaza szokott lenni.

Szemelyeskedo balfek - senki nem tudja es senkit nem is erdekel, hogy igaza van-e, mindenki a stilusat kritizalja, mert az sokkal nyilvanvalobb, mint az igazsagtartalma, ameddig mar nem jutnak el az olvasok a szovegertelmezesben.

A "Nevertryed" BSD fan - kardoskodik valamelyik BSD rendszer mellett, hogy mennyivel jobb mint a Linux meg az osszes tobbi rendszer, holott soha sem probalta es nem is latta mukodesben egyik BSD rendszert sem semmilyen korulmenyek kozott.

Read only hupper - ritkan, vagy egyaltalan nem szolalnak meg, akar meg account-juk sincs. Bar ugy tunik, mintha nem is lennenek reszei az oldalnak, rengeteget olvassak, es nagyon jol tudjak, hogy melyik felhasznalo milyen gyakran szokott jot, ertelmeset illetve hulyeseget mondani, es rohognek a markukban, mikor valaki jatssza a hulyet.

:)

Ez idáig rendben is van. Úgy gondolom a HUP egy közösségi fórum is egyben. Hangulattól, a téma az egyén életében vett fontosságától, bármitől függően szólhat hozzá az ember. Ezen felül nem muszáj mindenben egyetérteni. Az IT igen nagy terület, nincs olyan, aki mindenhez egyformán jól ért. A konkrét vitában a dolog úgy áll, hogy egy olyan ember, akinek magas szintű programozásban van rutinja, vitatkozott egy olyannal, akinek hardware fejlesztésben, illetve ehhez kötődően alacsonyszintű programozásban van gyakorlata. Nyilván mindenki elfogult abban az irányban, amihez jobban ért. Én úgy látom a dolgot, ahogy írtam, ő meg másképp. Nincs abszolút igazság, mert akármilyen stílusban programozik valaki, annak lesznek előnyei és hátrányai. Mondok példát.

Optimális kódot ír az ember, lehetőleg hardware közeli nyelven, mint amilyen az assembly vagy a C. A program gyors lesz, kevés erőforrást fog enni futásidőben, viszont nehezen karbantartható, sok emberi erőforrást ezik meg. Ezzel szemben lehet software-esen szépészkedni, absztrakciókban bűvészkedni. Ez jó eséllyel kevésbé hatékony kódot eredményez, több erőforrást igényel futásidőben, ugyanakkor lényegesen kevesebb emberi erőforrást a kód későbbi továbbfejlesztése során. Most akkor kinek van igaza? Szerintem ez erősen feladattól függ. Mivel én a hardware-hez érzem magam közel, így ebben az irányban vagyok elfogult, s bizony, fogom a fejem, hogy programozók hogyan gondolkodnak néha. Erről írtam fentebb. Van, aki ezt másként látja, s olyan környezetben, ahol a gépi erőforrás az olcsó, az emberi erőforrás a drága, nyilván neki van igaza.

Ami a trollkodást illeti, én a fórumozást a közösségi lét egy formájának tekintem. Ennek megfelelően van, hogy szakmai szempontok alapján nyilvánulok meg, van, hogy hülyéskedek kicsit, van, hogy beszólok, ha valamivel nem értek egyet. Nem gondolom, hogy tudományos precizitással kell mindig megnyilvánulni, bár ennek lehetősége is adva van. Szóval az én megnyilvánulásaim vegyesek, úgy érzem.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Most akkor kinek van igaza?"

A megrendelőnek. Q.E.D.

----------------
Lvl86 Troll - Think Wishfully™

"Különben az sem véletlen, hogy a Linux kernel nagy részét C-ben írták, s nem C++-ban."

Hajjajj, ezzel de rohadtul mellélőttél :)
Nem véletlen, az az oka, hogy egyrészt amikor megjelent a Linux kernel a C++ még gyerekcipőben járt, másrészt vannak ezek a berögzült (begyöpösödött) C kóderek, akik szerint minden az ördög műve, ami nem C. Pedig a C++ tökéletesen alkalmas kernel fejlesztésre, hatékonyságban nem marad el a C-től, maximum gyorsabb lehet. Természetesen kernelnél nem használsz kivételeket, RTTI-t, de enélkül is rengeteg hasznos dolgot ad a nyelv, ami NAGYON hiányzik C-ből.

http://channel9.msdn.com/Events/GoingNative/GoingNative-2012
Itt valamelyik kérdezős sessionben Stroustrup nagyon szépen beszél erről. Mondhatod rá, hogy elfogult, de felesleges, az egy nagy ember.
----
Hülye pelikán

Persze, lehetne C++-ban kernelt irni, de szerintem nem erdemes. Sok helyen nem lehetne kihasznalni a nyelv adta lehetosegeket. pl. a "new" eleg hamar elfregmentalna a memoriat
Mashol meg kenyelmetlen lenne.

Ahol kenyelmesnek es jonak is ereznem az objektum orientaltsagot, az az IO alrendszer. Mar csak azert is mert ott a leggyakoribb, hogy mar a C megeroszakolasanak szintjere emelik a strukturak hasznalatat. Viszont ettol meg nem lenne olyan kenyelmes a C++ mint user space-ben.

Egyrészt saját new handler írásának TIPIKUSAN a kernel és az alacsonyszintű dolgok a színhelyei.
Viszont a szigorúbb típusosságot, a struktúrák okosabb kezelését, a templateket (template != bloat, a C++ rengeteg olyan templatet használ, ami fordításkor létezik, aztán kódba már nem kerül bele, lásd traits), meg még isten tudja micsodát.
Az objektumorientáltság pedig tipikusan nem való kernelbe. Még szerencse, hogy a C++ nem OO nyelv.

"Viszont ettol meg nem lenne olyan kenyelmes a C++ mint user space-ben."

Ezt senki nem is állította, azt állítottam, hogy kernel spaceben sokkal kényelmesebb lenne a C++ mint a C.
----
Hülye pelikán

+1

--
NetBSD - Simplicity is prerequisite for reliability

Kézzel optimalizálsz olyan dolgokat, amiket tutira megoldana helyetted a fordító is.
Nyerni nem nyersz semmi fontosat, cserébe sokkal hosszabb idő alatt készítesz el egy sokkal nehezebben karbantartható programot.

Ha otthon csinálod, hobbi projektben, a te dolgod.

De egy projektben a csapat többi tagjával szúrsz ki.

Azert az nem igaz, hogy mindent megold helyetted a fordito is. Az viszont igen, hogy a legtobb nyelvben a jo kod atlathato is, tehat ha mar nagyon csunya dolgokat muvelsz az valoszinuleg nem jo. (kiveve nagyon keves specialis esetet)

Csak olyan gépekben gondolkodtok itt néhányan, ahol gigahertzekben mérik az órajelfrekvenciát, s gigabyte-okban az operatív tárat.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

meg merem kockaztatni, hogy a fejlesztok 90% -a hasonlo gepekre fejleszt. fel kene mar ebredned, rajonni, hogy a kisebbseghez tartozol, es hogy kb majdnem senkit nem erdekel, hogy a CPU majd hogy pakolassza a biteket.

_ha_ beagyazott rendszerekre kodolnek, erdekelne. _amikor_ C -ben kernelt pofozok, erdekel. de Java programozokent baromira nem.

Ez tévedés. Viszont ilyen rendszerre nem fejlesztek nagyon magas szintű nyelven. Nem használok kivételkezelést, RTTI-t, és eleve odafigyelek.
----
Hülye pelikán

Az nem jelenti azt, hogy nem tudom, hogy mivé fordul le a kód.

De amikor belső ügyviteli folyamatokhoz készítek _desktopra_ alkalmazást, nem akarok foglalkozni azzal, hogy most mit hova pakol a memóriában a gép. (Ha már itt tartunk, ez géppel jól optimalizálható feladat.)

----------------
Lvl86 Troll - Think Wishfully™

Pedig ebben igaza van NagyZ-nek: esetek nagy részében, ha elkezded ilyennel szívatni a JVM-et, CLR-t, akármit, sokszor (nagyon csúnyán) többet ártasz, mintha békén hagytad volna. Vannak ilyen dolgok, amelyek alacsony szinten bár működnek, csak épp menedzselt nyelvekben pont, hogy telibe vered a nyelv optimalizálóját, ami miatt összességében sokkal-sokkal lassabb lesz.

Másik: nem csak abból adódik a különbség, hogy Java (vagy .NET, ilyen szempontból egy kutya), hanem abból is, hogy az adott nyelvhez tartozó környezet milyen. Ezeknél a keretrendszereknél a hatékonyság mellett az is kérdés, hogy mennyire lehet hatékonyan dolgozni benne, mert nagyon nem mindegy, hogy valamit 2 hónap vagy 1 év lefejleszteni. Másrészt vannak sokszor olyan patternek, amelyek kellenek ahhoz, hogy jól bővíthető, rugalmas és karban tartható kód legyen és ne keresztül-kasul hívogassuk a fél világot. Ezek is mind-mind olyan dolgok, amelyek keményen megtolják 5-10-20 elemmel a call stacket. Érdekel? Nem, mert ameddig ilyenről van szó, hogy 0.01 sec helyett 0.05 secet igényel egy művelet, ami egy gombnyomásra történik, addig nem fogok vele foglalkozni.

Majd, ha abból a műveletből egymilliót kell futtatni egyszerre, akkor foglalkozok vele. Ez nem zárja ki, hogy tudjam, hogy mi történik a dobozban, csak nem akarok egy szint alatt foglalkozni vele.

Szóval a világ nem fekete és fehér.

----------------
Lvl86 Troll - Think Wishfully™

Tevedsz, teged is erdekel, hogy mit csinal, csak te a CPU-t JVM-nek hivod. De ha azt vesszuk, Javaban a JVM-mel/bytecode-dal foglalkozni pont ugyanolyan alacsony szint, mint C/C++ eseteben a CPU-val/ASM koddal foglalkozni. :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

tevedes, ugyanis:
- en nem optimizalok a JVM szintjen, a JVM belso mukodese maximum a Java kodon nezett performancia miatt erdekel, vagy amiatt, hogy hogy lehet bytecodeot transzformalni
- a JVM bytecodebol nem lehet kovetkeztetni a gepi kodra, ami majd a JIT soran generalodik

- Nem mondtam, hogy optimalizalsz, azt mondtam, hogy foglalkozol vele. Sok olyan Java programozo van, akit a performancia vagy nem annyira erdekel, vagy nem is ert annyira hozza, hogy a JVM mukodesebe melyebben belelasson. Egy appszervernel pl. ugyis kismillio mas reteg is van, ahol lehet meg optimalizalni - es a legtobb Java koder ilyen kornyezetben dolgozik.
- ezt nem is allitottam. De a Java vilagban a bytecode megfelel az ASM kodnak, amennyiben az az um. "legalacsonyabb szintu" dolog, amivel meg foglalkoznak.

--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

hrgy, ne. kerlek.
a java bytecode az java bytecode, az asm meg asm.
ne akarj egyenlosegjelet eroszakolni kozejuk.
mire a java bytecodebol asm kod lez, eleg sok mindenen fog meg keresztulmenni.

A VM szempontjából a bytecode szerinted micsoda?

Csakhogy optimalizalni nem tudsz ra, mert a JIT compilerbe nincs belelatasod.

Viszont ha tudod, hogy milyen bytecode-k eredmenyeznek biztosan lassu kodot, akkor el tudod kerulni. Nem veletlen, hogy .Net-nel is nagyon szoktak nezegetni a generalt IL kodot, mert van egy csomo dolog, amirol tutira lehet tudni, hogy karos.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Van olyan operator, hogy hasonlo, azt hiszem egy egyenlosegjel es felette egy hullamvonal a jele neki, geometriaban hasznaljak, ha jol tudom. Na, arra gondoltam, nem igazi egyenlosegjelre.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Mondjuk azért elnézve a Minecraft visszafejtett kódját... a javac-nél is lenne azért mit optimalizálni bőven, pl. néhány triviális feltétel-kiértékelést.

----------------
Lvl86 Troll - Think Wishfully™

Az a probléma, hogy az egyetem nem Java/C# programozót képez, hanem programozót.
Az igazi programozó aztán képes elsajátítani akár a Java akár a C# akár bármelyik másik nyelvet és eszközrendszert ha a sors ere kényszeríti.

A kulcs ebben van. Aki nem képes erre az ne akarjon programozni, mert az minden nyelven csak kókányolni fog.

Aki meg nem képes egy ilyen szintű feladatot megoldani, mint a topiknyitó által felvázolt az menjen el kondásnak, de ne akarjon programozó lenni....

Uff...

Akik szakirányú szakmát szereztek szakközépiskolában - általában, akik nem gimnáziumba jártak -, sokkal gyakorlatiasabb látásmóddal rendelkeznek. Szerintem jobb szakközép után végezni az egyetemet. Mégis a gimiseket nyomják nagyon. Persze, mert nekik nincs szakmájuk, s akkor az érettségi szakma nélkül egy papír, ami arról szól, hogy az illető megtanult írni, olvasni.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Gimiből is jött ki szakbarbár, és szakközepest is ismerek, aki tisztességes programozó lett. Viszont vannak ilyen általános trendek, már a személyes megfigyeléseim alapján: a szakközepeseket nehezebb rávenni, hogy elvontan foglalkozzanak a kérdéssel, általánosan több esik neki a kódnak csúnyán. A legveszélyesebb, ha olyan nyelv közelébe kerülnek, ami nem akadályozza ezt aktívan (C, Perl). A gimisek sokszor balf*szok, de több elegáns kódot láttam a kezük alól kijönni.

Mégegyszer, mert tudom, hogy sok a gyengeelméjű: ezek általánosítások, az egyénre sosem vonatkoztathatók. Ráadásul személyes tapasztalat alapján.
----
Hülye pelikán

Tetra, én olyan családból jöttem, ahol a gimiseket dicsőítették és a szüleim azzal ijesztgettek, hogy ha rosszul tanulok, majd megyek a hülyék közé a szakközépbe.

Miután bekerültem az egyetemre, volt szerencsém végzett szakközépiskolásokkal is élőben találkozni és a személyes tapasztalat messze nem azt mutatta, hogy a gimisek az okosok, a szakközepesek meg a hülyegyerekek. Nagyon nem így van.

Az egyetemi oktatóimmal értek egyet: a gimnazistáknak az elméleti részek szoktak jól menni, a szakközepeseknek meg a gyakorlat. Gyakran kértem tőlük segítséget az egyetem alatt. Az egyetem befejezésével meg ugyanazt a diplomát kaptuk, függetlenül attól, hogy honnan jöttünk.

Gimi csak akkor, ha utána tovább tudsz (azaz tudod finanszírozni a kölöknek, hogy tovább tudjon) menni egyetemre.

Ez egyértelmű, hiszen a gimi nem ad szakmát...
----
Hülye pelikán

Értem én, hogy te honnan jöttél, de ez mennyiben releváns a témával kapcsolatban? Senki nem mondta (itt), hogy a gimisek okosak a szakközepesek meg hülyék.
----
Hülye pelikán

Persze, csak azt nem nézed, hogy mennyi szakközepessel NEM találkoztál az egyetemen. Az egyetem maga funkcionál szűrőként. Amúgy a szakközepekkel nem az emberek tudása szokott a gond lenni, hanem a viselkedése. (Tapasztalatom szerint. 8 osztályos gimnáziumból szakközépbe átsétálva azért elég durva fejeket tudtam vágni.)

Ezt közvetlen példával tudom cáfolni. Nálunk van szakmunkás képzés, szakközép, gimnázium, technikum és fősuli kihelyezett kar. Név szerint (teljesség igénye nélkül) pl: bádogos, lakatos, karosszéria lakatos, hegesztő, villanyszerelő, informatikai szakmacsoportos szakközép, redészeti osztály, ami gimnáziumi képzés, katonai osztály, sport osztály, gépész (szakközép, két tannyelvű, német bizonyítványt is kapnak), elektronikai technikus, gépész technikus, gépész mérnökasszisztens, informatikai mérnökasszisztens...

Ennyi féle ember jár oda. Régebben voltak közte érdekes egyedek, de 1-2 év alatt kihullottak és azóta igen nagy rend van. Ez köszönhető az iskola vezetésének. Nálunk nincs olyan, hogy a WC-ben dohányzik valaki. Azért akasztás járna. Hallottam olyan iskolákat a környéken, ahol drogoznak nyíltan az udvaron, órára bejárnak olyan emberek, akik nem is járnak iskolába (tüzet kérni meg zsepit, meg ilyenek)... a tanárokat befenyítik, stb. Nálunk ilyen nincs. Már csak a katonai meg rendőr tisztek jelenléte is megkövetel egy bizonyos szintű fegyelmet. De a legtöbb férfi tanár is olyan szerencsére. Pedig régen aztán itt is volt ám 3. emeletről ajtó kidobás, meg szalonnán csúszkálás és hasonlók. 4-5 éve változott az egész vezetés, és azóta be van kamerázva az udvar, a gyerekkel aláírattak egy papírt, hogy ha dohányzáson kapják, akkor az iskola mentesül a büntetés alól, mert előra figyelmeztették és ezt ő aláírta. Az udvaron lehet dohányozni egy nem hivatalos helyen, ha valakit rajta kapnak, az onnantól kezdve az ő baja.

De nálunk ez a legnygyobb probléma. Órák alatt nem lehet hangoskodni egyáltalán sehol és ezt be is tartják, egy ideje rongálások sincsenek, még egy árva padfirkáért is jár valami, a tanár minden óra végén megnézi a padokat. Például az infótermeket van amit nyitva hagynak és bent maradnak a diákok, de mire vissza ér a tanár, minden a helyén van, nem kezdik el kilopni az alkatrészeket meg szétbontani a termet. Régen ez szokás volt... meg átapcsolgatni a tápot 110V-ra menet közben. Valami történt. Ott, abban az iskolában tényleg... élvezet bejárni :)

Sokan nem hiszik el nekem, pedig ez így van. És oda aztán tényleg jár mindenféle ember.

Tehát egy általános tapasztalatot cáfolsz EGY személyes példával. Logikus.
----
Hülye pelikán

plz read again, lócsemege is pont ezt mondta, amit te az első mondatodban.

És igen, a gimnazisták absztraktabb képet kapnak a világról, ezért nem kezdenek el -ben munin-t írni, hanem keresnek és megtalálják a munin-t. Érted...
És igen, a gimnazisták meg gyakorlatlanok. Mintha nem is illene bemocskolniuk a kezüket kódolással. Én gimibe jártam, 4 éven át halmazelméletből vezettük le a matematikát meg Delphiztünk. Kisebbik öcsém meg valami híradós szakközépbe járt, csak néztem, amikor mesélte, hogy miket tákoltak, majd kódoltak rá.

Senki sem akadályozza meg a gimist, hogy nekiálljon kódolni. Én azt vettem észre, hogy úgy általánosságban (ami statisztikát jelent, nem egyént) szélesebb a látóköre a gimnazistáknak, ami egy bizonyos szint felett határozottan előny. Azalatt pedig lehet hátrány.
----
Hülye pelikán

Hát, ahogy idősödöm, évről-évre egyre kevésbé értékelem a gimnáziumi tudást.

Szerintem sokkal többet ér az, ha tudsz heggeszteni, forrasztani, értesz a villamossághoz, minthogy bevágod, hogy Mikszáth Kálmán mikor élt, vagy éppen tudod, hogy mi az az Anschluss és mikor volt. Gimnázium után külöbséget tudsz tenni a téma és a réma között, ismered az alanyt az állímányt és a határozókat, megismered Kantot és a többi filozófus elmélkedéseit is, amivel le tudod majd kötni magad közmunka után.

Mert ugye a látóköröd gimnázium után bizony széles lesz, rengeteg teljességgel felesleges tudást kapsz, amit utána maximum bedughatsz a ...., mert a mindennapokban semmire sem fogsz menni vele.

Látom valami nagyon szúrja az oldalad a gimnazistákkal kapcsolatban. Én értékelem, hogy sok biológiát, kémiát, fizikát tanultunk (ahhoz képest, hogy elvileg humán gimi volt). Te szerintem kevered a bölcsészeket a gimnazistákkal. Tény, hogy az osztályból csak kb a negyede ment műszaki pályára, de azok nem lettek rosszabbak, mint a máshonnan jövők.

Az meg, hogy szerinted nem fontos tudni ilyeneket, hogy mi az az Anschluss... erre nehéz mit mondani. Persze, a mindennapi életben nem segít, de látok embereket, akik történelmileg teljesen képzetlenek, és szerintem szegényebb tőle az életük, nem szeretnék úgy élni. Jó kontextusba helyezni a világunkat. Persze nem kell mindenkinek ez, de én szeretném magam legalábbis értelmiségi-kezdeménynek tudni. Ha te csak szakma adóként tekintesz az egyetemre, akkor rosszul teszed. Egy szakmához sem kell öt év elmélet, márpedig az egyetemek elsősorban elméletet oktatnak. Sok ember fejleszt szoftvert egyetem nélkül.
----
Hülye pelikán

A fizikával, matematikával semmi bajom nincs.

A biológiával sem lett volna bajom, ha a "riboszomatikus enzimfehérjék abszorbciója" stílusú mondatokat mellőzték volna a tankönyvből. A könyv leginkább az "Antantémusz, szórakatémusz" rituális ráolvasásra hasonlított, ezért nem tudtam vele mit kezdeni. Lenne értelme a biológiának, de nem így.

De tanultunk történelmet, filozófiát, nyelvtant, irodalmat (minden nap volt magyar), amiknek valljuk be sok értelme nem volt...

Fizika: fluxus, RLC-körök, Kirchoff-egyenletek (még a villamosmérnökök sem használják),...

Az RLC kör az mondjuk kegyetlenül fontos a középiskolásoknak. Tudni kell, hogy az induktivitáson/kondenzátoron siet-e a feszültség, vagy késik (siet-késik ez mekkora ökörség)...

A gyakorlati oktatása a kapacitásnak, induktivitásnak, tranzisztornak talán értelmesebb lett volna, mint az RLC kör és a fluxus. Legalábbis szerintem.


Fizika: fluxus, RLC-körök, Kirchoff-egyenletek (még a villamosmérnökök sem használják),...

:D:D:D


A gyakorlati oktatása a kapacitásnak, induktivitásnak, tranzisztornak talán értelmesebb lett volna, mint az RLC kör és a fluxus. Legalábbis szerintem.

kapacitasnak es induktivitasnak nincs koze a gyakorlatban az RLC korokhoz :D

---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering

Arra gondoltam, hogy kapacitásra / induktivitásra, mint energiatároló elemre kellene gyúrni.

Hogyan lehet késleltetni vele, tölteni, kisütni, villogtató elektronikát építeni kapacitásokkal és tranzisztorokkal.

Bocs, de a villamosmérnökök sem nagyon számolnak tápegység kisimításánál.

t = R * C
R = U / I

képletek nem túl bonyolultak, legalábbis én ilyen szellemiségben számolok. A dolgok lényegét kell megérteni és akkor primitív módszerekkel közelítheted a végeredményt.

Majd hülye leszek kiszámolni differenciálegyenlettel, hogy 1976.6 uF-os kapacitás kell, amikor a boltban ilyen nem is kapható.

Az összes korábbi hozzászólásoddal egyetértek, itt azért vitatkoznék kicsit.

A fázisban siet, késik egyfelől igaz, másfelől viszont nem fejezi ki a fizikai tartalmat. Tehetek én arról, hogy a dsin(x)/dx = cos(x), aztán ugyanakkor az is igaz, hogy cos(x) = sin(x+pi()/2)? Na ugye! :) Szóval siet az, meg késik, de csak azon véletlen okán, hogy az egyik függvény adott időbeli változási sebessége éppen a másik függvényt adja, s nem tényleges időbeli eltolásról van szó. Ha így lenne, akkor a kondenzátor árama a jövőt is tudná. Izgalmas ez az időgép. :)

Ami az RLC köröket, mágneses köröket, Kirchhoff-egyenleteket illeti, használják a villamosmérnökök. Egyrészt, a (lineáris) villamos hálózatanalízis arról szól, hogy az áramkör gráfjából felírsz n darab független egyenletet, azt meg ugye tudjuk, hogy ha van n darab független egyenletünk, s ugyanannyi ismeretlenünk, az megoldható, például Gauss-eliminációval. Ezeket az egyenleteket éppen a Kirchhoff-egyenletek alapján lehet felírni, s így kapod azt az együttható mátrixot, amellyel az ismeretlenek vektorát szorozva kapsz egy vektort. Meghatározandók az ismeretlenek.

A mágneses körök pedig elég hamar előkerülnek, ha például kapcsolóüzemű tápegységet, vagy netán villamosgépet tervezel.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

- Kirchoff egyenletekkel még nem láttam senkit idáig számolni: csomóponti potenciálok és hurokáramok alapján számolnak.
- a -1 fok kicsit késik, a 359 fok nagyon siet? (elméleti problémám van a siet-késikkel)

A csomóponti potenciálok módszere nem más, mint minden csomópontra felírni Kirchhoff I. törvényét (ΣI=0), a hurokáramok módszere pedig a független hurkokra felírt Kirchhoff II. törvénye (ΣU=0).

A siet, késik fogalmát -π < φ ≤ π halmazon értelmezném.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mégsem tanítják a gimiben, pedig rohadt egyszerű számolni vele.

Marad a jó kis gyakorlatban használhatatlan elmélet.

Attól függ melyikben... Nekem pl. tanították. Dolgozat nem volt belőle, csak elméleti, viszont akit érdekel az ilyesmi annak ott volt a lehetőség, hogy megtanulja. (Oldottunk meg vele problémákat órán.)

Most hagyd abba, mert amit mondtál, az a realloc hardveres változata :-).
Locsemege le is írja, miért.

Ne fájdítsd villamosmérnök szívemet :-).

- dupla -

Nézd, nálunk az egyetemi oktatók kérték, hogy ne használjuk a siet-késiket, mert nem fedi a valóságot és fizikai tartalma sincs.

Azt javasolták, hogy "más fázist" használjunk helyette.

A nagyon siet, nagyon késik között epszilon különbség van. Ráadásul a sin/cos függvények úgy folytonosak, hogy végtelenszer deriválhatóak 180 foknál!

Egyébként próbálj a témánál maradni és ne keverj bele 20 évvel ezelőtti hozzászólásokat. Hidd el, értelmesebben lehet így beszélgetni és nem megy el a téma személyes vagdalkozásba.

A sin/cos mindenhol végtelenszer deriválható, és mivel periodikus ezért ha pínél igaz rá valami, igaz lesz pí + k*2*pí-nél is, k egész.

De hogy ne kötekedjek (értelmetlenül, hiszen az ellenkezőjét te sem állítottad), erről az jut eszembe, amikor sok félév analízis meg egyéb matek után bevezettük a "majdnem minden n" fogalmát, na az meglepő volt. Oké, hogy kapott egzakt definíciót, de valahogy furán állt Simon szájában ez a látszólag pongyola kifejezés :)
----
Hülye pelikán

A hurokáram/csomóponti potenciálra gondoltam elsősorban.
Erre azt mondani, hogy "nem használják a Kirchhof-egyenleteket" meredek. Ebből az szűrődhet ki, hogy a lényeget nem érted, ami sose jó. Főleg az EVT-nél (aki érti, érti).
Az, hogy késik vagy siet, az szemlélet kérdése. Ez viszont nem.
Másrészt a :-) nálam csipkelődést akar jelenteni, nem sértegetést. Igyekszem visszafogni, látom, zavar.

A hurokáram/csomóponti potenciálok a Kirchhoff egyenletek összevont formái.

A Kirchhoff egyenletek számolásra gyakorlatilag alkalmatlanok, mert kismillió egyenlet van és nem mindegy, hogy 4 egyenletet, vagy 12-15-öt számolsz végig.

Igen, meg kell tanítani a Kirchoff egyenleteket és ki kell egészíteni a két egyszerűsített módszer legalább egyikével.

Használható dolgot kell a gyermekeknek megtanítani, az elméletnek és a gyakorlatnak találkoznia kellene.

Mindenképpen el kell kerülni, hogy tanítanak valami szart a pedagógusok, amit a büdös életben semmire sem tudsz használni. Ezt kell látni, hogy 12 évet ültem gimnáziumban / általánosban, ebből 4-5 évet teljességgel feleslegesen, mert már nem emlékszem arra, amit tanítottak. Oroszból már csak a "nye pamagáj"-ra (ne segíts) emlékszem. Minden héten két oroszóra is volt, feleslegesen.

Mély tudása a diákoknak akkor lesz, ha képesek a megtanult anyagot a mindennapi élettel összekötni. Egyébként időkidobás. Öveges professzor sikere éppen abban volt, hogy mindennapi jelenségeket mutatott be és számolt végig a gyermekekkel. Megértették a tanulók és egy életre megjegyezték. Tudták hová tenni a dolgot.

Velünk számoltattak fluxust, RLC-t, minden szart, megírtuk a dolgozatot, utána elfelejtettünk mindent. Az egyetemen pedig mindent leadtak újra, mert a gimnáziumi tudás használhatatlan volt alapnak.

természetesen tanár és tanár között is van különbség.

A fizikát és a biológiát szidom és nem a matematikát. Nekem kizárólag normális matektanáraim voltak, ezért nem beszélek matematikáról semmit.

Persze elképzelhető, hogy ha például jó fizikatanáraim lettek volna, pocsék matematika tanárok, akkor más véleményem lenne.

Velem pl. ez volt. A fizika tanárom szerintem az eddigi legjobb tanár volt, matematikából meg azon a szinten jártak a tanáraim, hogy feladunk 100 feladatot minden óra után házinak és akkor majd tudja a diák. Igaz, hogy nem tudja mit csinál, mert csak ismétel, de ez nem gond. Eredmény: szét untam a fejemet és nem csináltam meg a feladatokat. A dolgozatokkal utána csak azért volt gondom, mert (mivel nem 1000x láttam ugyanazokat a feladatoka) lassabb voltam mint a többiek. Igaz, hogy azért mert tudtam, hogy mit csinálok, de ez nem gond.
A vicces az volt, hogy pont emiatt valós helyzetekben (pl. fizika) sokkal használhatóbb volt a tudásom mint a többieké.

"De tanultunk történelmet, filozófiát, nyelvtant, irodalmat (minden nap volt magyar), amiknek valljuk be sok értelme nem volt... "

Ó istenem. Értem már. Nézd, más világban élünk. Számomra fontos dolog, hogy az ember a világban el tudja helyezni magát. Te forrasztani akarsz. Értem én, de ettől még ne ócsárold a gimit, mindenkinek másra van szüksége, és ugyanolyan jó szakember lehet gimnazistából, mint szakközepesből, és fordítva is igaz, mindkettő lehet rossz szakember is.
----
Hülye pelikán

Ez igaz. Az egész onnan indult, hogy mondtam, szakközépből jövők gyakorlatiasabban állnak a dolgokhoz. Számomra elég vicces, hogy végzett villamosmérnöknek gondjai támadnak, ha meg kell forrasztania valamit, vagy mérni kellene. Márpedig a mérnök mér. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez korrekt, csak nem értettem, egy progtervmatosnak/infósnak miért kéne feltétlenül assemblyvel foglalkoznia. Jó az szemléletet adni, csak nem mindenhova kell az a szemlélet. Én speciel assemblyztem, kell is a tudás, de másnak meg nem fog kelleni. Ahogy a nyomtatóbeállítás (nagyon komoly nyomtatók vannak :D) és a CPU hegesztés sem alapfeltétele a szoftverfejlesztőnek.
----
Hülye pelikán

Az attól függ, mire fejlesztesz software-t. Nem csak PC van a világon, meg mobiltelefon. Lehet olyan, hogy oprendszered sincs. Aztán valahogy meg kell oldanod a párhuzamos folyamatokat, lehetőleg hatékonyan, mert RAM-od a legkevesebb. Vannak regisztereid meg utasításaid. Jó, tudom, az is egy megoldás, hogy odaadod a hardware-esnek, b*szódjon vele ő. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem azt mondtam, hogy nem kell olyan szoftverfejlesztő, aki ért ehhez, hanem hogy nem kell MINDEN szoftverfejlesztőnek értenie hozzá. Látod, rád is rádférne egy formális logikai kurzus :)
----
Hülye pelikán

Ha már itt tartunk, egy mérnök informatikusnak miért kell kötelezően villamosságtan meg elektro? :)

(Biztos velem van a gond, de nem sikerült megbarátkoznom semmivel, ami a digitális technika szintje alatt van. Onnan kezdve viszont az archin, és a low level dolgokon át egészen a magas szintű fejlesztésig gyakorlatig végig érdekel.)

----------------
Lvl86 Troll - Think Wishfully™

És forgácsolás (gápgyagya), meg mechanika, meg...? Ja, mert arra van oktató...

Ha nincs efféle ismereted, hogyan mérsz meg egy hibát? Én oszcilloszkóppal megtaláltam egy VIA chipset DMA bugját, aztán kiderült, a Linux kernel fejlesztői is megtalálták már. Előtte kihullott majdnem az összes hajam.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tipikus scenario, amivel nap, mint nap meg kell küzdenie minden egyes informatikusnak.

----------------
Lvl86 Troll - Think Wishfully™

valoban nem talalkozik vele az ember minden nap. de ha talalkozik, akkor ez a plusz tudas artalmas?

---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering

Nem olyan reg terjedt fb-n az egyetem vs valo elet cimu kep, amit most hirtelen nem sikerult elokeresnem, pedig jol jellemezte volna a problemat: egyaltalan nem vagyok meggyozodve, hogy azzal a tudassal meg tudnek oldani valamit, ha kapnek egy valodi ilyen feladatot.

Masreszt, ha eziranyu erdeklodeseim lettek volna, akkor a szomszedba (Kando) jelentkeztem volna.

Artani persze nem fog, leszamitva, hogy a mernok info szak jelenleg kb. a mindenbol egy keveset, de ugy igazan semmit szak.

----------------
Lvl86 Troll - Think Wishfully™

Ártani nem árt, de sok kapacitást elvesz: ez egy másik szakma.
----
Hülye pelikán

+1
Ilyen erovel tanuljunk anatomiat is. Vagy eppenseggel belgyogyaszatot. Nem artalmas az a plusz tudas.....csak eppen nem mindenkinek kell tudnia.

Egy baj azért van ezzel a szemlélettel. A software-t hardware-re írod, az előbbi az utóbbin fog futni.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem, én a szoftvert legdurvább esetben is az oprendszerre írom. De sokszor inkább jónéhány réteggel még afölé. A céges komolyabb performanciaigényű dolgokat sem közvetlenül a hardverre írjuk, jó vaskos réteg van köztem és a hardver között.
----
Hülye pelikán

Azt hiszem, ez nagyon jól összefoglalja, hogy milyen mélységekig lehet letúrni és a konklúziót jól levonja, hogy a gyakorlatban miért nem fog mindenki kioptimalizálni szénné mindent.

http://tothviktor.wordpress.com/2010/12/04/mire-optimalizalsz/

http://tothviktor.wordpress.com/2011/08/22/mikro-optimalizacio-i/

Szóval összefoglalva: jó dolog, ha valaki tudja, hogy mi van a dobozban, csak nem akkor, amikor megpróbálunk okosabbnak tűnni a fordítónál annak pontos ismerete nélkül. Mert az ASM-et ismerni egy dolog. Viszont, hogy igazán hatékonyan tudjunk dolgozni, nem ártana ismerni az adott processzor mikrooptimalizálásait (ugye CPU-nként változik és viszonylag rengeteg van belőle).

Magasabb szinten - mint ahogy a cikk is írja - a fordítók számítanak a tipikus kódfordulatokra és megpróbálnak arra optimalizálni (hisz, "könnyen", nagy teljesítmény-javulást lehet elérni), ami miatt macera, ha erőlködik az ember.

Aztán meg ott van az is, hogy mit fizet ki a megrendelő. És márpedig a megrendelőnek van igaza.

Szerk:

És még egy: http://tothviktor.wordpress.com/2011/08/23/if-vs-switch/

----------------
Lvl86 Troll - Think Wishfully™

Persze, hogy nem tipikus. Viszont előfordulhat. Én is cirkuszolhatnék, hogy hardware-es vagyok, semmi közöm a software-hez, aztán mégis programozom olykor. Az IT egy nagy terület, a valóság meg nem kímél. Többnyire megoldás kell a problémára, nem kifogás. Azt az ügyfél nem látja, hogy mennyire szép absztrakciókkal érted el az eredményt, vagy mennyire gányoltál, azt viszont nem tudja nem észrevenni, ha a szerkezet nem működik.

Különben nálunk az oszcilloszkóppal történő hibakeresés teljesen bevált technológia. Akkor, amikor hardware folyamatokhoz képest kell megállapítani, egy software hol tart, mit csinál, s miért nem :), akkor bizony nagyon jó tud lenni, ha teszem azt, egy mérőponton software-ből triggereled az oszcilloszkópot, vagy nézed meg, mi hány nanosecundumra van egymástól.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az remek, de most megint a saját világképedet próbálod ráerőltetni oda, ahol a hardware kimerül annyiban, hogy van néhány ronda doboz a sarokban egy polcon, amit etetni kell a 230V-al.

Korábban webes rendszereket fejlesztettem, most desktop/server appot. Itt többet számít a jó architektúrális felépítés és az absztrakció és az oszcilloszkóp maximum egy cikként kerül elő a cikkek táblában.

----------------
Lvl86 Troll - Think Wishfully™

Ez ideáig rendben is van. A szál nagyjából az oktatásból indult, abból, hogy miért kell elektrotechnikát tanulni programozónak. Azért, mert nem mindenki csak webfejlesztő lesz szerencsére, vannak határterületek, műszereket, ipari berendezéseket, orvosi eszközöket is programozni fog valaki. Ha olyan lenne a képzés, hogy erre definíció szerint senki sem képes, az szerinted egy jó oktatási irány?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A kérdés az volt, hogy miért kell MINDEN programozónak ezt tanulnia, amikor elenyésző részüknek lesz szüksége rá.
----
Hülye pelikán

Talán azért, mert az egyetemi évek alatt még nem tudod, pontosan melyik cégnél fogsz dolgozni, az a cég egyáltalán talpon marad-e vagy csődbe megy, és így tovább. Mekkora jóság lenne már, ha az orvosoknak nem kellene megtanulni az anatómiát, az elsősegélynyújtást, hanem csak a szűken vett emberrészhez kellene értenie. :( Virágoztassuk fel a szakbarbár-képzést! Hurrá.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az eleje bullshit, nyílván nem tudod előre, hol fogsz dolgozni, de mivel a szakmának nem szoros része, ezért az tanulja csak, aki szeretné.
A második része pedig színtiszta demagógia. Gratulálok.
----
Hülye pelikán

Remek, viszont te láthatólag nem tanultál meg magas szinten programozni. Pedig azt is elvárják ;)

----------------
Lvl86 Troll - Think Wishfully™

Amennyire elvárták, annyira megtanultam. Tegyük hozzá, nem vagyok programozó matematikus. A legfőbb különbség talán az, hogy én nem lázadtam ellene, sőt, nem bántam volna, ha többet, s jobban tanítják.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Túlélted, nem?

"Azt az ügyfél nem látja, hogy mennyire szép absztrakciókkal érted el az eredményt, vagy mennyire gányoltál, azt viszont nem tudja nem észrevenni, ha a szerkezet nem működik."

azt viszont igen, ha a nem megfelelo tervezes, absztrakcio miatt a masodik korben szetesik az ami az elsoben mukodott.

Félreértjük egymást. Nem azt mondtam, hogy nem kell szépen programozni, erre törekedni, pusztán a dolgok fontosságára utaltam. Ha valami nem működik, az rosszabb, mintha valami működik, még ha ez utóbbi barkácsolás eredménye is. Továbbra is meggyőződésem, hogy kellenek elvi alapok, minimális hardware ismeretek a programozóknak, ellenkező esetben fogalmuk sincs, mit miért csinálnak, s nem látják a fizikai korlátokat, csak eszetlenkednek, mint ahogy ezt nem kevés project igazolja is manapság. Nézzük meg, egy Windows 3.1 vagy Windows 95 milyen hardware-en futott, s azon a hardware-en mire mennénk manapság. A szolgáltatások nem fejlődtek annyit, mint amennyit nőt a hardware igény. Tehát a hatékonyság romlott.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Ha valami nem működik, az rosszabb, mintha valami működik, még ha ez utóbbi barkácsolás eredménye is."

egyetertek.

"Továbbra is meggyőződésem, hogy kellenek elvi alapok, minimális hardware ismeretek a programozóknak"

nyilvanvaloan valamennyire erdemes ismerni. csak teljesen mas a sulya, amikor x reteggel feljebb vagy, egy magasszintu nyelvben. teljesen mas a kornyezet, mas tudast, gondolkozasmodot igenyel egy hardware kozeli problema megoldasa mint egy uzleti problema megoldasa egy rendkivul absztrakt software-es terben. ettol fuggetlenul termszetesen hasznos, ha valaki a masikban is jaratos valamennyire, mert fejleszti a gondolkodasmodot.

"A szolgáltatások nem fejlődtek annyit, mint amennyit nőt a hardware igény. Tehát a hatékonyság romlott."

ezzel nem ertek egyet.

Mert ezektől lesz mérnök-informatikus, és nem favágókóder. Annak, aki csak egy-két nyelvben akar úgy-ahogy működő kódot írni. bizonyára van valamilyen kellemes OKJ-s programozóképzés.

Nem lehet 2^n-féle szakot indítani, aszerint, hogy az embereket melyik tárgy érdekli, és melyik nem. Az egyetem egy szakról kiállított diplomával tanusítja, hogy neked elmondta valaki azokat a tárgyakat, amit ők jónak tartottak, és átmentél a vizsgán. Ha az egyetem elég jó nevű, akkor ez jó pont lesz az állásinterjún. Ha neked nem azok a tárgyak tetszenek, akkor megtanulod magad, ami neked tetszik. De akkor az állásinterjún helyben kell meggyőznöd a leendő főnöködet a tudásodról, nem lesz egy előre kiállított igazolásod róla.

Szerintem normális esetben a diploma ennyi, egy igazolás arról, hogy valaki ellenőrizte már a tudásodat, tanulási készségedet. Ha az illetőnek jó neve van, ér valamit, ha nem, nem.

A mérnök informatikus eredetileg műszaki informatikus, ami meg eredetileg "villamosmérnök, amelyik tud programozni is", csak hát bologna óta ez is elbaszódott.
A mérnökön van a hangsúly, nem az informatikuson.

Az egesz problemanak az a forrasa, hogy nincs normalis szoftvermernok-kepzes ma az orszagban. Pedig kellene.

Ugyan, választott politikusaink nem értik e szót.

"De tanultunk történelmet, filozófiát, nyelvtant, irodalmat (minden nap volt magyar), amiknek valljuk be sok értelme nem volt... "

Hátizé... Pedig, ha valaminek van értelme, az a történelem, a nyelvtan és az irodalom.

Btw. Néhány éve abból élek, hogy olyan emberek után takarítok és tervezek normális rendszert, akik jól tudtak gyorsan tákolni ;)

----------------
Lvl86 Troll - Think Wishfully™

Mégegyszer, mert tudom, hogy sok a gyengeelméjű: ezek általánosítások, az egyénre sosem vonatkoztathatók.

Hagyjuk már a fenébe ezt a kínosan feszengő polkorrektséget, mert undorom van tőle. Utálom a politikailag korrekt embereket. (Néha én is beleesek ebbe. Akkor kénytelen vagyok magamat is utálni. :))


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Értem én, én is gyűlölöm amikor kiköti valaki, hogy de nekem van cigány barátom, csak sokszor méteres fonalakat segít megelőzni egy ilyen kitétel. Nem véletlenül van itt a gyengeelméjű kitétel. Viszont egyre toleránsabb vagyok, lehet ez elpuhulás, de mindenesetre megtörténik. Már nem ugatom le az ilyet, mostanában csak figyelmen kívül hagyom :)
----
Hülye pelikán

Egy volt kollégám néha úgy írt meg ideiglenes, debugolást segítő programot, hogy változót is lusta volt deklarálni, közvetlenül memóriacímre hivatkozott az utasításban. :D


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Miután a cégeknek legtöbb helyen nem mérnöki munka kell, hanem valami megoldás gyorsba, olcsón, mit vársz?

Mert ha befektetnének egy rendes megoldásba, akkor jóval nagyobb költségekkel kell számolni, addig a konkurencia megelőzhet valami ideig-óráig működő gányolmánnyal, stb.

----------------
Lvl86 Troll - Think Wishfully™

tenyleg ez a helyzet a legtobb cegnel. az a baj, hogy nem gondolkoznak hosszabb tavon. csomo tarthatatlan hatarido abbol adodik ezeknel a cegeknel, hogy korabbi, osszeganyolt rendszereket kell tovabbfejleszteni, karbantartani, ami miatt rohejesen sok munkaora eluszik, igy az uj projektekre szinten irrealis hatarido keletkezik. mi ennek a vege? az, hogy 2-3x annyiba kerul a cegnek is szarul csinalni, mintha jol csinalta volna mar az elejen, esetleg kicsit tobb kezdeti raforditassal. aztan ez megy korbe korbe. ez szerintem a sok kokler mellett a management hibaja is.
szerencsere azert vannak helyek, ahol ez nem igy megy.

Nocsak, egyre több informatikusnak van nemi élete? :DD


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nyilvánvalóan. Ezért vannak egyre többen. :D
Mivel egyre többen vannak ezért nő a szakbarbárok száma is, vagyis hígul a szakma. Emiatt egyre többnek van nemi élete. Innentől kezdve loop...

Pár év és kihalnak a mai értelemben vett informatikusok.
Átveszik a helyüket a csak magas szinten programozó,
bitekre mit sem adó,
gigahertzben gondolkodó,
JVM-re hagyatkozó
szörnyetegek. :)

Találkoztam már informatikussal, aki nem tudta fejben a D9-et decimálisra átváltani.

Hova lehet még tovább süllyedni?

Például ha már írásban sem tudja, az szerintem még rosszabb. :)

Hát, láttam ennél rosszabbat.

Kérlek, fejtsd ki, hogy hogyan lesz valakiből jó szoftvertervező attól, hogy fejből ki tudja számolni, hogy 13*16+9.

----------------
Lvl86 Troll - Think Wishfully™

Inkább ne :-).

Találkoztam már olyan informatikussal, aki nem volt képes leírni, hogy 0xD9 vagy D9h vagy $D9 és feltételezte, hogy majd kitalálják mire gondolt. Az valószínűleg eszébe sem jutott, hogy ez nem feltétlenül egy hexadecimális szám.

Megjegyzem: Én sem váltanék át hexből decimálisba fejben, mert felesleges és egy átváltási hibánál több idő megy el a javítással.

A hexadecimális számrendszer [0-9A-F] számokból áll. x, $, h az nincs benne.

Ha már kötözködni akarunk a definíciókkal.

igen, viszont a D9 onmagaban nagyon sok mindent jelenthet. Ha 0xD9-et, $D9-et, vagy D9h-t irsz, akkor sokkal konnyebb kitalalni, hogy mire gondoltal. Foleg, hogy a D9 akar lehet 64-es szamrendszer is, vagy akarmi...

Legyen igazad. Ideje lenne átmennünk valami szaftosabb témára trollkodni, mert ebben a hex-dec dologban nincsen elég kakaó.

:)

A D9H az label, mindenképpen decimális számjeggyel kell kezdődnie tehát. Azaz 0D9H lesz az. Van még egy szokásos formula: H'D9'.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

jogos

Lassan már lehetne a témából egy "sumák cum laude" doktori értekezést írni.

:)

"Mivel egyre többen vannak ezért nő a szakbarbárok száma is, vagyis hígul a szakma."

Ez gyönyörű volt :D

Egyébként állítólag az ilyen emberekből (is, láttam ellenpéldát!) lesznek a főnökök. Van elég bőr a képükön, hogy viseljék azt, hogy beszólnak nekik, de van elég sok bolond is, aki megoldja helyettük a feladatot.
Az ilyen gyorsan jut előre... :-(

Rövid úton kisdoktorija is lesz :-/

Szóval
1.) be kell olvasni egy 10x10-es tömb elemeit.
2.) egy másik az elemeket kiírja táblázatos formában.

Minek foglaljak dinamikus memóriát? Nem kell tárolni csak beolvasni. :)
Nem volt feltétel, hogy egész program legyen.

Ha már segítség kell, akkor adj hozzá saját dolgot és legalább olvasd el, mert ez a feladat értelmetlen.

Ahhoz, hogy ki tudd írni, tárolni kell. Ezen felül a feladat kiírásában szerepel, hogy az 'A' mátrix dinamikusan foglalt.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyészt, ez nem egyetem, hanem egy középiskolás feladat. Másrészt, én életemben nem tanultam C-t, csak próbálkoztam. Tényleg nem lett dinamikus, de az majd a következő lépcső lesz. Egyelőre úgy tűnik, hogy működik a dolog, aztán picit megörültem magamnak :) Igazából ennyi a dolog lényege.

Tudod, az a baj, hogy nem probalkoztal elegge.

Altalaban azt szoktak mondani jobb forumokon, hogy addig, amig nem tudod bemutatni a sajat kododat, es hogy mi nem megy, addig ne tedd fel a hazi feladataidat. Igenyesebb forumokon pedig tenyleg automatikusan lezarjak az ilyen kerdeseket, mert ebbol, hogy masok oldjak meg helyetted, semmit nem tanulsz, mert nincs meg az osztonzes, hogy utanaolvass, es megertsd, mi hogyan mukodik.

Csunya es durva dolog, de en is egyetertek ezzel. Ha mar bemutattad, hogy legalabb felfogtad a feladatot, es kepes vagy egy rosszul mukodo implementaciot prezentalni, az azt jelenti, hogy fektettel energiat a problema megoldasaba. Amig ez nincsen meg, addig egy vagy a sok hulyegyerek kozul, aki kicsapja a hazit az internetre, es varja, hogy megoldjak helyette. Meg ha te nem is tartozol ezek koze, ez igy ebben a formaban nem latszik rajtad.

Egyebkent en pl. eletemben nem tanultam LUA-t, megis viszonylag hamar (kb. 2 ora alatt) megertettem, hogy az imapfilter LUA alapu szuroi hogyan mukodnek, es mit kell odairnom, hogy jo eredmenyeket kapjak. Tehat nem az szamit, hogy mit tudsz, hanem hogy akarsz-e tanulni, vagy nem akarsz. Ennyi. Probalkozni kell, keresot hasznalni, ha nem megy, akkor pedig konkret kerdeseket feltenni (erre a kodra ezt a hibat kaptam, de szerintem ez igy jo, mit rontok el?), es akkor nincs gond.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

+1

A valós számok szövegként vagy bináris formában vannak?

Az a baj, hogy nincs specifikálva, mit ért a kitűző az alatt, hogy "A dinamikusan foglalt."

Fentebb többféle megoldás van erre, egybe foglalni egy malloc-cal egy 10x10-es tömböt, 10 egydimenziós tömböt foglalni és azt összefogni, ... Melyikre gondolhatott a kitűző?

Nem ezen a kezdő C-tanuló szinten válik fontossá, de nem bírom megállni, hogy meg ne jegyezzem: komoly programozóktól is láttam utóbbi megoldást, tehát 2D tömböt soronkénti malloc-cal foglalni és egy mutatótömböt csinálni neki fejléccel, *és ez egy nagyon rossz megoldás!*

Logikailag rendben van a soronkénti malloc, de úgy szétfragmentálja a memóriát meg sok egyéb bajt okoz, hogy a program bizonyos tömbméretek esetén akár 2-3-szorosan is belassulhat (ha sok tömbelem olvasás/írás mellett nem túl sok a számolási művelet). Ezt gyakorlati példákban is láttam. Persze, a kérdésben szereplő 10x10-es egyszerű feladatban ez nem számít, de jó, ha a tanulás elején már jó reflexek rögzülnek.

Alig bonyolultabb ennél az, amikor az ember a 10x10=100 float-nak egyetlen malloc-cal foglal helyet és e terület megfelelő helyeire irányítja a fejléc pontereket. (No persze, ha fordítási időben tudjuk a méretet, akkor akár eleve 10x10-es tömböt is foglalhatunk egy malloc-cal.)

Szerintem igencsak kerülendő a ciklus belsejéből hívott malloc.

+1

ez az orszag tenyleg az okostojasok orszaga csesszetek meg!

Meg a kulturálatlanoké, hogy a fene esne belé...
:-)
(troll vége, kéne valami ontopic is tőlem...)