search

kyunghyuncho / NMT

1 stars 1 forks source link

Options #7

Open sebastien-j opened 9 years ago

sebastien-j commented 9 years ago

I open this issue to discuss how we want to allow user options. We could use Groundhog scheme with prototypes and states.

Do you have any preferences? Is there some standard approach with Blocks?

rizar commented 9 years ago

Is there some standard approach with Blocks?

No, there isn't. Unlike Pylearn2 we keep this the user's private territory and allow to do whatever he wants.

I would recommend just use whatever configuration format you find the easiest. The Groundhog scheme is not so bad for small/medium scale experiments. But I would be eager to hear @bartvm's opinion.

bartvm commented 9 years ago

I'm not too familiar with how you managed configuration in GroundHog, but if it is a single state variable that gets read and written to by a variety of functions, I very much dislike it. It looks and smells like a global variable, which says enough. If it's read-only, that's fine of course.

There's no standard approach, and I don't think there really can be one. If you want to publish a script with a command line interface, than argparse should fit your needs. If you have so many configurations that this becomes unmanageable, I would suggest putting your configuration in a separate YAML file. You might even be able to use Blocks' config_parser to manage the configuration for your, including defaults and support for environment variables. If you want the user be able to actually pass Python objects for the configuration (e.g. particular Brick classes or objects) then an importable Python file with a read-only dictionary is also an option.

kyunghyuncho commented 9 years ago

On Thu, Mar 26, 2015 at 4:46 PM, Bart van Merriënboer < notifications@github.com> wrote:

I'm not too familiar with how you managed configuration in GroundHog, but if it is a single state variable that gets read and written to by a variety of functions, I very much dislike it. It looks and smells like a global variable, which says enough. If it's read-only, that's fine of course.

I remember discussing this with someone (maybe, @rizar?), and agree with @bartvm that we should make sure that the configuration (however it's implemented) be read-only.

There's no standard approach, and I don't think there really can be one. If you want to publish a script with a command line interface, than argparse should fit your needs. If you have so many configurations that this becomes unmanageable, I would suggest putting your configuration in a separate YAML file. You might even be able to use Blocks' config_parser to manage the configuration for your, including defaults and support for environment variables. If you want the user be able to actually pass Python objects for the configuration (e.g. particular Brick classes or objects) then an importable Python file with a read-only dictionary is also an option.

— Reply to this email directly or view it on GitHub https://github.com/kyunghyuncho/NMT/issues/7#issuecomment-86708499.

rizar commented 9 years ago

Oops, forgot about this!

I'm not too familiar with how you managed configuration in GroundHog, but if it is a single state variable that gets read and written to by a variety of functions, I very much dislike it. It looks and smells like a global variable, which says enough. If it's read-only, that's fine of course.

Sure, writing to state was awful. Apart from that it was just a global dictionary - a standard representation for configuration.

I would say that command line arguments is a bad solution in terms of scalability and would only use them as an auxiliary tool. Configuration should be a file if a project is a bit more than tiny, IMHO.

orhanf commented 9 years ago

Currently we are following GroundHog's way for options, but with readonly dictionaries, check here