Partial formula execution
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- backend, performance
Direzione di ricerca
Start by reading issue #64 and its prototype, then trace the variable execution path around the proposed eligible and formula entry points. Compare the current behavior with the Massachusetts-only example and identify how to avoid breaking changes. Done means a considered implementation that evaluates formulas only for eligible entities without the bugs noted in #64.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Although this might be relevant to Core, I suspect it'd need a much longer discussion to avoid breaking changes, so filing here with a view to implementing as a patch. There have been a few attempts already in #64 , but with some bugs so I though I'd sketch out the cleanest implementation here.
The problem
Some variables are only relevant to a small subset of the population. For example, Massachusetts income tax only needs to be calculated for people and groups in Massachusetts, and not the rest of the population. Right now, we implement the tax as simply zero for those other people, but this causes wasted computation time and space for 98% of entities, because NumPy vectorised operations happen regardless of the retrospective filter at the end.
The solution
We could have the following variable definition:
class ma_tax(Variable):
value_type = float
label = "MA income tax"
definition_period = YEAR
unit = TaxUnit
def eligible(tax_unit, period, parameters):
return tax_unit.household("state_code", period) == "MA"
def formula(tax_unit, period, parameters):
...
eligible is run first to determine the relevant subset of the population, and then the main formula next. This will be much more efficient iff the formula is much more complex than eligible.
#64 has a prototype of the implementation, but it's buggy and needs more thought. I think there's a clean way to do this, intercepting the population passed to the formula to only return the subset values.
cc @MattiSG, @MaxGhenis, @rickecon
- Lingua principale
- Python
- Stelle
- 1
- Fork
- 1
- Merge medio
- 11h 16m
- PR unite (30g)
- 2
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di PolicyEngine/openfisca-tools
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
-
Add piecewise formulasAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
Tutte le issue di PolicyEngine/openfisca-tools
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
SwiftKickMobile/skai#84 ·
-
Lychee link check failedAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
jxxghp/MoviePilot#7070 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
flop-labs/technocore-chat#997 ·
I maintainer di solito rispondono entro 1 giorno
-
tunneld on Windows: Wi-Fi devices are not discovered because uvicorn runs on a ProactorEventLoopAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
doronz88/pymobiledevice3#2051 ·
I maintainer di solito rispondono entro 1 giorno