Principal Component Analysis in Machine Learning

Hello everybody,

today I want to note important for me details of Machine Learning. 

So, the first and very important usage of PCA is visualizing data. If you have 10 dimensions, can you visualize those data? If you can I'm happy about you, but I can't. I can imagine only 1, 2, 3 D :). But with principal componenet analysis it's possible to visualize data. 

Second application is reducing memory/disk need to store data. That's quite self-explanatory, to train on 10 000 dimensions and 100 dimensions is different.

Third is speeding up learning algorithm. It's actually related with second.

Another important detail, it's bad idea to use PCA in order to avoid overfitting. Actually everybody who does machine learning knows that decreasing number of features increases chances of overfitting.

How to override base event in Acumatica

Hello everybody,

Imagine following scenario. You have some code in base class, which you need to change. How to do it. For this purpose you can use PXOverride attribute.

See the following code:

public class YourExtension : PXGraphExtension<SomeBasicGraph>
{
   [PXOverride]
   public void MethodForOverriding(string viewName, IEnumerable items)
   {
      // Method body
   }
}

In case which is presented MethodForOverriding of base class will be called. If you want to avoid it, you can add additional argument to the code,

and then manipulate how to call it or even omit calling of method from base logic. Look at the following code:

[Update, thanks to Taras Vynar]

public class YourExtension : PXGraphExtension<SomeBasicGraph>
{
  [PXOverride]
  public void MethodForOverriding(string viewName, IDictionary keys, IDictionary values, Action<string, IDictionary, IDictionary> methodDel)
  {
    //some your code
    methodDel(viewName, keys, values);
    //again some of your code. 
    return res;
  }
}

This is very similar to overriding events of DAC classes as mentioned here

Event handlers in Acumatica

Hello everybody,

today I want to share with you how order of event handlers in Acumatica is organized.

Each graph has list of event handlers for each type of manipultaion. Also new declarations of methods can be added to the start or then end of collection, and there are events which are added in the beginning of collection.

