Ci sono problemi che diventano più facili con l'aumentare delle dimensioni?

62

Questa potrebbe essere una domanda ridicola, ma è possibile avere un problema che in realtà diventa più facile con l'aumentare delle dimensioni degli input? Dubito che eventuali problemi pratici siano così, ma forse possiamo inventare un problema degenerato che ha questa proprietà. Ad esempio, forse inizia a "risolversi" man mano che si ingrandisce o si comporta in qualche altro modo bizzarro.

algorithms asymptotics

— dsaxton
fonte

7

Un vero problema con questa proprietà che viene in mente è il cracking hash della password non salato quando è formulato come "dato n hash, crack almeno un hash". Poiché la velocità di cracking si ridimensionerebbe linearmente con n, il tempo di esecuzione sarebbe proporzionale a 1 / n - tranne per il fatto che non possiamo effettivamente assegnare un tempo definitivo poiché il cracking è stocastico e non ha un limite superiore costante nel tempo.

— amon

1

@amon Il tempo di esecuzione non scala come . Ci vuole tempo solo per leggere il hash che hai dato come input!

1 / n

$1/n$

n

$n$

n

$n$

— David Richerby,

3

Vuoi dire più facile in termini assoluti o relativi? Quali misure di costo autorizzi? Avete bisogno di un costo strettamente decrescente o non è sufficiente (da qualche punto in poi)?

— Raffaello

2

@DavidRicherby In questo esempio, è lecito ignorare il costo di lettura dell'input purché non si faccia alcuna dichiarazione sul costo assoluto. Invece, la velocità aumenta linearmente con l'ingresso. Pertanto, n • T (1)> T (n) anche se si considera il costo di lettura dell'input. Vale a dire per questo problema è più semplice risolvere un input di grandi dimensioni in una volta piuttosto che suddividere l'input, anche se il problema è divisibile. Non sto dicendo che T (n)> T (n + 1) per tutto n.

— amon

4

A tutti coloro che vogliono pubblicare l'ennesima risposta del modulo, "Qualche problema in cui l'input è una domanda più un mucchio di suggerimenti sulla risposta": Questo non funziona. Gli input più difficili di lunghezza sono quelli in cui usi tutti gli bit per porre la domanda e non dare suggerimenti. Il fatto che sia facile affrontare brevi domande con molti suggerimenti non significa che il tempo di esecuzione nel caso peggiore sia buono.

n

$n$

n

$n$

— David Richerby,

39

No, non è possibile: almeno, non in senso asintotico, dove è necessario che il problema continui a diventare strettamente più semplice, per sempre, come . $n \to \infty$

Sia il miglior tempo di esecuzione possibile per risolvere un simile problema, dove è la dimensione dell'input. Si noti che il tempo di esecuzione è un conteggio del numero di istruzioni eseguite dall'algoritmo, quindi deve essere un numero intero non negativo. In altre parole, per tutto . Ora se consideriamo una funzione , vediamo che non esiste una funzione del genere che sta diminuendo rigorosamente monotonicamente. (Qualunque sia , deve essere finito, diciamo ; ma poi poiché sta diminuendo rigorosamente monotonicamente, e $T(n)$ $n$ $T(n) \in \mathbb{N}$ $n$ $T: \mathbb{N} \to \mathbb{N}$ $T(0)$ $T(0)=c$ $T$ $T(c) \le 0$ $T(c+1) \le -1$ , il che è impossibile.) Per ragioni simili, non esiste una funzione che sia asintoticamente strettamente decrescente: possiamo allo stesso modo dimostrare che non esiste una funzione di tempo di esecuzione dove esiste tale che per tutti , sta diminuendo monotonicamente rigorosamente (tale funzione dovrebbe diventare eventualmente negativa). $T(n)$ $n_0$ $n \ge n_0$ $T(n)$

Quindi, un tale problema non può esistere, per la semplice ragione che i tempi di esecuzione devono essere numeri interi non negativi.

Si noti che questa risposta copre solo algoritmi deterministici (ovvero, il tempo di esecuzione nel caso peggiore). Non esclude la possibilità di algoritmi randomizzati il cui tempo di esecuzione previsto è in costante riduzione monotona, per sempre. Non so se sia possibile che esista un tale algoritmo. Ringrazio Beni Cherniavsky-Paskin per questa osservazione .

