Binary classification example:

  

''' 

Binary Classification. 

''' 

import numpy 

import pandas 

from microsoftml import rx_fast_linear, rx_predict 

from revoscalepy.etl.RxDataStep import rx_data_step 

from microsoftml.datasets.datasets import get_dataset 

 

claims = get_dataset("claims") 

 

import sklearn 

if sklearn.__version__ < "0.18": 

    from sklearn.cross_validation import train_test_split 

else: 

    from sklearn.model_selection import train_test_split 

 

claimsdf = claims.as_df() 

claimsdf["isCase"] = claimsdf.case == 1 

data_train, data_test, y_train, y_test = train_test_split(claimsdf, claimsdf.isCase) 

 

forest_model = rx_fast_linear( 

    formula=" isCase ~ age + parity + education + spontaneous + induced ", 

    data=data_train) 

     

# RuntimeError: The type (RxTextData) for file is not supported. 

score_ds = rx_predict(forest_model, data=data_test, 

                     extra_vars_to_write=["isCase", "Score"]) 

                      

# Print the first five rows 

print(rx_data_step(score_ds, number_rows_read=5)) 

 

There are different ways to add role-based access control to principals for an Azure subscription. These can be done in the IaC with something such as: 

Resource azurerm_role_assignment azure_rbac { 

 scope                                 = var.scope 

 role_definition_name    = var.role_definition_name 

 principal_id                      = var.principal_id 

} 

The scope can be specific to a resource or a resource group or a subscription and takes the fully qualified identifier for the same. 

The role definition name can one of many built-in roles that confers permissions to the principal. For example, this could be Owner, Contributor, Reader, Storage Blob Data Reader and so on. 

The principal_id is typically the object id for the user, group or AD entity. If a service principal is used, it must be the corresponding object id of the paired enterprise application otherwise there will be an error message that states “Principals of type Application cannot validly be used in role assignments”. 

There are many ways to populate the attributes of the resource definition via different IaC definitions, but the provider recognizes them generically as a role assignment. 

The preferences among AD entities for use with deployments is managed identity which can be both system and user defined. The benefit of managed identity is that it can work as a credential as opposed to requiring key-secrets to be issued for an enterprise application. 

Some caveats apply to IaC in general for role assignments. For example, the code that requires to assign an rbac based on the managed identity of another resource might not have it during compile time and only find it when it is created during execution time. The rbac IaC will require a principal _id for which the managed identity of the resource created is required. This might require two passes of the execution – one to generate the rbac principal id and another to generate the role assignment with that principal id.    

The above works for newly created resources with two passes but it is still broken for existing resources that might not have an associated managed identity and the rbac IaC tries to apply a principal id when it is empty. In such cases, no matter how many times the role-assignment is applied, it will fail due to the incorrect principal id. In this case, the workaround is to check for the existence of the principal id before it is applied. 

One of the frequently encountered situations is when the rbac assignments proliferate by iterating over other resource types for their associated managed identities. In such cases, the IaC might only appear as a few lines of code but the compilation and execution might result in a lot more new definitions. When this assignment needs to be changed, usually the same must be applied across all the new role assignments. Even the task of reconciling the state with the actual can become quite tedious and require scripts. There is no default grouping to refer to all these assignments together and action taken on one must be repeated on others. It is advisable to start clean by removing all the assignments from the state and reapplying the new infrastructure role-assignment changes. This guarantees a clean state and baseline before each change. 

 

 

 

Binary classification example:

'''

Binary Classification.

'''

import numpy

import pandas

from microsoftml import rx_fast_linear, rx_predict

from revoscalepy.etl.RxDataStep import rx_data_step

from microsoftml.datasets.datasets import get_dataset

 

claims = get_dataset("claims")

 

import sklearn

if sklearn.__version__ < "0.18":

    from sklearn.cross_validation import train_test_split

else:

    from sklearn.model_selection import train_test_split

 

