Friday 11 November 2011

A Thesis on Program and Exceptions


A program is very much like a train which runs on track of instructions.



While an Exception is an end of line in the track of instructions. As Exceptions are events for which no instruction is given to the computer. So on reaching such an event (end) the program crashes.

In the above picture the train (program) is about to crash on reaching the end (exception). 
Exceptions are therefore called events for which no instructions are given to the computer. In other words the program runs out of the track of instructions.
While exception handling is very similar to safe changing of track of the train.
Just ponder upon the following picture.

The try-block is very similar to a radar that detects the exception before hand if it finds any exception it lets the program on a safe track called catch-block.
Isn't it amazing! to think like that.

Thursday 10 November 2011

There are 3 features of OOPs


Following are the 3 features of OOPs:
1) Abstract-o-Encapsulism (Combination of Visible & Invisible data)
2) Polymorphism
3) Inheritance

I just decided to combine the 'Abstraction' and 'Encapsulation' together to form 'Abstract-o-Encapsulism' which is simply ‘Combination of Visible & Invisible data’. As I am convinced that 'Abstraction' and 'Encapsulation' are just 2 aspect of the same thing.


A Grand Linkage:
Likewise, 'Abstraction' is CAUSED by 'Encapsulation'.
So the Equation is,
'Abstraction' + 'Encapsulation' = Whole Truth (Complete Data)
Now,
'Abstraction' = partial Truth (Data) which is visible.
'Encapsulation' = remaining partial Truth (Data) which is invisible.
Therefore,
Partial Truth (Data) which is visible + Remaining partial Truth (Data) which is invisible = Whole Truth (Complete Data) in other words, "Everything around us is Abstract-o-Encapsulism".



- By Suneet K. G. Chaudhary
[E-mail: skgchaudhary@gmail.com]

Wednesday 9 November 2011

Abstraction is Magic (in context of OOP)

I have just discovered a synonym for Abstraction and that is 'Magic'. Anything which you feel like Magic is an Abstraction for you. And most importantly Abstraction is all around us.
For Eg: When a Magician brings out a flower from an empty box. You have absolutely no idea, how the flower reached inside the empty box. There is obviously some way but its hidden. The magician Encapsulates the way through which the flower entered the box. Now, thats what I call an Abstraction.
Similarly, when you use 'Facebook' ever wondered how it works. Its a complete Abstraction. Remember there are hard working developers working behind the scenes for your comfort on Facebook.

Thursday 29 September 2011

Evolution of Classes Architecture


OOP in C (not C++).
#include <stdio.h>
struct Car
{
   int n; 
   void display() 
   {
      printf("The Car no. is %d .", n);
   } 
};
main()
{
   Car c;
   printf("Enter Car no.: ");
   scanf("%d", &c.n); 
   c.display();
   getchar();
   getchar(); 
}
Although it does not have access specifier, constructor, etc yet Struct instances are objects as the have State(i.e. the value of 'x'), Behavior(i.e. the 'display()' method) and Identity(i.e. the Car struct 'c'). 
But most importantly the experimental code reveals to me, that the idea of Classes in OOPs must have evolved from 'Structs'. Just like Man evolved from Monkeys and Lizards evolved from Dinosaurs, in the same way Classes in OOPs evolved from Structs. 
'Structs' are ancestors of 'Classes'.



Of course, the following concepts are not possible in C:
1) Encapsulation: Hiding of data is not possible because of no access specifier.
So, Encapsulation is gone.
2) Abstraction: Without Encapsulation, Abstraction is not possible.
So, Abstraction is gone.
The only things left with is Inheritance and Polymorphism. They are somewhat or rather very much there in the procedural languages like C because in C struct can be inherited and polymorphism of methods(Static Polymorphism) is also possible.


Conclusion: 'C' was already 50% Object - Oriented.

Thursday 7 July 2011

The Idea of 'Common Account-Table Oriented Database Scheme'

1. Account-Table Architecture
The big idea is to develop a concept of 'Complex table'. A 'Common Account-Table' in financial accounting is an instance of 'Complex table'.
And also an account is an object. In fact, an account-table is a special object
I understand that this might sounds like a tricky concept to grasp and might even be outrageous. But then it isn't true, rather this is a simple concept and has enormous scope within it.

2. Using XML
The main reason which motivates me to propose the above idea is the problems of handling XML technology. Yes, although XML is a brilliant technology but it is never handled with broad vision in mind, and the reason is that, different Soft wares have different Schema of XML, so its not possible to map the financial transactions across different Financial Software Systems. Tell me if I am wrong...... Perhaps that is why XBRL which has evolved out of XML which is used only for consolidated financial reports is not so useful for intrinsic Audit Work like vouching and verification.

