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

Model config #376

Closed
lukedeo opened this issue Jul 10, 2015 · 2 comments
Closed

Model config #376

lukedeo opened this issue Jul 10, 2015 · 2 comments

Comments

@lukedeo
Copy link
Contributor

lukedeo commented Jul 10, 2015

Hey @fchollet, I'm using keras in some research, and I've found myself making a config system like caffe (except I'm using json in lieu of protobuf). I've been using a system like:

{
    "data_layers" : [
        {
            "name" : "raw_data",
            "connects_to" : "maxout/1"
        },
        {
            "name" : "other_data", 
            "connects_to" : "dense/1"
        }
    ],
    "output_layers" : [
        {
            "name" : "output",
            "input" : "softmax/1"
        }
    ],
    "components" : {
        "dense/1" : {
            "class" : "Dense",
            "input" : "other_data",
            "constructor" : {
                "input_dim" : 15,
                "output_dim" : 10,
                "activation" : "relu"
            }
        },
        "maxout/1" : {
            "class" : "MaxoutDense",
            "input" : "raw_data",
            "constructor" : {
                "input_dim" : 30,
                "output_dim" : 20,
                "nb_feature" : 10
            }
        },
        "dropout/1" : {
            "class" : "Dropout", 
            "input": "maxout/1",
            "constructor" : {
                "p" : 0.5
            }
        },
        "dropout/2" : {
            "class" : "Dropout", 
            "input": "dense/1",
            "constructor" : {
                "p" : 0.2
            }
        },
        "softmax/1" : {
            "class" : "Dense",
            "inputs" : ["dropout/1", "dropout/2"],
            "merge_mode" : "concat",
            "constructor" : {
                "input_dim" : 30,
                "output_dim" : 12,
                "activation" : "softmax"
            }
        }
    }, 
}

Which is equivalent to

graph = Graph()
graph.add_input(name='raw_data')
graph.add_input(name='other_data')

graph.add_node(Dense(15, 10, activation='relu'), name='dense/1', input='other_data')
graph.add_node(MaxoutDense(30, 20, 10), name='maxout/1', input='raw_data')

graph.add_node(Dropout(0.5)), name='dropout/1', input='maxout/1')
graph.add_node(Dropout(0.2)), name='dropout/2', input='dense/1')

graph.add_node(Dense(30, 12, activation='softmax'), name='softmax/1', inputs=['dropout/1', 'dropout/2'], merge_mode='concat')

graph.add_output(name='output', input='softmax/1')

If I organized this in a nice way, would this be useful to Keras as a PR?

@pranv
Copy link
Contributor

pranv commented Jul 10, 2015

One of the goals of Keras is not to have separate definition mechanism unlike Caffe.But having it couldn't hurt

On Fri, Jul 10, 2015 at 6:25 PM, Luke de Oliveira
[email protected] wrote:

Hey @fchollet, I'm using keras in some research, and I've found myself making a config system like caffe (except I'm using json in lieu of protobuf). I've been using a system like:

{
  "data_layers" : [
      {
          "name" : "raw_data",
          "connects_to" : "maxout/1"
      },
      {
          "name" : "other_data", 
          "connects_to" : "dense/1"
      }
  ],
  "output_layers" : [
      {
          "name" : "output",
          "input" : "softmax/1"
      }
  ],
  "components" : {
      "dense/1" : {
          "class" : "Dense",
          "input" : "other_data",
          "constructor" : {
              "input_dim" : 15,
              "output_dim" : 10,
              "activation" : "relu"
          }
      },
      "maxout/1" : {
          "class" : "MaxoutDense",
          "input" : "raw_data",
          "constructor" : {
              "input_dim" : 30,
              "output_dim" : 20,
              "nb_feature" : 10
          }
      },
      "dropout/1" : {
          "class" : "Dropout", 
          "input": "maxout/1",
          "constructor" : {
              "p" : 0.5
          }
      },
      "dropout/2" : {
          "class" : "Dropout", 
          "input": "dense/1",
          "constructor" : {
              "p" : 0.2
          }
      },
      "softmax/1" : {
          "class" : "Dense",
          "inputs" : ["dropout/1", "dropout/2"],
          "merge_mode" : "concat",
          "constructor" : {
              "input_dim" : 30,
              "output_dim" : 12,
              "activation" : "softmax"
          }
      }
  }, 
}

Which is equivalent to

graph = Graph()
graph.add_input(name='raw_data')
graph.add_input(name='other_data')
graph.add_node(Dense(15, 10, activation='relu'), name='dense/1', input='other_data')
graph.add_node(MaxoutDense(30, 20, 10), name='maxout/1', input='raw_data')
graph.add_node(Dropout(0.5)), name='dropout/1', input='maxout/1')
graph.add_node(Dropout(0.2)), name='dropout/2', input='dense/1')
graph.add_node(Dense(30, 12, activation='softmax'), name='softmax/1', inputs=['dropout/1', 'dropout/2'], merge_mode='concat')
graph.add_output(name='output', input='softmax/1')

If I organized this in a nice way, would this be useful to Keras as a PR?

Reply to this email directly or view it on GitHub:
#376

@fchollet
Copy link
Collaborator

I think the existing get_config method on Graph has quite a bit of margin for improvement, so if you want to tackle that it's cool (we're not using them for anything yet, but in the future we might, e.g. model serialization, etc).

A few comments:

  • having a "constructor" section is layer configs is probably a good idea indeed
  • "data_layers": the term is "inputs" in the Graph model
  • "output_layers": the term is "outputs"
  • "components": the term is "nodes"
  • "connects_to": we don't use this information when building the model

Overall, I think simple improvements to the existing get_config method should suffice to achieve full serialization capabilities. Can you detail what your problems were with this method? Then we can fix that.

@lukedeo lukedeo closed this as completed Jul 16, 2015
fchollet pushed a commit that referenced this issue Sep 22, 2023
* jax ignore sorted in top_k

* Ignore sorted argument for jax top_k

`sorted=True` is a strictly stronger guarantee than `sorted=False`, so
better to always return `sorted=True` than add an annoying inconsistency
between what backends support what.
hubingallin pushed a commit to hubingallin/keras that referenced this issue Sep 22, 2023
* jax ignore sorted in top_k

* Ignore sorted argument for jax top_k

`sorted=True` is a strictly stronger guarantee than `sorted=False`, so
better to always return `sorted=True` than add an annoying inconsistency
between what backends support what.
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

No branches or pull requests

3 participants