claimsdf = claims.as_df()

claimsdf["isCase"] = claimsdf.case == 1

data_train, data_test, y_train, y_test = train_test_split(claimsdf, claimsdf.isCase)

 

forest_model = rx_fast_linear(

    formula=" isCase ~ age + parity + education + spontaneous + induced ",

    data=data_train)

   

# RuntimeError: The type (RxTextData) for file is not supported.

score_ds = rx_predict(forest_model, data=data_test,

                     extra_vars_to_write=["isCase", "Score"])

                    

# Print the first five rows

print(rx_data_step(score_ds, number_rows_read=5))

 

Pattern to detect an anomaly:

 

import numpy as np

import matplotlib.pyplot as plt

from sklearn import svm

from sklearn.datasets import make_blobs

 

 

# we create 40 separable points

X, y = make_blobs(n_samples=40, centers=2, random_state=6)

 

# fit the model, do not regularize for illustration purposes

clf = svm.SVC(kernel="linear", C=1000)

clf.fit(X, y)

 

plt.scatter(X[:, 0], X[:, 1], c=y, s=30, cmap=plt.cm.Paired)

 

# plot the decision function

ax = plt.gca()

xlim = ax.get_xlim()

ylim = ax.get_ylim()

 

# create grid to evaluate model

xx = np.linspace(xlim[0], xlim[1], 30)

yy = np.linspace(ylim[0], ylim[1], 30)

YY, XX = np.meshgrid(yy, xx)

xy = np.vstack([XX.ravel(), YY.ravel()]).T

Z = clf.decision_function(xy).reshape(XX.shape)

 

# plot decision boundary and margins

ax.contour(XX, YY, Z, colors="k", levels=[-1, 0, 1], alpha=0.5,

           linestyles=["--", "-", "--"])

# plot support vectors

ax.scatter(clf.support_vectors_[:, 0], clf.support_vectors_[:, 1], s=100,

           linewidth=1, facecolors="none", edgecolors="k")

 

plt.savefig("SOSONEP04PyPlot01.pdf")

 

There are different ways to add role-based access control to principals for an Azure subscription. These can be done in the IaC with something such as:

Resource azurerm_role_assignment azure_rbac {

 scope                                 = var.scope

 role_definition_name    = var.role_definition_name

 principal_id                      = var.principal_id

}

The scope can be specific to a resource or a resource group or a subscription and takes the fully qualified identifier for the same.

The role definition name can one of many built-in roles that confers permissions to the principal. For example, this could be Owner, Contributor, Reader, Storage Blob Data Reader and so on.

The principal_id is typically the object id for the user, group or AD entity. If a service principal is used, it must be the corresponding object id of the paired enterprise application otherwise there will be an error message that states “Principals of type Application cannot validly be used in role assignments”.

There are many ways to populate the attributes of the resource definition via different IaC definitions, but the provider recognizes them generically as a role assignment.

The preferences among AD entities for use with deployments is managed identity which can be both system and user defined. The benefit of managed identity is that it can work as a credential as opposed to requiring key-secrets to be issued for an enterprise application.

Some caveats apply to IaC in general for role assignments. For example, the code that requires to assign an rbac based on the managed identity of another resource might not have it during compile time and only find it when it is created during execution time. The rbac IaC will require a principal _id for which the managed identity of the resource created is required. This might require two passes of the execution – one to generate the rbac principal id and another to generate the role assignment with that principal id.  

The above works for newly created resources with two passes but it is still broken for existing resources that might not have an associated managed identity and the rbac IaC tries to apply a principal id when it is empty. In such cases, no matter how many times the role-assignment is applied, it will fail due to the incorrect principal id. In this case, the workaround is to check for the existence of the principal id before it is applied.

 

 

 

Problem: Given two integer arrays preorder and inorder where preorder is the preorder traversal of a binary tree and inorder is the inorder traversal of the same tree, construct and return the binary tree.

 

 

 

    3

    / \

   9   20

       /   \

     15   7

 

