From da9e152566f00c324f0d1ea4626e59170ab7a5bc Mon Sep 17 00:00:00 2001 From: Prayag Verma Date: Sat, 30 Jan 2016 23:55:32 +0530 Subject: [PATCH] Fix spelling mistake in Roadmap.md environement > environment compatibilty > compatibility emabarassingly > embarrassingly unnecesasrily > unnecessarily lighweight > lightweight curcial > crucial existance > existence --- ROADMAP.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 488ac281..cb9c5ad6 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -18,8 +18,8 @@ The roadmap focuses on five separate things - New class system: - **[definite]** with no global side-effects (i.e. the class constructor should be scoped into its parent package) - Get rid of every statement/system that has a global effect on the environement (torch.setdefaultensortype => dangerous and not clean) - - **[needs discussion]** fully serializable (i.e. when deserializing/reloading a model, there shouldn't be a need to load libraries that defined the class originally, like nn; the class definition should be serialized as well: this would remove a lot of backward compatibilty hacks that we have to add to class definitions currently + Get rid of every statement/system that has a global effect on the environment (torch.setdefaultensortype => dangerous and not clean) + - **[needs discussion]** fully serializable (i.e. when deserializing/reloading a model, there shouldn't be a need to load libraries that defined the class originally, like nn; the class definition should be serialized as well: this would remove a lot of backward compatibility hacks that we have to add to class definitions currently - **koray**: I like this, but wouldn't it break backward compatibility? Currently, whatever we serialize, it is just the data and implementation is defined at load time, so if a bug is fixed (or introduced) you use that. @@ -29,7 +29,7 @@ The roadmap focuses on five separate things - **[needs discussion]** OpenMP: Should it stay or go? Is Threads sufficient? - **Ronan**: I really wonder about this guy, especially now that I have been using threads intensively. I am not sure that fine-grine threading is necessary. - **koray**: I guess you mean with threading, there is no need for OpenMP, but I disagree. - Our convolution layer will use multiple threads and then if we run a ReLu over a huge state space, it would become emabarassingly slow. + Our convolution layer will use multiple threads and then if we run a ReLu over a huge state space, it would become embarrassingly slow. We shouldn't expect everyone to run their experiments in a threading framework. It is more work than necessary sometimes.) - **[needs discussion]** Templated C++ in TH Core? - **Ronan**: Should I cleanup TH core? In the end, I am scared to move to C++, but some iterators based taking a closure could be nice (I have some of those that I could add easily). @@ -39,14 +39,14 @@ The roadmap focuses on five separate things - **[definite]** Benchmarking support in Tester - **[definite]** Consistent testing scripts across all core projects - **[definite]** 'nn' container unified interface between containers and graph - - **[mostly definite]** Switch to batch only assumption in 'nn'. Right now, the code is unnecesasrily complicated for stochastic/batch confusion, we needed extra functions like nInputDims and such. + - **[mostly definite]** Switch to batch only assumption in 'nn'. Right now, the code is unnecessarily complicated for stochastic/batch confusion, we needed extra functions like nInputDims and such. - **[needs discussion]** Support named arguments in the constructor for all 'nn' layers. - **[definite]** 'rnn' package. - **Soumith**: Nicholas Leonard's seems to be a good one. - **[mostly definite]** argcheck for all core functions in torch. Get rid of cwrap's ugliness. - **[definite]** improve paths to support more file system operations - **Clement**: could lfs and penlight be made more standard? penlight is a heavy package but provides so much utility - - **Soumith**: I think penlight is lighweight and provides strong utility, definitely consider dependence. + - **Soumith**: I think penlight is lightweight and provides strong utility, definitely consider dependence. - **[definite]** JIT/Lua/FFI/GC: - **koray**: I think Torch should be agnostic to whatever is the backend; - **clement**: yes! @@ -93,7 +93,7 @@ The roadmap focuses on five separate things - This ties to the first question in **Other Questions** section. - Can we/community do pull requests on iTorch? ( **Soumith**: Yes ) - First step would be to leanify dependencies and/or install procedure (**Soumith**: agreed) -- **[needs discussion]** How about Penlight? It has many curcial things that people use. +- **[needs discussion]** How about Penlight? It has many crucial things that people use. Should we endorse it, use some things from it? Replicate some things in penlight in torch? - **clement**: upvoting this! we use it extensively. - **Ronan**: I live better with less abstractions, but I can be convinced there. @@ -139,6 +139,6 @@ The roadmap focuses on five separate things - being able to do pull requests? - Licensing? - or maybe maintain a list of suggested packages? - - when does existance of a package stop us from developing the same in core torch? + - when does existence of a package stop us from developing the same in core torch? - **Soumith**: I think this should largely be community driven and by popularity. Top starred or watched repos in the ecosystem would be a good start.