Metamodel Design

NOTICE: This page is out-of-date!

This page contains notes and comments on the design choices of the DeepForge 'nn' metamodel (language design).

Hidden attributes

In DeepForge, hidden attributes could be denoted two main different ways:

• inferred from naming convention
• specified in the attribute meta
• inferred from attribute meta

Specifying it in the attribute meta is a cleaner solution but could potentially have collisions in the future. However, as this will provide a more explicit specification of hidden attributes (rather than implying from a naming convention), this is the approach used in DeepForge.

Integration of Torch Specific Information

This is not standard for model integrated computing. Generally, you have the model then, potentially, multiple possible outputs. That is, the mapping from the model to the output format is contained in the respective plugins.

There are a number of benefits to this (especially wrt separation of concerns). However, there are problems with this approach wrt DeepForge: - DeepForge strives to allow the end user to extend the metamodel and share it - This results in the plugins requiring more info (new mappings) - Users should obviously only be sharing (meta)models and assets. Updated models should not require any changes to the code base. - This means the mapping information for the plugin should be stored in the metamodel

Dimensionality Inference

One feature of DeepForge is the ability to infer the dimensionality of the incoming and outgoing data for each layer. This requires the layers to be able to provide information about how they modify the incoming data dimensions. Every layer definition in the metamodel will contain the following (hidden) attributes for dimensionality inference:

• dimensionalityTransform
  • enumeration with the following types:
    • same
    • custom
• calculateDimensionality
  • lua code that is evaluated within the context of the given layer (with access to the input dimensionality, of course)

To promote portability, this will require this information about the changes to the dimensionality to be stored with the layer's definition in the metamodel. To flexibly support different types of changes to the dimensionality, the output dimensionality calculation for the layer will be written in lua (as lua is required to write custom layer definitions anyway). This will allow users to define custom layers which will be compatible with the dimensionality inference of DeepForge.

As many layers perform elementwise operations which have no effect on the dimensionality of the data, the dimensionalityTransform attribute will be provided and will have two values same or custom where same designates that the incoming and outgoing dimensionality match. More values can be added for additional common transformation types.