Input: preorder = [3,9,20,15,7], inorder = [9,3,15,20,7]

Output: [3,9,20,null,null,15,7]

 

Example 2:

Input: preorder = [-1], inorder = [-1]

Output: [-1]

 

Solution:

Node BuildTree(char[] Preorder, char[] InOrder, int index = 0)
{
 Node root = new Node();
 root.data = PreOrder[index];
 root.left = null;
 root.right = null;

 int inIndex = Arrays,asList(InOrder).indexOf(Preorder[index]);

 if ( index+1 < Preorder.Length &&
       IsLeftSubtree(Preorder[index+1], inOrder, inIndex) == true)
       root.left = BuildTree(Preorder, InOrder, index + 1);

 if ( inIndex+1 < InOrder.Length &&
       isPredecessor(InOrder[inIndex+1], Preorder, index) == false)
       root.right = BuildTree(Preorder, InOrder, Arrays.asList(PreOrder).indexOf(InOrder[inIndex + 1]));

 return root;

}

boolean is Predecessor(char c, char[] Preorder, int index)
{
return Arrays.asList(Preorder).indexOf(c) < index;
}

boolean isLeftSubtree(char c, char[] inOrder, int index)
{
Arrays.asList(Inorder).indexOf(c) < index;
}

 

 

This is a continuation of the previous articles on IaC deployment errors and resolutions. In this section, we talk about in-place edit of resources and their property assignments. When compared to destroy and create, in-place updates of resources are much easier and a relief to deployment supervision because the overall resource behaves the same in relation to its dependencies and those that depend on it. These attributes can include a wide variety from version to rules or features but the address, binding and contract remain somewhat the same as earlier. In-place edits must have a corresponding IaC change. One of the common errors with in-place edits is that what’s feasible via the management portal, SDK or CLI may not be available in the IaC directives. For example, a restart of a resource does not necessarily have a corresponding directive. Another example as with an example of popular Azure App Service is when the access restrictions turn the public access on or off. In both cases, the access restriction remains set. Sometimes this can be overridden by simply adding a rule to allow an ip address which in turn automatically adds a deny all to other source ip addresses. The behavior can have equivalence but does not come with independent directives in the IaC syntax and semantics.

Another example of when in-place edits is not always predefined is when the value is generated. For example, a public ip address resource when deployed by the IaC might yield one ip address when run the first time and another when run subsequently. If the address determines the connectivity to the resource, the client trying to access the resource by the ip address must be changed twice. In such a case, it might be prudent to separate the updates to the resource that goes together with the generation of an ip address and create an ip address for re-purposable assignment beforehand. In those cases, the clients don’t need to change.

A tthird example of in-place edits that are counter-intuitive is when we want to make the changes that can be masked as an in-place edit so that other resources do not need to know. For example, a group of resources can be edited in place without impact to others. All it would take is to treat  a resource and its dependencies as a unit so that even if one requires the other to be informed of the change, the overall update appears in-place to the rest of the deployment.

Another example of an in-place edit is a DNS zone record update to a different ip address. In reality the ‘@’ record is the top-level record of its type for that subdomain represented in the DNS zone and changing its value is essentially assigning the same name to a different resource. In these cases, the client that used to communicate by ip address might no longer be getting the same resource and even iif it is using the same name might not be able to tell the difference when one resource is used instead of the other.

Some of the pitfalls of in-place edits is when the visibility is lost or the changes remain hidden to the deployment and the idempotency is lost because the operations are no longer stateless. Such is the case with an application gateway when the updates to a backend pool member might require the removal and repeat addition of the pool member so that the application gateway can refresh its awareness of that member. In these cases, one might rely on the start/stop behavior rather than actually making these part of the IaC.

These are some of the extended examples of the in-place edits. Thank you for staying tuned.