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

Computational cost of the Fraction module #2

Open
nikohansen opened this issue May 11, 2020 · 0 comments
Open

Computational cost of the Fraction module #2

nikohansen opened this issue May 11, 2020 · 0 comments

Comments

@nikohansen
Copy link
Contributor

nikohansen commented May 11, 2020

moarchiving uses the Fraction type to avoid rounding errors when computing HV differences. When used to build an archive with more and more dense points, the Fraction module will become more and more computational expensive, quite likely proportional to the archive size or to the iteration count.

Timing of repeated computation of a = (a + b) / 2 with Fraction and with float:

Screen Shot 2020-05-04 at 13 14 01

The "fix" to prevent using Fraction

import moarchiving
moarchiving.BiobjectiveNondominatedSortedList.hypervolume_final_float_type = float
moarchiving.BiobjectiveNondominatedSortedList.hypervolume_computation_float_type = float

will reduce the computational demand problem but also turn off arbitrary precision.

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

1 participant