Created by Matteo on Feb 17th.
Notes from meeting Feb 17th. Matteo, Irene, Luca
On Step 1
storingPerTime : \naturals \tiems \naturals → Dollars (CostDomain)
storingPerTime is heavily space-based (e.g. if you half the time you are storing, you roughly save 50%)
NB: S is linear-ish in d
Eqn1 // sec tradeoffs
for all N’
storingPerTime(d, N) < Regeneration cost(d,N’)
S(d,N) < R(d,N’) for all N’
Eqn2 (The “trivial” tradeoff)
for any d, for any space N’ ≤ N,
Regeneration(d, N’) ≤ Initialization(N, …) //d not a parameter
Put them together
storageperTime(d, N) ≤ Init
Claim: if I reduce d to its half then Init is being reduced by …?
Obs: seems like Initialization has another parameter that can adjust the cost (e.g. the degree of the graph)
Direction 2: What we seem to want is a family of PoS s.t. for (roughly) all parameters rho, N
TInit(rho, N) \approx R(rho)
(Possible problem: this ratio may depend on rho. Also, maybe there is an additional constraint, e.g. we don’t want T_init (in a new PoS) to cost more than the current T_init)
Possible direction 2bis: fix rho and find better R for that rho mathematically (i.e. a better bound)
- other possible assumption T_init is roughly linear in N
- this is to simplify and seems true in the intuitive constructions of PoS
On Step 3:
it may be more of an add on on top of the other directions. While the other two directions are more of a new PoS (with the exception of 2bis), the third is valid on any given PoS as a compiler.
We can see PoS as an optimization with constraints on parameters rho, etc. where some are fixed.