— DW
fonte

9

Questa è una bella prova, ma non sono d'accordo con la premessa. Invece di chiedere un tempo di esecuzione strettamente monotonico, la domanda potrebbe più ragionevolmente richiedere una funzione in cui esiste una a, b con a <b in modo che T (a)> T (b), ovvero la sua riduzione non strettamente monotona. Quindi, è ovviamente possibile trovare funzioni integer adatte. Ma perché numeri interi? Avevo l'impressione che il tempo di esecuzione indicasse un tempo, non un conteggio delle istruzioni (tranne ovviamente per le macchine di Turing) e che l'espressione T potesse usare operazioni non intere come log () o esponenti non interi.

— Amon,

2

@amon "il tempo di esecuzione indicava un tempo, non un conteggio delle istruzioni" Assolutamente no. Il tempo di esecuzione è sempre un conteggio delle istruzioni. Qualsiasi altra cosa sarebbe impossibile da ragionare in quanto dipenderebbe da un'infinità di dettagli di implementazione.

— David Richerby,

3

Per quanto vaga sia la domanda, non vedo come escluda una funzione di costo di, diciamo, . Ora, ma per "piccolo" , quindi il problema "diventa più facile", relativamente parlando. (I costi assoluti crescono asintoticamente, ovviamente).

T (n) = n^{2} \cdot (1 + ϵ)^{- n} + n

$T(n) = n^2 \cdot (1+\epsilon)^{-n} + n$

T (n) \sim n

$T(n) \sim n$

T (n) \approx n^{2}

$T(n) \approx n^2$

n

$n$

— Raffaello

2

@Raphael, non è un problema che diventa più facile: diventa più grande quando diventa più grande, quindi il problema diventa più difficile quando diventa più grande, una volta che è abbastanza grande. Ho affermato nella prima frase della mia risposta che nessun problema può essere reso più facile per sempre. Certo, un problema può diventare più facile per un po '( può diminuire per , diciamo), ma non può continuare a diventare più facile per sempre.

T (n) \sim n

$T(n) \sim n$

T (n)

$T(n)$

n

$n$

n

$n$

n

$n$

T (n)

$T(n)$

n \leq c

$n \le c$

— DW

1

Anche con tempi interi, per un algoritmo randomizzato il tempo previsto (o qualsiasi altra misura della distribuzione) può essere frazionario e potrebbe avvicinarsi gradualmente ad una costante dall'alto. [Questo non significa che tali problemi esistano realmente, solo che l' argomento "nessuna funzione esiste" è insufficiente.]

T

$T$

— Beni Cherniavsky-Paskin,

25

Sebbene non sia proprio una risposta alla tua domanda, l' algoritmo di ricerca di stringhe Boyer-Moore si avvicina. Come dice Robert Moore sulla sua pagina web sull'algoritmo,

Il nostro algoritmo ha la proprietà peculiare che, in termini approssimativi, più lungo è il modello, più veloce è l'algoritmo.

In altre parole, in generale l'algoritmo cerca un'istanza di una stringa di destinazione in una stringa di origine e una stringa di origine fissa, più lunga è la stringa di destinazione, più veloce è l'esecuzione dell'algoritmo.

— Rick Decker
fonte

10

Probabilmente, il modello non è la dimensione del problema, ma la lunghezza della stringa da cercare è. Come nel commento di David Richerby sopra , direi che la lunghezza del modello è più un suggerimento su come risolvere il problema (ho cercato di cercare la stringa) che il problema stesso (vedere se un modello corrisponde a una stringa di una lunghezza particolare .)

— Kevin - Ripristina Monica

4

@Kevin L'affermazione suggerisce che la ricerca di un modello di lunghezza in una lunghezza testo è più veloce della ricerca di un modello di lunghezza . Osservando tali input a relazione fissa (cioè coppie di stringhe), penso che Rick abbia dato una risposta adeguata alla domanda (se non in senso classico, asintotico).

\sqrt{n}

$\sqrt{n}$

n

$n$

\log n

$\log n$

— Raffaello

10

Chiaramente, da un punto di vista matematico e puramente algoritmo CS questo è impossibile. Ma in realtà ci sono molti esempi reali di come ridimensionare il tuo progetto sia più semplice, molti dei quali non sono intuitivi per gli utenti finali.

