on 23-Apr-2019 (Tue)

blocks

^^^ example:

resource "aws_instance" "example" {
  ami           = "ami-b374d5a5"
  instance_type = "t2.micro"
}

where you have a block type of resource, with two labels ("aws_instance", which is resource type, and "example" which is your internal name for the resource). And within this resource block you have arguments, describing/declaring the resource.

arguments

^^^ example:

resource "aws_instance" "example" {
  ami           = "ami-b374d5a5"
  instance_type = "t2.micro"
}

where you have a block type of resource, with two labels ("aws_instance", which is resource type, and "example" which is your internal name for the resource). And within this resource block you have arguments, describing/declaring the resource.

In terraform, the main elementes of configuration files are (fill out missing occulsion, note that the two occulsions are for same element, so looking for single answer here):

<BLOCK TYPE> " [...] " " [...] " {
# Block body
<IDENTIFIER> = <EXPRESSION> # Argument
}

BLOCK LABEL

^^ each block type can have 0 or more block labels, e.g. resource blocks ususally have 2 labels while variable blocks have just 1:

resource "aws_instance" "example" {
  ami           = "ami-b374d5a5"
  instance_type = "t2.micro"
}

variable "region" {
  default = "us-east-1"
}

In terraform, the main elementes of configuration files are (fill out missing occulsion):

[...] "<BLOCK LABEL>" "<BLOCK LABEL>" {
# Block body
<IDENTIFIER> = <EXPRESSION> # Argument
}

BLOCK TYPE

^^ e.g. resource blocks type:

resource "aws_instance" "example" {
  ami           = "ami-b374d5a5"
  instance_type = "t2.micro"
}

In terraform, the main elementes of configuration files are (fill out missing occulsion):

<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
# Block body
<IDENTIFIER> = <EXPRESSION> # this line is a block [...]
}

Argument

^^ e.g. following resource block for "aws_instance", has two arguments declaring/describing the resource ("ami" and "instance_type"):

resource "aws_instance" "example" {
  ami           = "ami-b374d5a5"
  instance_type = "t2.micro"
}

In terraform, the main elementes of configuration files are (fill out missing occulsion):

<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
# Block body
<IDENTIFIER> = [...] # Argument
}

Expression

^^ note expression can be litteral or something where value can be evaluated. Either way, final value is of one of types: string, number, bool, list, or map.

Here is example where the arguments have values that are literal string expressions:

resource "aws_instance" "example" {
  ami           = "ami-b374d5a5"
  instance_type = "t2.micro"
}

boolean

^^ boolean is one of either: true, false

true or false

^^ note no quotes are used above

^^^ terraform convirts "true" to true, etc.

In terraform, for maps, each key value declaration is seperated by [...] char, and key/value pairs are seprated from each other with either line break (more common) or comma (less common, only when everything is on single line)

e.g.:
{
name [...] "John"
age [...] 52
}

NOTE: looking for one answer in all 3 occultions

=

^^^ note equal sign, NOT colon, like python

After the success of CNNs in IVSRC 2012 (Krizhevsky et al. (2012)), initialization with Gaussian noise with mean equal to zero and standard deviation set to 0.01 and adding bias equal to one for some layers become very popular.

Why it is not possible to train very deep networks from scratch with this initialization?

In terraform, HCL, complete the map literal value below that defines a person with name john (string) and age 52 (number):

{

[...]

}

{
  name = "John"
  age  = 52
}

^^^ note the name/value pairs are seperated from each other with spaces

^^^^ note each name and value are seperated by equal signs