On such a problem you can get more than your fair share of scores with a simple solution approach and code.

See how many points does dynArrayTrivial.cpp collect. This code simply simulates the process mantenendo aggiornato ad ogni istante l'array A[1...n] nel modello proposto dal testo dell'esercizio.
Quindi l'aggiornamento avviene in O(1), per accesso diretto alla cella da modificare, e per rispondere ad una query si va per la ovvia solutione O(n).

Non e' impossibile fare una stima approssimativa sulle dimensioni di un'istanza risolvibile da questo approccio, e farsi delle aspettative ragionevoli sui punti gia' collezzionati da esso.
Quanti punti erano a proposito?

Basta testare: ora potete usare persino proprio le stesse istanze su cui i vostri codici sono stati valutati.
Vi consiglio di prendere dimestichezza col sistema di gara, che paga assai, ed in effetti uno degli obiettivi di questa modalita' d'esame e' proprio quella di indurvi ad un approccio sperimentale e consapevole a vari aspetti della programmazione in vivo. Non saro' quindi io ad impedirvi di cogliere i frutti generosi di un tale approccio.

In gara non avevate i seed, e non potevate procurarveli se non vi portate su un piano che non intendo promuovere.In gara non avevate il generatore di istanze randArrayInstance.cpp, ma non vi credo se mi dite che l'allestirne uno vi sarebbe costato troppa fatica per valerne la pena.
Congiunto alle informazioni sulle tipologi di istanze fornite nel testo, cio' avrebbe potuto fornirvi una stima affidabile sui punti riferibili a questa prima soluzione.
Non solo: vi avrebbe consentito di effettuare un debug un minimo serio di questa od altre soluzioni, il che e' forse ancora piu' importante poiche', piu' spesso che no, cio' fa la differenza fra il raccogliere il frutto del proprio lavoro ed il gettarlo alle ortiche.
Il mio consiglio qui e': meditate su queste cose.
Se vi brucia avere perso questi punti, meditate su queste cose.
Cio' significa pensare al futuro piuttosto che piangere sul latte versato.

Proseguiamo con queste considerazioni.
Supponiamo anche io abbia visto fin dall'inizio, o fossi a conoscenza pregressa, di una soluzione potente come quella in dynArray.cpp.
Come mi converra' procedere nella codifica? Provate a porvi questa domanda, perche' e' una domanda che dovreste porvi anche all'esame, essendo questa una situazione che potra' ben presentarvisi.

La risposta, come spesso accade, va cercata in un'altra domanda:

Open Question: quanto vi costa scrivere prima la soluzione banale?

Tale domanda e' pertinente anche se nulla di quanto nel codice della soluzione banale fosse riutilizzabile
(quando invece la parte piu' voluminosa e noiosa su gestione input/output puo' tipicamente essere riutilizzata),
e la ragione di cio' puo' essere intravista nella seguente ulteriore domanda pertinente.

Open Question: quanto affidabile (sul piano della correttezza) potrebbe risultare una codifica piatta della soluzione banale? Quanto vi costa convergere ad un codice affidabile lavorando su questa soluzione?

Queste di cui parliamo sono qualita' enormi della soluzione banale, che dovrebbero farci optare per cominciare comunque per partire dalla sua codifica.

Nel mio caso, confesso che ero gia' a conoscenza pregressa della soluzione basata sui Fenweek trees implementata nel codice dynArray.cpp. Potete pero' vedere che ho implementato anche la soluzione banale, mosso anche da intenzionalita' didattica. Ma la domanda e': secondo voi, quale delle due soluzioni ho deciso di implementare per prima, e perche'?

E lascio ora a voi l'esplorazione di ulteriori considerazioni su un versante qui solo richiamato ma di prima importanta.

Open Question:
Supponete di codificare ora una soluzione ultimativa, o magari anche solo di secondo livello.
Quanto puo' accellerare (se non banalmente consentire) il processo di convergenza ad una codifica corretta l'avere a disposizione un codice affidabile di riferimento per lo stesso problema?

A questi aspetti ci si riferisce quando si parla genericamente di cross-validation.