Indicazioni : più lunghe sono le indicazioni, a volte possono diventare più facili. Ad esempio, se desidero che Google Maps mi dia indicazioni per andare a ovest 3000 miglia, potrei guidare verso la costa occidentale e ottenere istruzioni di guida attraverso il paese. Ma se volessi andare 6000 miglia a ovest, finirei con istruzioni significativamente più semplici: salire su un aereo da New York a Hokkaido. Fornirmi una pista da fondo che incorpora traffico, strade, condizioni meteorologiche, ecc. È piuttosto difficile da un punto di vista algoritmico, ma dirmi di salire su un aereo e cercare voli in un database è relativamente più semplice. Grafico ASCII di difficoltà vs distanza:

           |     /
           |    /
Difficulty |   /                  ____-------
           |  /           ____----
           | /    ____----
            ---------------------------------
                       Distance

Rendering : dire che voglio un rendering di una faccia e un rendering di 1000 facce; questo è per un annuncio cartellone, quindi entrambe le immagini finali devono essere 10000 x 5000 pixel. Renderizzare realisticamente una faccia sarebbe difficile - alla risoluzione di diverse migliaia di pixel devi usare macchine davvero potenti - ma per la folla di 1000 facce ogni faccia deve essere larga solo dieci pixel e può essere facilmente clonata! Probabilmente potrei eseguire il rendering di 1000 volti sul mio laptop, ma il rendering di un volto realistico di 10000 px richiederebbe molto tempo e macchine potenti. Grafico ASCII di difficoltà rispetto agli oggetti renderizzati, che mostra come la difficoltà di rendering di n oggetti su un'immagine di una dimensione impostata diminuisce rapidamente ma poi ritorna lentamente:

           | -    
           |- -                     _________
Difficulty |   --      ______-------            
           |     ------      
           |       
            ---------------------------------
                        Objects

Controllo dell'hardware : molte cose con l'hardware diventano molto più facili. "Sposta il motore X 1 grado" è difficile e / o impossibile e devi affrontare tutti i tipi di cose che non dovresti affrontare per "spostare il motore X 322 gradi".

Attività di breve durata: supponiamo che si desideri che l'elemento X sia acceso per (molto poco tempo) ogni secondo. Aumentando il tempo di esecuzione di X, avrai bisogno di software e hardware meno complessi.

— Owen Versteeg
fonte

Nel tuo esempio "indicazioni stradali", indica esattamente qual è il problema computazionale e qual è l'istanza. Non è affatto chiaro per me che il tuo esempio di 6k miglia sia un'istanza più grande o solo un esempio di una parte facile di qualcosa (ad esempio, se ti do un grande grafico collegato grafico più un vertice isolato, chiedendo percorsi più brevi in generale è "difficile", ma chiedere un percorso più breve dal vertice isolato verso qualsiasi luogo è banale). Ancora una volta, per il tuo esempio di rendering, qual è l'effettivo problema computazionale? Qual è l'istanza rispetto alla quale stai misurando la complessità?

— David Richerby,

L'esempio di rendering non sembra essere istanze dello stesso problema: il primo è il rendering di una singola immagine; la seconda sta eseguendo il rendering di molte piccole immagini e quindi incollando più copie di quelle immagini in alcune aree.

— David Richerby,

Penso che per viaggiare i parametri sarebbe il nome delle 2 città e n sarebbe il numero di caratteri per codificarli.

— emory

3

Ci sono casi Sono i casi in cui i criteri di successo sono una funzione dei dati, piuttosto che cercare di trovare un'unica risposta. Ad esempio, i processi statistici i cui risultati sono formulati con intervalli di confidenza possono diventare più facili.

Un caso particolare a cui sto pensando sono problemi che hanno una transizione da comportamenti discreti a comportamenti continui, come i flussi fluidi. Risolvere il piccolo problema entro un certo grado di errore può comportare la modellazione di tutte le interazioni discrete, che possono richiedere un supercomputer. I comportamenti continui spesso consentono semplificazioni senza produrre risultati al di fuori di un limite di errore correlato.

— Cort Ammon
fonte

2

