Algoritmo per trovare denominazioni valutarie ottimali

Mark vive in un piccolo paese popolato da persone che tendono a pensare troppo alle cose. Un giorno, il re del paese decide di ridisegnare la valuta del paese per rendere il cambiamento più efficiente. Il re vuole ridurre al minimo il numero previsto di monete necessarie per pagare esattamente qualsiasi importo fino a (ma non incluso) l'importo della fattura cartacea più piccola.

Supponiamo che la più piccola unità di valuta sia la moneta. La banconota di carta più piccola del regno vale monete. Il re decide che non dovrebbero esserci più di monete diverse in circolazione. Il problema, quindi, è trovare un -set di numeri interi da che minimizza soggetto a .$n$$m$$m$$\{d_1, d_2, ..., d_m\}$$\{1, 2, ..., n - 1\}$$\frac{1}{n-1}\sum_{i = 1}^{n-1}{c_1(i) + c_2(i) + ... + c_m(i)}$$c_1(i)d_1 + c_2(i)d_2 + ... c_m(i)d_m = i$

Ad esempio, prendi l'USD standard e le sue denominazioni in monete di . Qui, la banconota di carta più piccola vale 100 della moneta più piccola. Ci vogliono 4 monete per fare 46 cent usando questa valuta; abbiamo . Tuttavia, se avessimo un taglio in monete di , ci vorrebbero solo 3 monete: c_1 (46) = 1, c_2 (46) = 1, c_3 (46) = 1 . Quale di questi set di denominazioni minimizza il numero medio di monete per fare una somma fino a 99 centesimi inclusi?$\{1, 5, 10, 25, 50\}$$c_1(46) = 1, c_2(46) = 0, c_3(46) = 2, c_4(46) = 1, c_5(46) = 0$$\{1, 15, 30\}$$c_1(46) = 1, c_2(46) = 1, c_3(46) = 1$

Più in generale, dati e , come si può determinare algoritmicamente il set ottimale? Chiaramente, si potrebbero enumerare tutti i -subset vitali e calcolare il numero medio di monete necessarie per fare somme da 1 a , tenendo traccia di quello ottimale lungo il percorso. Dato che ci sono circa -subset (non tutti fattibili, ma comunque), questo non sarebbe terribilmente efficiente. Puoi fare di meglio?$n$$m$$m$$n - 1$$C(n - 1, m)$ $m$

Ciò è legato al noto problema di modifica . Così ben studiato, infatti, che questa domanda è stata indagata$m \leq 7$[1] usando la forza bruta. A partire dal 2003, la durezza di trovare denominazioni ottimali sembra essere un problema aperto.

Se controlli gli articoli che citano Shallit, sembra che le denominazioni che consentono avide strategie di cambiamento siano di particolare interesse. È chiaro che tali denominazioni presentano in pratica vantaggi.

1. What This Country Needs is a 18c Piece di Jeffrey Shallit (2003)

Ho indovinato (a torto, ma abbi pazienza con me) che la serie $\{b^i |\ b = \lceil n^{1/m} \rceil, 0 \leq i < m\}$di monete sarebbe l'ottimale, poiché le monete sarebbero spaziate esponenzialmente, riducendo così il valore rimanente il più possibile per ogni moneta aggiunta. Per il tuo esempio, questo sarebbe$\{1,3,9,27,81\}$.

Questa è una tacca migliore ($390/99$) rispetto alle denominazioni in USD ($420/99$), ma ciò non deve significare nulla.

Ho scritto una sceneggiatura Haskell per ottenere alcuni numeri con la forza bruta, dato che non sono sicuro in questo momento come affrontarlo analiticamente.
Si scopre che la distribuzione esponenziale non è sempre la migliore: ce ne sono a volte leggermente migliori, ad esempio, per$(m,n) = (4,30)$ noi abbiamo $75/29$ per $\{20,8,3,1\}$ ma $87/29$ per $\{27,9,3,1\}$. La mia macchina lenta non ci riesce$(5,100)$, quindi dobbiamo usare numeri più piccoli, qui.

Tuttavia, ho notato che l'errore sembra essere piuttosto piccolo. La maggior parte delle volte, la divisione delle somme produce qualcosa che inizia con un 1.0 ..., quindi ho eseguito altri test.

Da un set di test con $3 \leq m \leq 5$ e $6 \leq n \leq 40$, otteniamo un errore medio della nostra crescita esponenziale rispetto alla migliore soluzione di $1.12$ con una deviazione standard di $0.085$.

Potresti sostenere che i parametri del test sono piuttosto piccoli, ma come fai notare, è solo una forza bruta se imposti $n = 100$ (Probabilmente c'è una soluzione migliore, ma questa è stata un'ottima scusa per rilassarmi e fare un po 'di Haskell).

Ecco la mia suite di test, se vuoi provarlo:

getopt :: [Integer] -> Integer -> [Integer]
getopt _ 0 = []
getopt coins target = choice:(getopt viable $ target - choice)
                          where
                            viable = filter ((>=) target) coins
                            choice = maximum $ viable

getsum :: [Integer] -> Integer -> Int
getsum coins n = sum $ map length $ map (getopt coins) [1..(n-1)]

buildall :: Integer -> Integer -> [[Integer]]
buildall 1 _ = [[1]]
buildall m n = foldl1 (++) $ map (\am -> map (\x -> x:am) [((head am)+1) .. (n-1)]) $ buildall (m-1) n

buildguess :: Integer -> Integer -> [Integer]
buildguess m n = reverse $ map ((^) $ ceiling $ (fromInteger n)**(1.0/(fromInteger m))) [0..(m-1)]

findopt :: Integer -> Integer -> ([Integer],Int)
findopt m n = foldl1 (\(l@(_,lhs)) -> (\(r@(_,rhs)) -> (if (lhs < rhs) then l else r)))
            $ map (\arr -> (arr,getsum arr n)) $ buildall m n

intcast :: (Integral a,Num b) => a -> b
intcast = fromInteger.toInteger

esterror :: Integer -> Integer -> Double
esterror m n = (intcast $ getsum (buildguess m n) n) / (intcast best)
                 where (_,best) = findopt m n

Ho eseguito il test con

map (uncurry esterror) [(m,n) | m <- [3..5], n <- [6..40] ]