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

Question regarding the coupling between problems and files #16

Closed
chkoar opened this issue Feb 6, 2021 · 8 comments · Fixed by #74
Closed

Question regarding the coupling between problems and files #16

chkoar opened this issue Feb 6, 2021 · 8 comments · Fixed by #74

Comments

@chkoar
Copy link
Contributor

chkoar commented Feb 6, 2021

Related: openjournals/joss-reviews#2974

Why the problem classes are coupled with files and not with other data structures?

@chkoar chkoar changed the title [joss-reviews#2974] [joss-reviews#2974] Question regarding the coupling between problems and files Feb 6, 2021
@geoffreyp
Copy link
Contributor

Combinatorial problems implemented (ρMNK-Landscapes, Knapsack and MUBQP) are using instance files. These files are generated with generators (noted in the documentation) by using specific parameters for each instance. I think it will be complicated to implement these generators in our framework to generate exactly the same instance file with the same seed (to compare the results for the same instance between two algorithms with another framework).

Problem classes are strongly inspired by the example code of the generator's authors (for example: http://svn.code.sf.net/p/mocobench/code/trunk/rmnk/generator/java/)

@chkoar
Copy link
Contributor Author

chkoar commented Feb 14, 2021

Since the implemented combinatorial problems are coupled with specific type of problems it should be instantiated using the specific file type and version.

file_mapping = {
    "rmnk_0_2_100_1_0": ...
}


class Rmnk:
    def __init__(file="rmnk_0_2_100_1_0"):
         if isinstance(file, str):
             ....

That way your avoiding the clutter and give the ability to the user to specify the verion of the problem or to pass the file itself is he/she wants to.

@geoffreyp
Copy link
Contributor

Sorry but I am not sure to understand, you propose to replace the str attribute instance_file (for example "/home/mydir/instances/rmnk_0_2_100_1_0.txt") by the attribute file which can be a str (as before with instance_file) or directly a file file=open(instance_file, 'r')?

I don't understand the dict file_mapping but for example for the Rmnk problem, instance files can be named "instance1.txt" or "rmnk1.txt" because parameters are read in the content of the file and not in the file name, so we can't check the filename.

@sjvrijn
Copy link
Contributor

sjvrijn commented Mar 29, 2021

Maybe something like Pooch can be of help? Although that's more aimed at larger files.

@chkoar
Copy link
Contributor Author

chkoar commented Jul 19, 2021

My point is that requiring external files (even for known problems) makes the things difficult. Take a look here. My proposal is to use instance files directly as a last resort. 1) provide the data directly (I know cumbersome), 2) Using a factory and 3)instance files.

@chkoar chkoar removed their assignment Jul 19, 2021
@chkoar
Copy link
Contributor Author

chkoar commented Jul 19, 2021

makes the things difficult.

Even for the example in the readme a user is instructed to go somewhere and download a file.

@geoffreyp
Copy link
Contributor

I added all the parameters in problems to allow the user to not use the instance file :
#74

@chkoar
Copy link
Contributor Author

chkoar commented Sep 25, 2021

Let's keep this issue out of the review

@chkoar chkoar removed their assignment Sep 25, 2021
@geoffreyp geoffreyp changed the title [joss-reviews#2974] Question regarding the coupling between problems and files Question regarding the coupling between problems and files Sep 25, 2021
@geoffreyp geoffreyp linked a pull request Sep 25, 2021 that will close this issue
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

Successfully merging a pull request may close this issue.

3 participants