La domanda è interessante e UTILE, perché la nostra filosofia in informatica è quella di risolvere i problemi più leggiamo e più è difficile. Ma, in effetti, la maggior parte dei problemi che si presentano nel modo tipico (difficile) può essere facilmente rappresentata nel modo "facile"; anche conoscendo la risposta di DW (che è sbagliato considerando che facile non significa più veloce, significa "meno lento", quindi non devi trovare tempi negativi, devi trovare il tempo asintotico).

Il trucco per trovarne uno è mettere la parte della soluzione come suggerimenti come una voce e considerare l'entrata del problema come un parametro costante.

Esempio: qual è il modo più lungo in auto tra Londra e Parigi evitando di visitare due volte una città francese e una britannica e non visitare un altro paese? considerando che devi andare a Birmingham prima di Ashford, Orleans prima di Versailles, La Rochelle prima di Limoge, ecc ...

È chiaro che questo problema con voci lunghe sarà più facile che con voci brevi.

Esempio di utilizzo: immagina un gioco gestito dalla macchina e l'IA del computer deve determinare se deve esplorare di più nel gioco per trovare altri suggerimenti, oppure se ora è il momento di dedurre qual è la decisione migliore da assumere .

— Juan Manuel Dato
fonte

2

Il tuo esempio non funziona. Le istanze che sono grandi perché hanno così tanti suggerimenti che determinano un ordine lineare dei vertici del grafico sono davvero facili. Tuttavia, le istanze che sono grandi perché forniscono un grafico di grandi dimensioni con quasi nessun suggerimento sono altrettanto difficili del normale problema del percorso hamiltoniano. Pertanto, il tempo di esecuzione nel caso peggiore di qualsiasi algoritmo che risolva questo problema sarà almeno altrettanto negativo del tempo di esecuzione nel caso peggiore dell'algoritmo migliore per il percorso hamiltoniano, che non sembra essere "super facile".

— David Richerby,

@David, la tua risposta è completamente errata: 1. La voce non è un grafico: il grafico grande è un PARAMETRO. Quindi il problema hamiltoniano viene convertito in una costante (molto grande, ma costante). 2. La voce è la soluzione del problema, quindi: se maggiore, stai offrendo un'esplosione combinatoria di suggerimenti. Una voce di un suggerimento dà un aiuto, due suggerimenti il doppio, tre suggerimenti saranno vicini a 4 volte ..., perché stai eliminando possibili soluzioni. Quindi, questo non era un hamiltoniano, questa è una soluzione da un grafico specifico e il problema è COSA avere a che fare con parti delle soluzioni.

— Juan Manuel Dato,

Penso che la tua argomentazione sia interessante in quanto le istanze più grandi sono "più facili" in un certo senso, ma penso che la risposta alla domanda originale sia in definitiva "no". Poiché il grafico è finito, ci sono quindi solo finitamente molti possibili suggerimenti. Pertanto, ogni istanza può essere risolta in tempo costante (ad esempio, utilizzando una tabella di ricerca). Anche se le istanze più grandi sono (intuitivamente) più semplici nella visione (asintotica) dell'informatica, tutte le istanze sono ugualmente difficili (risolvibili a tempo costante).

— Tom van der Zanden,

@Tom, sono d'accordo che la tua considerazione sulla complessità sarà costante, ma il problema è come stiamo accettando i nuovi suggerimenti: se con la nostra filosofia di calcolo della voce lunga non è meglio di una voce breve, allora dobbiamo cambiare la nostra filosofia - perché questo è un dato di fatto: voci lunghe implicano problemi più facili. Quindi non possiamo lavorare in quel modo ... Consiglierei il mio libro, ma non ho alcuna reputazione ...

— Juan Manuel Dato

@TomvanderZanden In realtà, non può essere risolto in tempo costante perché l'elenco di "suggerimenti" potrebbe contenere duplicati. Richiede qualcosa come time per la deduplicazione prima di poter eseguire la ricerca della tabella. Così indovinate un po? Risolvere casi più grandi è ancora più difficile.

n \log n

$n\log n$

— David Richerby,

1

Considera un programma che prende come input ciò che sai di una password e quindi cerca di decifrarla. Penso che questo faccia quello che vuoi. Per esempio:

