Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove magic numbers #7

Open
renepickhardt opened this issue May 6, 2022 · 2 comments
Open

Remove magic numbers #7

renepickhardt opened this issue May 6, 2022 · 2 comments

Comments

@renepickhardt
Copy link
Owner

Currently we have magic numbers in the code. For example:

https://github.com/renepickhardt/pickhardtpayments/blob/main/pickhardtpayments/UncertaintyChannel.py#L32 specifies MAX_CHANNEL_SIZE = 15_000_000_000 # 150 BTC

this is completely arbitrary and fits the current Lightning Network but chaning this may be necessary in the future but has an impact on the learnt weights in feature engineering.

I guess this is also related to feature engineering in general

@joshfix
Copy link

joshfix commented May 18, 2022

Hi Rene! Speaking of magic numbers, can you explain where the value of 1_400_000_000 comes from in this equation?

uncertaint_cost_feature = log(1_400_000_000/channel_size)

renepickhardt/mpp-splitter#12 (comment)

@renepickhardt
Copy link
Owner Author

I hope the Glossary in the notebook of https://github.com/renepickhardt/mpp-splitter/blob/pickhardt-payments-simulation-dev/Pickhardt-Payments-Simulation.ipynb would be helpful to give the answers (I plan to migrate this to a glossary file in this repo). The reason behind that number explained in this notebook: https://github.com/renepickhardt/mpp-splitter/blob/master/Minimal%20Linearized%20min%20cost%20flow%20example%20for%20MPP.ipynb

TL;DR:

the uncertainty cost uc(a) to send an amount a is defined as -log((c-a+a)/(c+a)) This be linearized as a/c which can be written as 1/c*a. So from that we derive the unit_uncertainty_cost to be 1/c. The problem is that min cost flow solvers use techniques from integer programming and thus need integer cost. Therfor I multiply all unit_uncertainty_cost with the largest capacity that i observed on the network which to get linearized_uncertainty_integer_unit_cost (or some other permuatation fo those words) as 1_400_000_000/channel_size.

Note that the additional log has no meaning and was just there to scale the feature for better visual representation to an logarithmic scale (as I did with the ppm which is the linearized_routing_integer_unit_cost).

The problem of this issue

Of course I could easily alsways take the currently max observed channel size but the problem is that my choice of \mu in feature engineering to include linearized_routing_integer_unit_cost might not work next time when this channel is closed or when we have a much larger one. Thus I tried to use 21M BTC. however if that in satoshi is my scaling factor wit reasonable sized payment amounts I get integer overflows. Thus I will need something smarter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants