La cumpărături

• Data publicării: 09.03.2026
• Data ultimei modificări: 09.03.2026 (changelog)
• Tema (o arhivă .zip cu toate fișierele .rkt folosite în etapa curentă) se va încărca pe vmchecker

Tema constă într-o aplicație care simulează fluxul clienților pe la casele unui magazin, și constă în 4 etape:

• una pe care o veți rezolva după laboratorul 3 (cu deadline în ziua laboratorului 4, la ora 08:00)
• una pe care o veți rezolva după laboratorul 4 (cu deadline în ziua laboratorului 5, la ora 08:00)
• una pe care o veți rezolva după laboratorul 5 (cu deadline în ziua laboratorului 6, la ora 08:00)
• una pe care o veți rezolva după laboratorul 6 (cu deadline în ziua laboratorului 7, la ora 08:00)

Așa cum se poate observa, ziua deadline-ului variază în funcție de semigrupa în care sunteți repartizați. Restanțierii care refac tema și nu refac laboratorul beneficiază de ultimul deadline (deci vor avea deadline-uri în zilele de 20.03, 27.03, 03.04, 10.04).

Rezolvările tuturor etapelor pot fi trimise până la ora 08:00 în ziua laboratorului 7, dar orice exercițiu trimis după deadline-ul soft și înainte de deadline-ul hard (care este dimineața zilei laboratorului 7) se punctează cu jumătate din punctaj. Orice exercițiu trimis după deadline-ul hard nu se mai punctează deloc. Nota finală pe etapă se calculează conform formulei: n = (n1 + n2) / 2 (n1 = nota obținută înainte de deadline-ul soft; n2 = nota obținută între deadline-ul soft și cel hard). Când toate submisiile sunt înainte de deadline-ul soft, nota pe ultima submisie este și nota finală (întrucât n1 = n2).

În fiecare etapă, veți folosi ce ați învățat în săptămâna anterioară pentru a perfecționa aplicația.

Pentru fiecare etapă veți primi un schelet de cod (dar rezolvarea se bazează în mare măsură pe rezolvările anterioare). Enunțul din această pagină este menit să descrie pe scurt aplicația și să ofere exemple de rulare a funcțiilor mai complexe. Dacă preferați, puteți rezolva tema utilizând doar indicațiile din schelet.

În această etapă presupunem că magazinul are fix 4 case (“counters” în engleză): C1, C2, C3, C4. Fiecare casă este reprezentată ca o structură:

(define-struct counter (index tt queue))

• index
  • în cazul nostru, este un număr de la 1 la 4 (1 pentru C1, 2 pentru C2, etc.)
• tt
  • vine de la “total time”, și reprezintă timpul total de așteptare la această casă: dacă un client se așază acum la coadă, el va avea de așteptat tt unități de timp până să ajungă în față (pentru conveniență vom considera unitatea de timp ca fiind 1 minut, chiar dacă este nerealist)
  • depinde de numărul de produse cumpărate de clienții din coadă (1 produs = 1 minut) și de eventualele întârzieri suferite de casa respectivă
• queue
  • este o listă de perechi (nume . nr-produse), reprezentând persoanele așezate la coadă la această casă (fiecare persoană apare în pereche cu numărul de produse cumpărate)
  • ca orice coadă, funcționează pe principiul FIFO (primul element din listă corespunde primului client care s-a așezat la coadă)

Deși nu am studiat structuri la curs sau laborator, utilizarea lor este simplă (și ne ajută să avem un cod mai lizibil). Aveți aici un tutorial foarte scurt cu tot ce vă trebuie pe partea de structuri și pattern matching.

Statutul caselor diferă astfel:

• C2-C4 sunt deschise tuturor clienților
• C1 acceptă doar clienți care au cumpărat maxim ITEMS produse (ITEMS este o constantă definită în schelet)

În această etapă, simulatorul trebuie să modeleze două situații:

• când un client dorește să se așeze la coadă cu coșul său de cumpărături
• când activitatea unei case este întârziată (din diverse motive neprevăzute) cu un număr de minute

Funcțiile principale pe care va trebui să le implementați sunt:

(min-tt counters)

• min-tt determină casa din counters care are tt minim, și întoarce perechea dintre indexul acestei case și valoarea tt-ului ei)
• când are de ales între mai multe case, o va alege pe cea cu index minim
• ex:

  (min-tt (list (counter 1 10 '()) (counter 2 12 '((ana . 12)))))

  • tt-ul minim este 10, la casa 1
  • ⇒ '(1 . 10)

(add-to-counter C name n-items)