According to T300 event handlers which are added to the end of collection:

    • FieldUpdated(PXCache sender, PXFieldUpdatedEventArgs e)

    • RowSelecting(PXCache sender, PXRowSelectingEventArgs e)

    • RowSelected(PXCache sender, PXRowSelectedEventArgs e)

    • RowInserted(PXCache sender, PXRowInsertedEventArgs e)

    • RowUpdated(PXCache sender, PXRowUpdatedEventArgs e)

    • RowDeleted(PXCache sender, PXRowDeletedEventArgs e)

    • RowPersisted(PXCache sender, PXRowPersistedEventArgs e

Let's say we considered about RowPersisted event. Then the schema will be following:

Base.RowPersisted -> 1st level event handler -> 2nd level event handler. In other words, initially Acumatica code will be executed, and after your code will be executed.

There are also events which has another order which are added to the beginning of the collection:

 

• FieldSelecting(PXCache sender, PXFieldSelectingEventArgs e)

• FieldDefaulting(PXCache sender, PXFieldDefaultingEventArgs e)

• FieldUpdating(PXCache sender, PXFieldUpdatingEventArgs e)

• FieldVerifying(PXCache sender, PXFieldVerifyingEventArgs e)

• RowInserting(PXCache sender, PXRowInsertingEventArgs e)

• RowUpdating(PXCache sender, PXRowUpdatingEventArgs e)

• RowDeleting(PXCache sender, PXRowDeletingEventArgs e)

• RowPersisting(PXCache sender, PXRowPersistingEventArgs e)

• CommandPreparing(PXCache sender, PXCommandPreparingEventArgs e)

• ExceptionHandling(PXCache sender, PXExceptionHandlingEventArgs e)

From RowPersisting prospective following chain will be executed:

2nd level.RowPersisting  -> 1st level.RowPersisting -> Base.RowPersisting. In other words initially your code will be executed, and only thereafter Acumatica code will be executed and (!!!!) modify your changes to some others. In my practice it was situation, that my changes to RowPersisting was lost because Acumatica basic code removed my code.

Probably you can have question, is there a way to modify this behaviour. What if I want to change order? Yes, it's possible. You just need to use PXAcumaticaEvent template. Look at code below:

protected void DAC_RowUpdated(PXCache cache, PXRowUpdatedEventArgs e, PXRowUpdated del)
{
  //your code can be here 
  if (del != null)
     del(sender, e);
  //or here. Or even in both places
}
Or you can even ignore calling of base code.
protected void DAC_RowUpdated(PXCache cache, PXRowUpdatedEventArgs e, PXRowUpdated del)
{
  //your code can be here 
}
In the second case basic code will not be executed.

With such tricks you can modify behavior in the way you like.

Usage of base views in Acumatica

Hello everybody.

Today I want to write interesting detail, which was strange for me. 

Imagine situation, that you in Extention class want to change some behaviour and want to ask something from view in base graph. You can try to do it with Base.BaseViewName.Cache.Current. And according to my observations it works. But as mentioned in T300 manual To query a data view declared within the base BLC or lower-level extension from the data view delegate, you should redeclare the data view within the BLC extension.

If you want to ask why this copy/paste needed I honestly will tell you: I don't know :)

Extentsion table in Acumatica with IsOptional

Hello everybody,

today I want to notice few words about attribute IsOptional. DAC extension can be mapped by inner join, or by left join statement. 

[PXTable(IsOptional = value)] // default is false, or Inner join
public class DACTableExtension : PXCacheExtension<BaseDACTable>
{
 ... 
}

As far as I understand idea behind name, IsOptional means are there additional items from left join. And if set to true, means yes, there are, and if set to false ( default way ) there are not.

The left join way ( IsOptional = true ) can be used for

  • not synched tables
  • creates extension record when record in base table created or updated
  • calculates default field values if no extension table record is found.
  • can be used as separated DAC ( this is shocking for me from viewpoint why to make extension, which can have separated life).

The inner join ( default ) way:

  • always synched
  • extension records automatically created with connection to base record
  • copies key column values to each extension table
  • removes from original db table record when there is not corresponding extension table record
  • can be used as separated DAC ( for me again this was another surprise )

 

If to summarise, both ways you can use as separeted DAC

DeletedDatabaseRecord in Acumatica

Hello everybody,

today I want to share notice about DeletedDatabaseRecord database field. Sometime in db you can notice DeletedDatabaseRecord field. For example there is DAC Sub. You can even wonder what is this if it is not visible for users? It is purposed Acumatica for monitoring is record deleted, and presented. 

Another area of usage DeletedDatabaseRecord is extension tables. If you want to use extension table, and basic table has DeletedDatabaseRecord, then you should add it to extension table as well.

Auto discovery mechanism of Acumatica Extensibility Framework

Hello everybody,

another interesting notice today. 

Imagine following situation.

1. You have base class. Let it is called GraphX. 

2. In your library you created extentions of this grap: GraphXExt1, GraphXExt2 at the same level. For example like this:

public class GraphXExt1 : PXGraphExtension<GraphX>
{
   protected virtual void ARTran_USRProjectID_FieldDefaulting(PXCache sender, 
PXFieldDefaultingEventArgs e) { } } public class GraphXExt2 : PXGraphExtension<GraphX> { protected virtual void ARTran_USRProjectID_FieldDefaulting(PXCache sender, PXFieldDefaultingEventArgs e) { } }

3. Then question, if page will be loaded, which ARTran_USRProjectID_FieldDefaulting will be executed? From GraphXExt1 or from GraphXExt2?

The answer is the last loaded ( !!!!! ). If last loaded by framework will be GraphXExt2 then GraphXExt2 will be the winner. If last loaded will be GraphXExt1 then page will execute ARTran_USRProjectID_FieldDefaulting of GraphXExt1. Acumatica doesn't have any way to configure loading sequence of graphs. It means that it is crazy idea to make changes of the same member in two different graphs.

What is companyid in Acumatica

Hello everybody,

today I want to notice few words about companyid field. What is it's purpose. Initially Acumatica provides two !!!! companyid. 1 and 2. Why two? The first is for some Acumatica internal usage, and then your company will get id 2. Even if you believe that your company deserve to be 1, you'll get 2 or more. It means that first active company will have id 2 or bigger. So, if you have some DAC which should be used by few companies, then you just add companyid field, make it as key, and that's it, Acumatica will track to which company your entity should belong.

Debugging learning algorithm

Few notes of how to debug machine learning algorithm:

  1. Get more training examples
  2. Try smaller sets of features
  3. Try getting additional features
  4. Try adding polinomial features
  5. Try increasing lambda
  6. Try decreasing lambda

What those trys can achieve:

  1. fixes high variance
  2. fixes high variance
  3. fixes high bias
  4. fixes high bias
  5. fixes high bias
  6. fixes high variance