Nessun input-> La forza bruta si spezza su tutti i simboli e una parola di qualsiasi lunghezza
Lunghezza della password -> Brute forza tutti i simboli in una parola di quella lunghezza
Simboli contenuti -> Riduce l'elenco di simboli da controllare
...
Simboli contenuti tra cui occorrenze multiple e lunghezza -> Calcola solo permutazioni
Tutti i simboli nell'ordine corretto -> sostanzialmente risolto se stesso

Dovrei aggiungere che questo è un trucco, poiché il problema dichiarato in questo modo è inverso alla dimensione dell'input. Potresti tralasciare uno strato di astrazione e dire che la dimensione dell'input è grande per nessun input (controlla tutti i simboli e le lunghezze delle parole) e piccola se inserisci la password corretta all'inizio.

Quindi tutto dipende da quanta astrazione permetti.

— RunOrVeith
fonte

2

Questo non funziona Innanzitutto, non è un problema computazionale ben definito: supponiamo che il tuo input sia solo "La password ha 8 caratteri" - che non determina in modo univoco alcuna password. In secondo luogo, supponiamo di renderlo ben definito includendo un hash e chiedendo qualsiasi password che corrisponda all'hash. In questo caso, le istanze più difficili sono quelle del modulo "L'hash è: [ -bit hash]" senza ulteriori informazioni. Queste istanze non diventano più facili da risolvere all'aumentare della lunghezza dell'input: diventano esponenzialmente più difficili.

b

$b$

— David Richerby,

0

È un dato di fatto, ho un problema che si riduce con l'aumentare dei dati. Una delle mie applicazioni registra gli attributi di un particolare prodotto, ad esempio il formaggio. Gli attributi sono ad esempio CheeseType, Brand, Country, Area, MilkType, ecc. Ogni mese o giù di lì, ottengo un elenco di nuovi formaggi che sono entrati sul mercato in quel periodo, insieme ai loro attributi. Ora, questi attributi sono digitati a mano da un gruppo di umani. Alcuni fanno errori di battitura, o semplicemente non conoscono il valore di tutti gli attributi.

Quando eseguo una ricerca nel mio database, provo a prevedere dalle statistiche che sapore ha il formaggio, sulla base di questi attributi. Quello che succede è che per ogni attributo, finisco con un intervallo di valori; alcuni sono validi alcuni non sono validi. Eliminare o correggere questi non validi è possibile solo se ho abbastanza dati. Si tratta di fare la differenza tra valori reali e rumore, senza eliminare valori rari ma validi.