2. Meteoric Advantages of 'Common Account-Table Oriented Database Scheme'
Now imagine that what would happen after implementation of 'Common Account-Table Oriented Database Scheme' or 'CATODS'? Till now I have reckoned the following benefits: 
  1. Transfer of Accounting Data with its double effect in heterogeneous environment: Firstly, Accounting transactions in detail would be transferred in heterogeneous environment. I reckon that, this itself would bring great revolution in the Accounting world as well as in the field of Auditing. As it would then be very easy for Accounting and Auditing and even Banking concern to procure and transfer data of detailed transactions along with the 'Principles of Accounting' being intact and thereby performing operations efficiently.
  2. Reliability and Accuracy: Since the implementation of double effect is now possible there can be higher level of reliability and accuracy of financial data.
  3. E-Vouching for Financial Audit: The other most important benefit would also be that, there can be a technology constructed to facilitate the Accounts Auditor's 'vouching' and 'verification' work on a very large-scale. This thing really excites me! as this would bring down considerably the chances of fraud and error.
  4. A GPS-system of global-finance: Well, with the above development I see there is a way to keep a global track of finance by unifying the accounting system of every organisation globally. This would then eradicate the possibility of fraud, black-money, tax-theft, etc.

    3. Account-Tables are 'Special Objects'
    But first, let us see and understand, how accounts are objects?
    An 'Object' has state, behavior and identity.
    An 'Account-Table' too has state, behavior and Identity, but they are very simple indeed. To know how, read the following:
    • States of an Account-Table: An account-table can be closed i.e. balance = nil or an account-table may have a debit balance or a credit balance. Thus, the above are the 3 possible states of account-tables and there is no 4th state of account-tables. Isn't that amazing?
    • Behavior of Account-Table: Again an account only has 2 possible behavior either it will be debited or credited as a part of transaction.
    • Identity: Of course, an account-table will also have an unique identity.    
    Apart from being an object account-tables are also special object lets see how?
    All the features of OOPS, namely Abstraction, Encapsulation, Polymorphism and Inheritance can be applied to account-table, when needed, but in addition to the above 4 there is a 5th feature i.e the principle of 'Double-effect'. And this makes the account-tables a special object.

    4. New Account-Table Architecture
    In the above, Account-Table architecture, the idea of normal forms has not been implemented that is why if we convert it into table there are empty cell.
    To avoid it, lets make a new architecture, wherein there is no possibility of empty cell.
    In the above architecture notice that there is no common attribute. There is a complex table namely Account and there are 2 sub-tables namely the 'Debit Table' and 'Credit Table'.
    Accordingly what you get is the following:
    Debit Table in XML format:
    <Cash_DebitTable>
    <CashTransaction>
    <Voucher_No.>NA</Voucher_No.>
    <Date_Dr.>01/04/2011</Date_Dr.>
    <Particulars_Dr.>To Balance b/d</Particulars_Dr.>
    <Amount_Dr.>50000</Amount_Dr.>
    </CashTransaction>
    <CashTransaction>
    <Voucher_No.>S1</Voucher_No.>
    <Date_Dr.>30/04/2011</Date_Dr.>
    <Particulars_Dr.>To Sales a/c</Particulars_Dr.>
    <Amount_Dr.>60000</Amount_Dr.>
    </CashTransaction>
    </Cash_DebitTable>
    Credit Table in XML format:
    <Cash_CreditTable>
    <CashTransaction>
    <Voucher_No.>B1</Voucher_No.>
    <Date_Cr.>01/04/2011</Date_Cr.>
    <Particulars_Cr.>By Bank a/c</Particulars_Cr.>
    <Amount_Cr.>10000</Amount_Cr.>
    </CashTransaction>
    </Cash_CreditTable>

    In the above table Cash A/c is an account-table and has 2 sub-tables namely Debit Table and Credit Table. Here Debit table and Credit table are independently recorded because XML only allows recording of simple tables and not complex tables and thereby fails to implement over the 'double-effect principle'. If you refer to my earlier blog you I have mentioned 2 important features of an Account transactions.
    Click the following:








    Sunday 3 July 2011

    Accounts in XML format: The Twin-table technique

    1. An Introduction
    Although there is availability of XBRL (Extensible Business reporting Language), which is made by application of XML. And XBRL I believe that can store accounting data in a simple table easily and not only that it can store but also process accounting data and can produce reports as desired. However, I am determined to find out a way for storing Accounting data along with its double effect by re-inventing the table structure itself. And I propose a 'Twin-table' technique for implementing the idea. 


    Note a very crucial point: I recently discovered and I am highly convinced that, an Account is not the usual table which we are used to, rather an Account is not a simple table, its actually a Twin-table in my opinion and a bit more complicated.


    2. A Glimpse of the big idea
    Even after knowing that it is not so practical to use XML for storing accounting data with its double-effect, yet for time being just to give a glimpse of what is there in my mind I am using simple XML tags for recording few transactions with double-effect. So far, I found and have tried many ways to do that but the best of them is below:
    Cash Account in XML format:
    - <Cash>
    - <CashAccount Effect="Dr.">
    - <CashTransaction>
      <Voucher_No.>NA</Voucher_No.>
      <Date_Dr.>01/04/2011</Date_Dr.>
      <Particulars_Dr.>To Balance b/d</Particulars_Dr.>
      <Amount_Dr.>50000</Amount_Dr.>
      </CashTransaction>
    - <CashTransaction>
      <Voucher_No.>S1</Voucher_No.>
      <Date_Dr.>30/04/2011</Date_Dr.>
      <Particulars_Dr.>To Sales a/c</Particulars_Dr.>
      <Amount_Dr.>60000</Amount_Dr.>
      </CashTransaction>
      </CashAccount>
    - <CashAccount Effect="Cr.">
    - <CashTransaction>
      <Voucher_No.>B1</Voucher_No.>
      <Date_Cr.>01/04/2011</Date_Cr.>
      <Particulars_Cr.>By Bank a/c</Particulars_Cr.>
      <Amount_Cr.>10000</Amount_Cr.>
      </CashTransaction>
      </CashAccount>
      </Cash>
    If you convert the above XML code into a table, you get the following table:                                       
    Sales Account in XML format:
    - <Sales>
    - <SalesAccount Effect="Dr.">
    - <SalesTransaction>
      <Voucher_No.>SR1</Voucher_No.>
      <Date_Dr.>30/04/2011</Date_Dr.>
      <Particulars_Dr.>To Sales returns a/c</Particulars_Dr.>
      <Amount_Dr.>5000</Amount_Dr.>
      </SalesTransaction>
      </SalesAccount>
    - <SalesAccount Effect="Cr.">
    - <SalesTransaction>
      <Voucher_No.>S1</Voucher_No.>
      <Date_Cr.>30/04/2011</Date_Cr.>
      <Particulars_Cr.>By Cash a/c</Particulars_Cr.>
      <Amount_Cr.>60000</Amount_Cr.>
      </SalesTransaction>
    - <SalesTransaction>
      <Voucher_No.>D1</Voucher_No.>
      <Date_Cr.>30/04/2011</Date_Cr.>
      <Particulars_Cr.>By Sundry Debtors a/c</Particulars_Cr.>
      <Amount_Cr.>50000</Amount_Cr.>
      </SalesTransaction>
      </SalesAccount>
      </Sales>
    If you convert the above XML code into a table, you get the following table:
        
    Note: I admit that there are empty cells above which makes the database inefficient and that there are no implementations of normal forms. But for time being let that be as it is. As the main focus is on understanding the accounting architecture.

    3. An Explanation                                          
    If you see the above tables carefully you will find that, the table has 2 parts, which are independent and unrelated directly to each other. The columns namely 'Date_Dr.', 'Particulars_Dr.' & 'Amount_Dr.' are recording Debit-effect of a transaction. While columns namely 'Date_Cr.', 'Particulars_Cr.' & 'Amount_Cr.' are recording Credit-effect of another transaction. Thus, as already said above that an Account is actually a Twin-table. Still there are 2 common columns shared by both the debit & credit parts namely 'Effect' & 'Voucher_No.' The  'Effect' column clearly mentions whether it is a debit effect or credit effect, while the 'Voucher_No.' mentions the transactions number, which will help in plotting the transactions across different ledgers in other words assure that there is a double effect making the account details. 
    Example: 
    The above transaction is of Cash sales, wherein the Cash A/c is debited (Debit what comes in.) for Rs. 60000 & Sales A/c is credited(Credit all incomes and gains.) for Rs. 60000 which is equally opposite effect.

    4. Principle of double-effect at work
    5. Features of Twin-Table of an Account
    Following are 2 important features of the Twin-tables of an Account (read carefully): 
    • Its a twin table where in every account has one independent table for recording Debit effect of the transactions and another one for recording Credit effect of the transactions. And most importantly, the Debit-table and Credit-table of the Account are independent of each other. A transaction is recorded in either of those 2 tables and never in both the tables of the same account, as debiting an account & crediting the same account in the same transaction is meaningless and never happens. 
    • However, each Transaction in Debit table of one or more accounts has equally opposite effect in the credit table of another account or accounts and vice-versa, which can be traced by 'Voucher No.'. This is none other than the Principle of Double-effect itself. 
    Thus, XML can be used efficiently for storing Accounting Data, but only after implementing a 'Twin-table' technique it cannot be used to store accounting data efficiently as of now.


    However, if you are still finding it hard to understand the principle of double-effect visit the following links:

    Or download an e-book from the following link: