[ 
https://issues.apache.org/jira/browse/SINGA-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lee Chonho updated SINGA-81:
----------------------------
    Description: 
Proposed design v1
- (1) have a class named Builder
   * (2) use Boost::parameter library (+ associated necessary header files)

(1)
Builder class implements api-like functions to configure JobProto including 
NetProto (LayerProto), ClusterProto, UpdaterProto, etc.

Two options
a. users call Builder's functions in main.cc like
{code}
JobProto jobproto;
Builder builder( &jobproto, "job name" );
builder.xxx(xxx)  // add data layer
builder.xxx(xxx)  // add parser layer
... etc. ...
{code}

b. we set main.cc like below and users call Builders functions in Construct() 
{code}
JobProto jobproto;
Builder builder( &jobproto, "model name" );
builder.Construct()
{code}

(2)
Planning to use header-only files from Boost library
- if the necessary files are small enough
- because we can use "named arguments" feature with no restriction of # of 
arguments, order, types.
- because function will be intuitive, and adding users' own proto in a 
straightforward way.

Example is here. http://theboostcpplibraries.com/boost.parameter
By following the example, we can do like
{code}
BOOST_PARAMETER_MEMBER_FUNCTION(   
 (char*), AddLayerData,   tag,   
 (required     
   (type, (int))  (name, (char*))  (src, (char*))
 ) 
 (optional     
   (path, (char*), *) (bsize (int) *)
 ) )
 {
    ...  // set values
    return name;
 }
{code}

Then, users can add a datalayer by

{code}
L1 = builder.AddLayerData(kShardData, "data", null, _path="train_shard", 
_bsize=1000);
{code}

(TODO)
- make use of google protobuf reflection for efficient parameter setting
- need to avoid multiple calls for adding same/similar layers

Any suggestion, design idea, comments please.

  was:
Proposed design v1
- (1) have a class named Builder
- (2) use Boost::parameter library (+ associated necessary header files)

(1)
Builder class implements api-like functions to configure JobProto including 
NetProto (LayerProto), ClusterProto, UpdaterProto, etc.

Two options
a. users call Builder's functions in main.cc like
{code}
JobProto jobproto;
Builder builder( &jobproto, "job name" );
builder.xxx(xxx)  // add data layer
builder.xxx(xxx)  // add parser layer
... etc. ...
{code}

b. we set main.cc like below and users call Builders functions in Construct() 
{code}
JobProto jobproto;
Builder builder( &jobproto, "model name" );
builder.Construct()
{code}

(2)
Planning to use header-only files from Boost library
- if the necessary files are small enough
- because we can use "named arguments" feature with no restriction of # of 
arguments, order, types.
- because function will be intuitive, and adding users' own proto in a 
straightforward way.

Example is here. http://theboostcpplibraries.com/boost.parameter
By following the example, we can do like
{code}
BOOST_PARAMETER_MEMBER_FUNCTION(   
 (char*), AddLayerData,   tag,   
 (required     
   (type, (int))  (name, (char*))  (src, (char*))
 ) 
 (optional     
   (path, (char*), *) (bsize (int) *)
 ) )
 {
    ...  // set values
    return name;
 }
{code}

Then, users can add a datalayer by

{code}
L1 = builder.AddLayerData(kShardData, "data", null, _path="train_shard", 
_bsize=1000);
{code}

(TODO)
- make use of google protobuf reflection for efficient parameter setting
- need to avoid multiple calls for adding same/similar layers

Any suggestion, design idea, comments please.


> Add Python Helper, which enables users to construct a model (JobProto) and 
> run Singa in Python
> ----------------------------------------------------------------------------------------------
>
>                 Key: SINGA-81
>                 URL: https://issues.apache.org/jira/browse/SINGA-81
>             Project: Singa
>          Issue Type: New Feature
>            Reporter: Lee Chonho
>
> Proposed design v1
> - (1) have a class named Builder
>    * (2) use Boost::parameter library (+ associated necessary header files)
> (1)
> Builder class implements api-like functions to configure JobProto including 
> NetProto (LayerProto), ClusterProto, UpdaterProto, etc.
> Two options
> a. users call Builder's functions in main.cc like
> {code}
> JobProto jobproto;
> Builder builder( &jobproto, "job name" );
> builder.xxx(xxx)  // add data layer
> builder.xxx(xxx)  // add parser layer
> ... etc. ...
> {code}
> b. we set main.cc like below and users call Builders functions in Construct() 
> {code}
> JobProto jobproto;
> Builder builder( &jobproto, "model name" );
> builder.Construct()
> {code}
> (2)
> Planning to use header-only files from Boost library
> - if the necessary files are small enough
> - because we can use "named arguments" feature with no restriction of # of 
> arguments, order, types.
> - because function will be intuitive, and adding users' own proto in a 
> straightforward way.
> Example is here. http://theboostcpplibraries.com/boost.parameter
> By following the example, we can do like
> {code}
> BOOST_PARAMETER_MEMBER_FUNCTION(   
>  (char*), AddLayerData,   tag,   
>  (required     
>    (type, (int))  (name, (char*))  (src, (char*))
>  ) 
>  (optional     
>    (path, (char*), *) (bsize (int) *)
>  ) )
>  {
>     ...  // set values
>     return name;
>  }
> {code}
> Then, users can add a datalayer by
> {code}
> L1 = builder.AddLayerData(kShardData, "data", null, _path="train_shard", 
> _bsize=1000);
> {code}
> (TODO)
> - make use of google protobuf reflection for efficient parameter setting
> - need to avoid multiple calls for adding same/similar layers
> Any suggestion, design idea, comments please.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to