Come puoi immaginare, a basso volume, il rumore è troppo importante per sistemare le cose correttamente. Se hai 5 istanze di Cheddar, 1 di Brie, 1 di Bri e 1 di Chedar, come faccio a sapere quale è corretta e quale è un errore di battitura? Con più volume, i refusi tendono a rimanere molto bassi, ma i valori rari ottengono alcuni incrementi cruciali, facendoli sfuggire al rumore (supportato dall'esperienza). In questo caso, potrei immaginare 50000 Cheddar, 3000 Brie, 5 Bri, 15 Chedar, per esempio.

Quindi sì, alcuni problemi si risolvono alla fine, quando si dispone di dati sufficienti.

— Chris
fonte

1

Questo non riesce per il solito motivo. Un grande input potrebbe essere quello in cui le persone ti parlano di molti diversi tipi di formaggio, piuttosto che quello in cui ti parlano di alcuni tipi di formaggio, ma alcuni di loro lo scrivono male. Inoltre, non è chiaro che "più facile" dovrebbe essere interpretato come "consentire una maggiore fiducia nel risultato".

— David Richerby,

Questo è un problema di vita reale (l'ho già avuto due volte), che non può essere risolto con una bassa quantità di dati. Può, e diventa ancora più facile distinguere, buoni valori da quelli sbagliati, poiché il volume aumenta. Ha il merito di rispondere alla domanda "Ci sono problemi che diventano più facili con l'aumentare delle dimensioni?" Non importa quanti tipi di formaggi escono, alla fine, con un volume sufficiente, avranno più "successi" dei refusi. Questo è cs .stackexchange, non matematica, quindi i problemi sono diversi e risolverli a volte significa semplicemente avere una maggiore fiducia nei risultati.

— chris,

Non è forse anche questa la premessa dello show televisivo Numbers ? O almeno alcuni episodi - So di ricordare specificamente una scena in cui il ragazzo di matematica osserva che l'algoritmo che sta usando per risolvere il problema attuale diventa più efficace con un set di dati più ampio.

— Dan Henderson,

2

"Diventa più efficace"! = "Diventa più facile".

— David Richerby,

-1

Considera il problema NP-completo 3-SAT. Se continui ad aumentare il problema fornendo input nella forma x_i = true / false, o finisci per convertire le singole disgiunzioni in clausole a due variabili, creando così un problema 2-SAT che è decisamente P, o semplicemente finisci per ottenere una risposta vera / falsa.

Nel caso in cui vi sia ridondanza negli ingressi x_i = true / false (stesso input fornito molte volte o input contraddittori), è possibile ordinare facilmente gli input e ignorare i valori ridondanti o segnalare un errore se i valori sono in contraddizione.

In ogni caso, penso che ciò rappresenti un problema "realistico" che diventa più facile da risolvere con l'aumentare del numero di input. L'aspetto "più semplice" è la conversione di un problema NP completo in un problema P. Puoi ancora giocare al sistema fornendo input ridicoli in modo tale che solo l'ordinamento richiederebbe più tempo della forzatura bruta del problema.

Ora, uno scenario davvero interessante sarebbe se siamo disposti ad accettare T (0) (utilizzando la notazione di DW nella risposta sopra) può essere infinito. Ad esempio, T (0) potrebbe equivalere a risolvere il problema di arresto di Turing. Se potessimo escogitare un problema in modo tale che l'aggiunta di più input lo trasformasse in un problema risolvibile, avremmo ottenuto l'oro. Si noti che non è sufficiente convertirlo in un problema risolvibile in modo asintotico, perché è altrettanto grave della brutale forzatura del problema.

— v vv cvvcv
fonte

1

Questi input particolari diventano più facili. Tuttavia, se si considerano tutti i possibili input, 3SAT in generale diventa notevolmente più difficile quando si aggiungono più clausole: gli input effettivi sono quelli senza queste clausole di "suggerimento". Se non autorizzi input generali, devi indicare esattamente quali input stai autorizzando.

— David Richerby,

Prima di tutto: siamo d'accordo sul fatto che l'aggiunta di più input può aumentare il tempo di esecuzione. Dico essenzialmente la stessa cosa sopra. In secondo luogo, dico chiaramente che stiamo prendendo un 3-SAT esistente e aggiungendo solo input del modulo x_i = true / false. Penso che sia abbastanza chiaro e non ho bisogno di fare ulteriori chiarimenti. Penso che stai prendendo la briga di formare l'interpretazione più fraintesa di ciò che ho scritto. Per favore, non preoccuparti.

— v vv cvvcv,

1

No sul serio. Quale problema computazionale stai risolvendo? Un problema computazionale è decidere l'appartenenza di una serie di stringhe (diciamo una serie di formule per evitare fastidi sulla codifica). Qual è l'insieme di formule per le quali stai affermando che decidere se una formula lunga è nell'insieme è più facile che decidere che una formula corta è nell'insieme? Non appena provi a renderlo preciso, sono abbastanza sicuro che il tuo reclamo andrà in pezzi.

— David Richerby,

Potete per favore chiarire la vostra comprensione della "mia richiesta"? Non appena provi a renderlo preciso, sono abbastanza sicuro che smetterai di sprecare la larghezza di banda di Internet.

— v vv cvvcv,

Sono un informatico, non un lettore di mente. Rendere preciso il tuo reclamo è il tuo lavoro, non il mio.

— David Richerby,

-1

La domanda si pone: "è possibile avere un problema che in realtà diventa più semplice con l'aumentare delle dimensioni degli input?" Cosa succede se gli input sono risorse che devono essere utilizzate dall'algoritmo per lavorare su un lavoro. È risaputo che più risorse sono, meglio è. Di seguito è riportato un esempio in cui più dipendenti ci sono, meglio è.

1) Vengono forniti due input:
i) Il numero di dipendenti in un settore. Questo è un numero naturale ed è l'ingresso principale . ii) Informazioni sul settore. Ci sono compiti che i lavoratori devono svolgere, etichettati A, B, C, D ... Ci sono posti che collegano i compiti che consentono ai dipendenti di passare da un compito all'altro. Sono etichettati 0, 1, 2, 3 ... Le informazioni fornite sono un semplice grafico diretto costituito da percorsi, ad esempio: A-1, 1-2, 2-B, C-3 ... Per semplicità ogni il percorso ha un costo di 1. $n$
$t$ $p$