• add-to-counter adaugă în coada casei C persoana name cu n-items produse (ceea ce se adaugă este o pereche care conține ambele informații)
• ex:

  (add-to-counter (counter 1 10 '((dan . 10))) 'ana 12)

  • adaugă perechea '(ana . 12) la sfârșitul cozii
  • ⇒ (counter 1 22 '((dan . 10) (ana . 12)))

(serve requests C1 C2 C3 C4)

• serve primește o listă de cereri (așezări la coadă, respectiv întârzieri) și le tratează în ordine, în sensul că actualizează C1, C2, C3 și C4 pe măsură ce situația caselor evoluează

Exemplu:

(serve '((ana 12) (delay 1 5) (mia 2)) C1 C2 C3 C4)

unde presupunem că C1-C4 sunt în prezent lipsite de clienți, iar ITEMS = 5:

• ana se așază la cea mai avantajoasă casă posibilă
  • întrucât ana are 12 produse, ea se poate așeza doar la una dintre C2, C3, C4
  • toate cele 3 case sunt lipsite de clienți și niciuna nu a suferit întârzieri, deci alegem C2 pentru că are index minim
• casa 1 suferă o întârziere de 5 minute
  • o casă fără clienți poate suferi întârzieri - în sensul că un client care se așază acum la C1 trebuie să aștepte 5 minute până când cineva îl va lua în primire
• mia se așază la cea mai avantajoasă casă posibilă
  • întrucât mia are 2 produse, ea se poate așeza la orice casă
  • situația curentă a caselor este: C1 este întârziată cu 5 minute (tt = 5), la C2 stă ana (tt = 12), C3 și C4 nu au nici clienți, nici întârzieri (tt = 0)
  • alegem C3 pentru că, dintre casele cu tt minim, C3 are index minim
• ⇒

  (list
   (counter 1 5 '())
   (counter 2 12 '((ana . 12)))
   (counter 3 2 '((mia . 2)))
   (counter 4 0 '()))

• Scheletul fiecărei etape va conține unul sau mai multe fișiere .rkt în care trebuie să lucrați, plus fișierul checker.rkt pe care îl veți folosi doar pentru testare (rulând codul fără să îl modificați).
• Fiecare etapă (o arhivă .zip cu fișierele în care ați lucrat, plus eventualele fișiere care sunt solicitate de acestea cu “require”) se va încărca pe vmchecker. Testele de vmchecker sunt aceleași cu cele din checker.rkt.
• În fiecare etapă veți avea de implementat o serie de funcții, în sprijinul cărora vă puteți defini oricând funcții ajutătoare (dacă nu se interzice asta în mod explicit). Atunci când există restricții asupra implementării funcției din cerință, aceleași restricții trebuie respectate și de eventualele funcții ajutătoare definite de voi.
• Dacă doriți să rezolvați exerciții din etapa curentă care depind de exerciții din etapele anterioare pe care nu le-ați rezolvat, puteți semnala acest lucru responsabilului de temă, care vă va pune la dispoziție o rezolvare pentru acele exerciții astfel încât să puteți continua tema. Odată ce alegeți această variantă, renunțați la dreptul de a mai trimite cu întârziere etapa pentru care ați solicitat parțial sau integral rezolvarea. Puteți solicita rezolvări doar pentru exercițiile din etapele anterioare, nu și pentru cele din etapa curentă. Dacă implementați un exercițiu din etapa curentă pe baza unui alt exercițiu din etapa curentă pe care nu l-ați rezolvat, se va lua în calcul punctajul dat de checker, chiar dacă implementarea ar funcționa în caz că exercițiul nerezolvat ar funcționa.
• Tema este o temă de programare funcțională - pentru care folosim Racket. Racket este un limbaj multiparadigmă, care conține și elemente “ne-funcționale” (de exemplu proceduri cu efecte laterale), pe care nu este permis să le folosiți în rezolvare.
• Pentru fiecare etapă, checker-ul vă oferă un punctaj între 0 și 120 de puncte. Nota 100 corespunde punctajului maxim pe etapă, iar orice surplus se transformă într-un bonus proporțional.
• Veți prezenta tema asistentului, care poate modifica punctajul dat de checker dacă observă nereguli precum răspunsuri hardcodate, proceduri cu efecte laterale, implementări neconforme cu restricțiile din enunț.
• Temele implementează o politică de zero toleranță pentru copiere. Cât timp respectați politica de colaborare și utilizare a internetului descrisă în regulamentul materiei, nu aveți motive de îngrijorare. Contăm pe voi să nu recurgeți la mijloace nepermise, și vă stăm la dispoziție pentru orice neclaritate.

• etapa 1
• tutorial structuri

• 09.03 (ora 15:30) - Am publicat etapa 1.

• Simple and Efficient Purely Functional Queues and Deques