Todos

[eseiler]

• remove filenames from HIBF, after testing with raptor
  • Add #ifdef RAPTOR_OLD_HIBF for serialization and remove filenames from lib ([MISC] Remove user_bins_type #82)
  • Finally remove #ifdef RAPTOR_OLD_HIBF afterwards
• documentation
• decide what is public and accessible
• read_from/write_to should have error handling. Should it always consume until the appropriate prefix appears?

Done:

• count interface for hibf ([FEATURE] hibf counting #119)
• IBF construction should get a similar ctor as the HIBF ([FEATURE] IBF is now constructible from hibf::config. #80)
• HIBF sets defaults and correct tmax (config.t_max = 0 -> warning? set default like chopper?) ([MISC] Pass mutable to hibf ctor and avoid config copy #66)
• config always const & ([MISC] Pass mutable to hibf ctor and avoid config copy #66)
• error if number_of_bins == 0 in config ([MISC] Pass mutable to hibf ctor and avoid config copy #66)
• remove warning for tmax ([MISC] Pass mutable to hibf ctor and avoid config copy #66) (should we?)
• HIBF should be constructable from a layout file ([FEATURE] Make the HIBF constructible from a layout file. #50)
  • Therefore HIBF lib needs to be able to read and write a layout (from chopper)
• Rename hibf.bulk_containes to hibf.membership_for ([MISC] Rename bulk_contains -> membership_for #55)
• directory structure ([MISC] Change direcotory structure of the repository #54)
• namespaces
  • Renamed to hibf -> seqan::hibf ([MISC] Rename hibf namespace to seqan::hibf #51)
  • check that subnamespaces are consistent ([MISC] Update layout- and add build-subnamespace #58)
• store timer in config ([MISC] Expose timer after HIBF construction #61)
• remove lemon dependency ([FEATURE] Get rid of lemon dependency. #56)
• import chopper tests
  • [TEST] Transfer tests from chopper #16
  • [TEST] Add some detail layout tests. #32
  • [TEST] Transfer hyperloglog and toolbox test. #39
• Check if ctors should be again removed (Added in [MISC] Change order of layout members. #41) ([MISC] Remove user_bin ctor again. #67)
• review config
  • Check if members can be removed
  • Add config validation ([FIX] config validation #78)
  • We have also discussed the following:
    Should the IBF get its own class? Probably yes but well wait for the dynamic_hibf or the paritioned_hibf to have more use cases and think more about the config design
    Should the general/filter config be separated from the layout config? No, because they share e.g. input_fn and number_of_user_bins and it would not be possible to check if input_fn is exactly the same. Or if ONLY in filter config, then it is misleading because the layout needs the input.

[eseiler]

Config

double max_rearrangement_ratio{0.5};
bool disable_estimate_union{false};
bool disable_rearrangement{false};

max_rearrangement_ratio == 0.0 means disable_rearrangement == true.

Estimate union should improve layout.

How much runtime does union estimate and rearrangement add?

Maybe always do union estimate. max_rearrangement_ratio controls rearrangement.

double max_rearrangement_ratio{0.5};
// bool disable_estimate_union{false}; REMOVED
// bool disable_rearrangement{false}; REMOVED