2) Problema: a
partire dalle prime attività A e con dipendenti, è necessario trovare una strategia ottimale che i dipendenti possano utilizzare per visitare tutte le attività. Le attività possono essere visitate più di una volta. Ricordiamo che non è possibile passare da un'attività all'altra se non si trova un percorso tra di esse. Il percorso dall'attività A alla B è indipendente da quello da B ad A. $n$

3) Output:
l'output è il percorso tra le attività che i dipendenti devono intraprendere. Ogni percorso è associato al numero di dipendenti che lo assumono. Per esempio:

Da A a B con dipendenti (un percorso in avanti) Da A a C con dipendenti (un percorso in avanti) Da B a D con dipendenti (un percorso in avanti) Da D a B con dipendenti (un percorso invertito) Da B a E con dipendenti (un percorso in avanti) $n1$
$n2$
$n3$
$n4$
$n5$

4) Possibile soluzione:
una possibile soluzione è innanzitutto calcolare il percorso più breve verso i nodi più vicini da A. Questo sarà un percorso diretto. Quindi calcola ricorsivamente il percorso di andata per ciascuna attività visitata. Il risultato è un albero. Per esempio:

          UN
      AVANTI CRISTO
    DE

Ora è il momento di determinare in che modo i dipendenti attraverseranno l'albero per visitare i compiti. A partire dall'attività A con dipendenti, vengono inviati alla sottostruttura sinistra e vengono inviati alla sottostruttura destra. Se nessuno della sottostruttura sinistra dovrà mai passare alla sottostruttura destra. $n$ $n1$ $n2$ $n2 \neq 0$

Per i dipendenti andranno semplicemente avanti. Per il dipendente dovrà utilizzare percorsi inversi per visitare altre attività. Ad esempio, da D a B l'algoritmo calcolerà il percorso più breve. Questo è un calcolo extra. Perché non calcolare direttamente un percorso più breve da D a E ?! Bene, si spera che sia ancora un calcolo extra. $n=\infty$ $n = 1$

Ma ovviamente il tempo di calcolo non diminuirà all'infinito (tra l'altro per troppo grande porterà a una cattiva gestione delle risorse e cose). $n$

— yemelitc
fonte

6

Grazie per aver condiviso i tuoi pensieri. Normalmente nell'informatica si intende un algoritmo che accetta una sequenza di bit come input e genera un'altra sequenza di bit. Con quella comprensione standard, non vedo come questa risposta possa avere senso. Se hai in mente una nozione diversa di algoritmo, penso che sarebbe utile se modifichi la domanda per descrivere cosa intendi con algoritmo (dal momento che sembra che tu non stia usando il termine in un modo che corrisponde all'uso standard del termine, come ho capito).

— DW

L'input può essere semplicemente un numero (il numero di risorse). Ciò influirà sul numero di calcoli aggiuntivi che l'algoritmo dovrà superare. Modificherò la risposta per fornire un esempio più concreto.

— yemelitc,

Grazie per la modifica, questo lo rende molto più chiaro. Ora vedo che non stai confondendo il costo del calcolo della soluzione con il costo dell'esecuzione come pensavo inizialmente. Ma ora siamo nella solita situazione. Innanzitutto, è necessario almeno un tempo lineare per leggere l'input. In secondo luogo, i casi difficili non sono quelli in cui dai un piccolo albero e un gazillion di persone, ma dove dai un grande albero e relativamente poche persone. (Ad esempio, se mi permetti un milione di bit, sceglierò un albero con circa un migliaio di vertici e ti darò cinque persone, non un albero con cinque vertici e un migliaio di persone.)

— David Richerby

Sono d'accordo. Sembra che siamo finiti tutti abbastanza critici al riguardo, diversamente da ciò che la domanda originale ci ha tentato! Ma spero che tu abbia la mia idea di "input come risorsa": non importa quanto sia grande il lavoro, più persone meglio è. Ancora in senso asintotico hai decisamente ragione, dovrei solo dare la colpa a numeri interi non negativi.

— yemelitc