THE GENETIC SEQUENCE BINARY FACTOR GROUPING ROUTINES


Sequence ordering resulting from above displayed band(s) extracted from original mRNA scan number series:






Chart overlaping on low enthropy region (high sequence elements redundance) produced with C_.ZIP


Number(s) sequence derivation based on low enthropy (redundant) number groups (c_1.cpp) is based on 2-byte CEL mean column number values used as 4x4(bit) integer array indexes, were actual array values are index occurence counts . Array entries are sorted in an descending order and their descending 4x4(bit) indexes populate a combinations array holding as much as 4(entries) for a 4(bit) index sequence. Permuting each entry would produce a max of 4*4*4*4 number combinations. Each CEL mean column number value was compared vs each combination entry (that also holds a occurence count) and x6 number sequence vector was produced having (occurence) sums of all 6 matching factor combination entries. Thus, a sequence chart was produced, were high Y axis (linear) regions suggest sequences composed of number (combinations) having high occurence counts.



Comparison charts of three leukemia types computed with binary factor grouping from raw CEL files containing fluorescence intensities from Affynetrix U95A chip (MLL translocations specify a distinct gene expression that distingiushes a unique leukemia). (probe groups ALL(1),MLL(2) and AML(3)) are compared bellow. mm57d.cpp scaling parameter ranges from (group count 4,1/5(0.20)),(group count 64,1/51(0.0196)),(group count 128,1/281(0.0035))




These mRNA .CEL (V3) data files were published by the title Cancer Program Datasets at www.broad.mit.edu .

There were computed using this authors method that is motivied by exploration of genetic text complexity as cited by this article (published by www.ncbi.nih.gov) :

On the complexity measures of genetic sequences.

Institute of Mathematics, Siberian Branch of Russian Academy of Science, Novosibirsk, Russia. gusev@math.nsc.ru

MOTIVATION: It is well known that the regulatory regions of genomes are highly repetitive. They are rich in direct, symmetric and complemented repeats, and there is no doubt about the functional significance of these repeats. Among known measures of complexity, the Ziv-Lempel complexity measure reflects most adequately repeats occurring in the text. But this measure does not take into account isomorphic repeats. By isomorphic repeats we mean fragments that are identical (or symmetric) modulo some permutation of the alphabet letters. RESULTS: In this paper, two complexity measures of symbolic sequences are proposed that generalize the Ziv-Lempel complexity measure by taking into account any isomorphic repeats in the text (rather than just direct repeats as in Ziv-Lempel). The first of them, the complexity vector, is designed for small alphabets such as the alphabet of nucleotides. The second is based on a search for the longest isomorphic fragment in the history of sequence synthesis and can be used for alphabets of arbitrary cardinality. These measures have been used for recognition of structural regularities in DNA sequences. Some interesting structures related to the regulatory region of the human growth hormone are reported.


Routine sources are included in mm57.zip and results were computed in the in the following order :

(1) Number group (s) (bands) were determined by several runs of mm57d.cpp using increasing number serie multiplication factor ( e.g. 1,11,21,31,41,51 where size of miltiplier would determine band range and CEL number scope) .
So each mult factor would produce band (s) range (s) scale that is most accurate within a limited range of CEL number (s) value (s).
The produced range files were merged (within or by choosen multiplier segment) into a sigle file e.g. xd.txt regarding number chaining .

(2) mm30315d.cpp run would output CEL array numbers attributed (marked) by band (range) index.

(3) All produced CEL array indexes sectioned by quadrants were permuted in the following way:
e.g. the band index order 123456789 would produce 123, 234, 345, 456 ....
or the following 123456 sequence would permute into 123234345456 .

(4) x6 (number (s)) long permuted sequences represented by 4-bits x4 symbols (A-P for values 0-15) were grouped by binary factor group symbol order . Each group was attributed by the leftmst non-zero x4-bit binary factor segment (s) order number (0-3)
e.g. 1 2 2 2 3 for index sequence ABCC AABA AABD AABC AAAB

(5) ims.cpp would check redundance of each group member outputed by the previous step through the (permuted) CEL file indexes .
It would produce x6 (band) index number long grouped list of redundant index sequences .

(6) mm30317d.cpp would compute index to index range (s) based on each produced redundant sequence group .
Spredsheet document chart curve would display (redundancy) count vs index number (s) axis .

(7) Multiple scan results name (s) cross section of previous file (sets) will determine complex sequence redundance (absence) .
Conjunction of these factor groups builds a unique sequence set expression (cs_1.cpp) . Image bellow present probe set (scans pt1 - pt3 3 probe sets) (CEL files) (y axis) vs unique seqence frequency (x axis) from:Gene Expression-Based Classification and Outcome Prediction of Central Nervous System Embryonal Tumors .




Image bellow present probe set scans pt4 results .




Image bellow presents 50 from prostate_normal_N01-N31.CEL and prostate_normal_N32-N62.CEL .



Image bellow presents 50 from prostate_tumor_T01-T31.CEL and prostate_tumor_T32-T62.CEL .



Sequence pattern (s) from T19 to from above displayed tumor sequence chart difference region , second line from chart difference region belongs to T30 .



Corresponding sequence pattern (s) from N19 .



(8) CEL file mean column values were selected agains a selected column (s) chart pattern numbers (chart columns range indexes subgroup) with s4_b.cpp and actual mean column values were transformed into corresponding actual number column (s) . Produced columns chart display group distribution across the actual number serie . Such number (sub) serie (s) may be compared after computing mean values against included list (.gct files) of protein names .
Actual number sequence (s) from N19 (left column) vs T19 (right column) corresponding to number band (pattern) charts dislayed above .



Bellow - comparisson of actual sequences in T19 (2 charts) vs N19 (2 charts) region 249 to 277 display transformation - tumor vs normal .
Number band (s) were selected from above sequence pattern charts .



To Borce Dzinleski


These routines were written by Dzinleski Jasenko jasenko@unet.com.mk who is the author of C/C++ based routines for encryption/decryption, large numbers operations, the 123SQL database engine and the simplified mariaBasic interpreter which are undergoing projects . This project is self-financing and any contributions are welcomed .

This site resulted in years long support from Borce & Dusica Dzinleski and Nada Popstefanova and is devoted to them and especially to my daughter Maria Dzinleska .The author is currently seeking for a developers job and this is his cv.

IMPLEMENTATION

  • RIFF(WAV) COMPRESSION (principia example)
  • This is a binary compression implementation on PDA recording device output file (16 bit, 8000 Hz, 128 kbps Wav). This functional example performs looseless wav compression on PDA recording file up to 350 sec.

    08.07.2008 VRM 1.0.0 Download File mar70.zip

  • BYTE ORDER COMPRESSION
  • mdiff and boc routines byte order compression utilization via (re) occuring 2-byte order pairs indexing . This routine processes each data byte and next data byte pair (s) through this C/C++ code ((((b8e&<data byte>)>>1)^((b8e&<next data byte>)>>1))<<1)|((b8o&<data byte>)^(b8o&<next data byte>)) where b8e is an 8-bit even bit mask and b8o is an 8-bit odd bit mask . Thus 2-byte (s) order (sequence) is truncated into a single byte field . Two byte resultant field (s) consisting of byte 1, byte 2 and byte 2, byte 3 for a single 16-bit dictionary entry . Thus compressed data results in ( (re) occuring entries) index number order . Index entries are bit truncated when written to the compressed data output file . Compression dictionary produced while compressing typical ASCII data file eg source code or HTML code is relatively small and average compression gains in such files are good .

    12.09.2008 VRM 1.1.0 Download File e1173.zip
    13.09.2008 VRM 1.0.0 Download mdiff, boc and byte order compression in e117_all.zip

  • 6-bit BINARY COMPRESSION
  • This is a fast compression routine based on a 4-byte data word translation via 6-bit bit parity table . 6 bit table entries were computed by ommitting last two bits (having decimal values 1 and 2) in a single byte (0 to 255) giving 64 index entries combination (s) per data byte . Also all truncation entries from a 4-byte data word have only 256 combination (s) . The 4 6-bit (truncated) dictionary entries are (re) indexed and writen to a compressed data output file in a truncated index number order having (binary) length (s) from 7 to 18 bits compared to the original data 32 bit (word) length . Useful for compressing large document data files (binary and text data documents) . Yet compression gain in ASCII data files is obvious due to short binary length of index number entries .

    27.08.2008 VRM 1.2.1 Download File mar6.zip

  • BINARY COMPRESSION 79
  • This a binary compression based on 2-byte data word right (low) bit truncation dependent on max of dictionary (re) occurences for each data buffer . Thus such (truncated) dictionary entries represent most of input data buffer . Dictionary entries are written to the compressed data file in a left truncating manner with the leftmost significant bit ommited , having 7 to 16 bits in length . This method performs fast and efficient data storage . This routine performs principia used in the bellow listed methods .

    01.08.2008 VRM 1.4.0 Download File mar79.zip

  • BINARY TEXT COMPRESSION
  • This is a fast and efficient compression example that executes fast input data indexing and dictionary occurrence search based on binary 4x4-bit long data samples . Indexed sequences are checked vs variable data length buffer .
    Thus this compression method gains speed concerning strict 4x4(16) - bit long dictionary patterns . This routine is subject of further development .

    04.09.2007 VRM 1.3.3 Download File mar9.zip

  • BINARY COMPRESSION ROUTINE
  • Binary compression methods are widely used in communications, data storage and numeric analysis. Exploring genetic complexity numeric sequences employ such methods. Some of them are presented on this site together with a command-line Win32 implementation (s) that demonstrates the capability of compression of large ASCII data files and binary files and also slightly modified in numeric data sequence analysis. This binary compression method is based on numeric sequence generated by the following binary formula as presented by the C/C++ syntax: #define op_7(x,y)(((x+y)^y)|(((x&y)!=0)?(x&y)/y:0)) . This numeric sequence represents all numbers from 0-255(8-bit) for 0-127(7-bit) arguments in an x-y matrix manner . When always x=y and x:0-127 it results in all 8-bit odd numbers . When applied on a 2-byte data sequence it results in 14 or less bits long index . Combined together with one 1-bit substract indicator it will allow compression . Using these arguments as dictionary entries coded by hi/lo/length indicators whose reocurring indexes are stored instead of the input data allows gain of an average 30% compression in large ASCII text files . This numeric sequence formula was generated by another routine written for the purpose of exploring numeric sequences generation .This is an compression Win32 command-line tool based on binary compression . This example states the speed and efficiency of this static large ASCII files compression method .

    04.09.2007 VRM 1.3.3 Download File mar.zip

  • BINARY COMPRESSION 77
  • This is a binary compression based on 2-byte long data binary shifting concatenation (bit density increase) into dictionary entries that are left truncated (common in ASCII data text files) . Compression gain depends on data redundancy in an inverse meaning . The larger the enthropy compression will increase .

    04.06.2008 VRM 1.1.0 Download File mar77.zip

  • BINARY FACTOR GROUPING COMPRESSION ROUTINE
  • This compression example uses binary pattern indexing by 2-byte sequence bit truncation from 16-12 bits in order to gain max of dictionary occurrence . This compression method is a compression gain vs unoptimized compression speed compromise .
    This example states the correctness of the genetic text complexity display routine since its dictionary covers most of the numeric sequences occurrence . Yet this compression example is subject of further development .

    21.09.2007 VRM 1.4.0 Download File mar73.zip

  • ASCII TEXT FILE FAST SORT/INDEXING Routine
  • This is a fast sorting/indexing example that builds a file position sorting tree as a result of n-depth text file line byte sorting . The sorted sequence tree may expand to further depth levels , this routine uses default depth 6. It exibits fast sorting of a text file up to the size 100K lines/rows .
    E.g.: C:\msort3 -f "War and Peace NT.txt"

    30.10.2007 VRM 1.3.1 Download File msort3.zip

  • MDUMP File 2-Byte-4 Sequence Redundance Dump
  • This is a file dump method that finds redundant data structures inside a formatted data binary file . Data structures hold or explain data inside byte (equal byte count length) binary sequnces (that also might had been formatted) . Such binary files are speadsheet , database , compressed or crypted data files . This routine examines redundant 2-byte sequences having equal distances inside 10K data buffer . 2-Byte sequences (combination (s)) are tested for equal distance presence upon probability redundance count . All such sequences are tested agais 4-Byte occurence count and a resultant txtdump.txt file is created . Usefull for creating binary file data structure definition (s) .

    01.10.2008 VRM 1.1.0 Download File mdump.zip

  • MDADD STRING DATE ADD
  • This is a string date add routine that computes add of start date with increment in days, months and (or) years . Comand line switches requires the start date string, increment string input together with a date formating string eg mdadd 20081008 00010000 YYYYMMDD (for adding 1 year) .

    16.11.2008 VRM 1.1.1 Download File mdadd.zip

  • MDDIFF STRING DATE DIFFERENCE
  • This is a string date difference routine that computes difference between two date strings in days, months and years . Comand line switches require two date (s) string input together with a date formating string eg mddiff 19591117 20081008 YYYYMMDD .

    08.10.2008 VRM 1.1.0 Download File mddiff.zip

  • MDIFF FILE COMPARE
  • This is a file compare routine based on a bit parity comparisson of 2-byte sequences . Hashing was built on sequenced use of this C/C++ code ((((b8e&<data byte>)>>1)^((b8e&<next data byte>)>>1))<<1)|((b8o&<data byte>)^(b8o&<next data byte>)) where b8e is an 8-bit even bit mask and b8o is an 8-bit odd bit mask , examined via byte sequence group (s) count (file 1 vs file 2) compare . Command line requires file 1 name and file 2 name resulting in fast comparrison result message . The -d (detail) switch displays all difference (lines) . Useful for file compare and change tracking in document and source code files .

    19.03.2009 VRM 1.3.3 Download File mdiff3.zip
    24.06.2009 VRM 2.0.1 Download File mdiff5.zip

  • BIT PARITY BYTE ORDER FILE CHECKSUM
  • This is a file fingerprint routine that outputs cheksum number (s) file . Hashing was built on sequenced use of this C/C++ code ((((b8e&<data byte>)>>1)^((b8e&<next data byte>)>>1))<<1)|((b8o&<data byte>)^(b8o&<next data byte>)) where b8e is an 8-bit even bit mask and b8o is an 8-bit odd bit mask . Sequenced number treshold count was computed with comarisson of original byte (bit parity) result vs generated result . Number point (s) were computed inside a 1024 byte file buffer and stored (XOR op) inside a 512 number sequence consequently . The output fingerprint file numbers state data order and integrity eg when compared vs same file (copy from restore or data transfer) cheksum (s). Command line requires input filename and cheksum output filename . Usefull for building cheksum list (s) of important data archive (s) .

    25.03.2009 VRM 1.3.0 Download File bp_boc3.zip

    Download Bit Parity Tools bp_tools.zip


    THE RANDOM KEYS DISTRIBUTION ENCRYPTION ROUTINE

    This is a strong encryption method based on a 4 number keys random number distribution . The 4 (5 - digit) number keys provide strong encryption protection due to message hashing that is provided on random number (s) generation where the inputed keys are used as random seeds . Each user choosen key is randomized and message hash is produced with a different randomizing method . Execution requires usage of the following command line switches:
    eg r71 -a 11111 -b 22222 -c 33333 -d 44444 -e < filename to encrypt>
    and to decrypt eg r71 -a 11111 -b 22222 -c 33333 -d 44444 -f < filename to decrypt>

    where the numbers following the -a -b -c and -d switches are user chosen encryption 5 digit number keys.

    1.1(min)...
    minmv=999;
    for(l=0;l<rsi;++l)
    {

    if(n=0||l==0){n=rs[l][1];continue;}
    if(n==rs[l][1]||n+1==rs[l][1]||n-1==rs[l][1]){n=rs[l][1];}else{


    if(minmv>rs[l][2]){minmv=rs[l][2];minl=l;}
    n=0;

    }

    }
    if(df){printf(" %d",rs[minl][0]%outm);}
    htable[hti_dmin][0]=rs[minl][0]%outm;++hti_dmin;
    ...

    1.2(max)...
    maxmv=0;
    for(l=0;l<rsi;++l)
    {

    if(n=0||l==0){n=rs[l][1];continue;}
    if(n==rs[l][1]||n+1==rs[l][1]||n-1==rs[l][1]){n=rs[l][1];}else{


    if(maxmv<rs[l][2]){maxmv=rs[l][2];maxl=l;}
    n=0;

    }

    }
    if(df){printf(" %d",rs[maxl][0]%outm);}
    htable[hti_dmax][1]=rs[maxl][0]%outm;++hti_dmax;
    ...

    2.1(min)...
    minmv=999;
    for(l=0;l<rsi;++l)
    {

    if(n=0||l==0){n=rs[l][1];continue;}
    if(n==rs[l][1]||n+1==rs[l][1]||n-1==rs[l][1])
    {


    n=rs[l][1];
    if(minmv>rs[l][2]){minmv=rs[l][2];minl=l;}

    }else{n=0;}

    }
    if(df){printf(" %d",rs[minl][0]%outm);}
    htable[hti_rmin][3]=rs[minl][0]%outm;++hti_rmin;
    ...

    2.2(max)...
    maxmv=0;
    for(l=0;l<rsi;++l)
    {

    if(n=0||l==0){n=rs[l][1];continue;}
    if(n==rs[l][1]||n+1==rs[l][1]||n-1==rs[l][1])
    {


    n=rs[l][1];
    if(maxmv<rs[l][2]){maxmv=rs[l][2];maxl=l;}

    }else{n=0;}

    }
    if(df){printf(" %d",rs[maxl][0]%outm);}
    htable[hti_rmax][3]=rs[maxl][0]%outm;++hti_rmax;
    ...

    (1) Each of the entered key numbers resultant distribution series (3-133)*(3-7) according to these criteria are written in a 4 column table
    (2) Each table is hashed according the bellow listed binary criteria
    (3) The 4 resulting tables are then re-hashed using the same binary criteria.

    #define op_A(w,x,y,z)(((((w&0x0000ffff)<<16)|x)&0xffff0000)|((((y&0x0000ffff)<<16)|z)&0x0000ffff))
    #define op_B(w,x,y,z)(((((x&0x0000ffff)<<16)|w)&0xffff0000)|((((z&0x0000ffff)<<16)|y)&0x0000ffff))
    #define op_E(w,x,y,z)(op_A(w,x,y,z)>op_B(w,x,y,z)?op_A(w,x,y,z):op_B(w,x,y,z))

    One out of the 4 functions running inside this encryption was used in the Game of life which is listed for download, and it states the diversity of random number distributions produced .

    Try looping this encryption in the following way:

    Step 1.C:\r7 -a <key1 number> -b <key2 number> -c <key3 number> -d <key4 number> -e "filename.txt"
    Step 2.C:\r7 -a <key5 number> -b <key6 number> -c <key7 number> -d <key8 number> -e "previous_output.mar"
    ...
    ...
    Step n.

    and repeat it in the same manner n times until the desired security level is gained .

    18.12.2007 VRM 1.3.3 Download File r7.zip

    MARIAHASH THE ENCRYPTION ROUTINE

    This is a fast encryption routine using proprietary hashing method. Cypher strength depends on a large hashing number and password length . Password text must be entered in a password.txt file and should have between 50 and 100 char(s) .This routine was written by the authors wish to try to improve message privacy while sent across the networks .

    09.06.2007 VRM 1.3.0 Download File 79923.zip

    THE 123SQL DATABASE ENGINE

    This is an undergoing project aimed to construct a small portable SQL database engine for PDA's, and this is a functional browsing engine that contains data and sample browsing statements . Data may be imported together with table/column creation . Typically the source data may be spreadsheet column TAB delimited export data . Database/table/column creation may be viewed in the included code following the -c switch . Table names and column names and field byte sizes should be specified, but column/field lengths my also vary in size row by row . The engine performs SQL keyword/syntax checking using the syntax/keywords list files included . Object names check and object attributes read is performed in the system database files named 123SQL_db_1.mar and 123SQL_db_2.mar . Database structure allows multiple object browsing . The sorting/searching routines require low machine resources thus meeting most modern PDA specifications and their sources were also published under different names .
    This project was founded on the authors' unique relational database engine structure design . The 123SQL engine requires the following command line syntax:
    E.g.: C:\910791 -d "Sample"
    for attaching and browsing the included database, where Sample is the database name included . When
    E.g.: C:\910791 -c "import_data_file.txt"
    the engine will create a database table and table columns as specified in the included create.txt syntax and import the data from the file name specified after the -c switch . Number of column definitions and TAB delimited fields must match, if specified column length is greater than data length space justification will occur . Supported SQL like data browsing syntax is :

    {select}

    {*|column_name|column_name_1,...column_name_n}

    {from}

    {table_name|table_name_1,...table_name_n}

    [where

    |[column_name=string_litteral|column_name>string_litteral|column_name<string_litteral]

    |[column_name>string_litteral and column_name<string_litteral]

    |[column_name[>|<]string_litteral and column_name=string_litteral]

    |[column_name=string_litteral or column_name=string_litteral or column_name=string_litteral]

    |[column_name>string_litteral and column_name<string_litteral and column_name=string_litteral]

    ]

    The MariaBasic Interpreter


    The Maria Basic Interpreter is a command-line programming tool - interpreter aimed to help PDA users code formula/calculations, string and file procedures that execute on their handhelds. The included source code may easily (re) compile for various OS/CPU architectures , since it was written in ISO/ANSI C and requres moderate machine resources . Interpreter design allows fast execution of basic syntax like procedures with calculations and file/string operations. Its simplified syntax allows basic programming skills and may be used for learning , but may expand to execution of rather complex routines . This interpreter allows basic like (simplified) syntax commands like nesting, statement loops, and conditional execution. The ZIP archive ready for download includes a few txt files which are sample basic syntax supported nesting and file/string function example (s) . Source procedures may execute with a command line stating: E.g.: C:\9901 -e "sample.txt". The (sample1...7.txt) example sources show the code structure necessary to supply for program execution .Supported routine code syntax is :

     

     

    MariaBasic 1.9.3.0 Program Structure:

     

    1. Coding convention (s)

    (<string constant> is a single quoted literal)

    (<num constant> is a number literal having [0-9,.] )

    (<varname> is a string literal having [_,a-z,A-Z,0-9] + type declaration [%|&|#|$])

    (type declaration [%|&|#|$] where % EQ integer data type , where & EQ 2x integer data type , where # EQ double data type , and $ EQ <=256 char data type)  

    (logical operator (s) are and , or , xor)

    (relation operator (s) are > , < , = , >= , <= , <> )

     

                2.Program body:

    1.Declarations:

    2. Statements | Simple Block Statements | Nested Block Statements | Declarations | Comments

    3. end Statement

     

    - Comments:

    rem <string constant>

    - Declarations:

    variable declaration (s):
    {
                   [varname$=’<string constant>|’]|[varname%=<num constant>|0]|[varname&=<num constant>|0]|[varname#=<num constant>|0]
    }

     

     

    - Statements:

     

                relation expression logical evaluation statement:

                {

                            varname[%|&]=

    (varname[%|&|#|$][=,<>,>,<,>=,<=]varname[%|&|#|$]

    [ or , and , xor ]

    [ varname[%|&|#|$][=,<>,>,<,>=,<=]varname[%|&|#|$])

    }

     

    calculation statement:

    {

    varname[%|&|#]=[[varname[%|&|#]|[<num constant>]]

     [^,*,/,+,-][[varname[%|&|#]|[<num constant>]]

    }

     

    string concatenation statement:

    {

    varname$=varname$+ varname$

    }

     

    string function statement (s):

    {

    varname[%|&]=len$( varname$)

    varname[%|&|#]=val$( varname$)

    varname$=trim$( varname$)

    varname$=left$( varname$, <num constant>)

    varname$=right$( varname$, <num constant>)

    varname$=mid$( varname$, <num constant>, <num constant>)

    varname$=format$( varname[%|&|#],<string constant>)

    }

     

    file operation statement (s):

    {

    open varname$ for [input]|[output] as #<num constant>

    input #<num constant>, varname$

    print #<num constant>, [<string constant>| varname[%|&|#|$][,]][;]

    close #<num constant>

    }

     

    console output statement:

    {

    print [<string constant>| varname[%|&|#|$][,]][;]

    }

     

     

    - Simple Blocks:

     

    simple if end if block:

    {

    if (<single relation expression>) then

    <statements>

    end if

    }

     

    Simple while wend Block:

    {

    while (<single relation expression>)

    <statements>

    wend

    }

     

    Simple for next Block:

    {

    for  varname[%|&]=[[<num constant>]| varname[%|&]] to [<num constant>| varname[%|&]]

    <statements>

    next varname[%|&]

    }

     

     

     

    - Nested Block Statement (s) (up to Level 3.)

     

    Nested type 1. Block:

    {

    if () then

     

    <statements>

     

                for to

    <statements>

     

                if () then

    <statements>

     

                            end if

                            <statements>

                if () then

    <statements>

     

                            end if

    <statements>

     

                next

     

    <statements>

     

                if () then

    <statements>

     

                if () then

    <statements>

     

                            end if

                <statements>

                if () then

    <statements>

     

                            end if

    <statements>

     

                end if

     

    <statements>

     

    while ()

    <statements>

     

                            if () then

    <statements>

     

                            end if

    <statements>

     

                            if () then

    <statements>

     

                            end if

     

    <statements>

     

    wend

     

    <statements>

     

    end if

    }

     

    Nested type 2. Block:

    {

    for to

     

    <statements>

     

                for to

    <statements>

     

                if () then

    <statements>

     

                            end if

                            <statements>

                if () then

    <statements>

     

                            end if

    <statements>

     

                next

     

    <statements>

     

                if () then

    <statements>

     

                if () then

    <statements>

     

                            end if

                <statements>

                if () then

    <statements>

     

                            end if

    <statements>

     

                end if

     

    <statements>

     

    while ()

    <statements>

     

                            if () then

    <statements>

     

                            end if

    <statements>

     

                            if () then

    <statements>

     

                            end if

     

    <statements>

     

    wend

     

    <statements>

     

    next

    }

     

    Nested type 3. Block:

    {

    while ()

     

    <statements>

     

                for to

    <statements>

     

                if () then

    <statements>

     

                            end if

                            <statements>

                if () then

    <statements>

     

                            end if

    <statements>

     

                next

     

    <statements>

     

                if () then

    <statements>

     

                if () then

    <statements>

     

                            end if

                <statements>

                if () then

    <statements>

     

                            end if

    <statements>

     

                end if

     

    <statements>

     

    while ()

    <statements>

     

                            if () then

    <statements>

     

                            end if

    <statements>

     

                            if () then

    <statements>

     

                            end if

     

    <statements>

     

    wend

     

    <statements>

     

    wend

                }

     

                3. End of Program:

    {end}

     

               

    This interpreter although functional is subject of further development and changes will occur. This package does not include all BASIC build (in) functions except the standard ones and more are going to get implemented. MariaBasic, when compiled for some PDA's compilers enables a simple but efficient programming PDA tool.

    123SQL 15.04.2008 VRM 1.5.0 Download file 123SQL.zip



    MariaBASIC 15.11.2008 VRM 1.6.9.1 Download file mariaBasic7.zip

    MariaBASIC 21.11.2008 VRM 1.7.0.1 Download file mariaBasic71.zip

    MariaBASIC 24.11.2008 VRM 1.9.0.1 Download file mariaBasic73.zip

    MariaBASIC 06.12.2008 VRM 1.9.0.5 Download file mariaBasic75.zip

    MariaBASIC 09.12.2008 VRM 1.9.3.0 Download file mariaBasic77.zip

    Jasenko Dzinleski at Download.com
    Jasenko Dzinleski at Download.com

    Jasenko Dzinleski at Brothersoft.com

    Jasenko Dzinleski at SourceForge.net
    Jasenko Dzinleski at SourceForge.net
    Jasenko Dzinleski at outYard.com - Find, share, sell and download digital goods
    Jasenko Dzinleski at outYard.com - Find, share, sell and download digital goods
    mariaBASIC at Brothersoft.com

    123SQL at Softpedia.com
    Jasenko Dzinleski at Softpedia.com
    123SQL at WindowsMarketplace.com

    123SQL at TigerDirect.com

    Here is a pair of routines written in mariaBasic:

    rem
    rem
    rem
    rem mariaBasic Sample code
    rem
    rem example: simple prime check
    rem
    rem

    var1%=0
    var2%=0
    var3%=0
    var5%=0
    var6%=0
    var7#=0
    var8&=0
    var9%=0
    var10%=0
    var11%=0

    var13%=299



    print "start"
    print " "

    for var1%=100 to 299

    print " ",var1%;

    var6%=var1%/2
    var7#=var1%/2
    var7#=var7#-var6%
    var6%=100*var7#

    var10%=0+0

    for var2%=2 to 298

    if var6%=50 then

    var7#=var1%/var2%
    var8&=var1%/var2%
    var7#=var7#-var8&
    var8&=1000000*var7#

    end if

    if var2%>=var1% then

    var2%=var13%+1

    end if

    if var8&>0 then

    var10%=var10%+1

    end if

    if var8&<0 then

    var10%=var10%+1

    end if

    next var2%

    var11%=var1%-2

    if var10%=var11% then

    print "."

    end if

    next var1%

    print " "
    print "end"

    end

    And here is a sample random generator code written in mariaBasic:

    rem
    rem
    rem
    rem mariaBasic interreter sample code
    rem
    rem example: simple random number generator
    rem
    rem


    var1%=1
    var2%=1

    var3%=11111

    var4%=0

    var51&=0
    var52&=0
    var11#=0
    var12#=0

    var4%=var3%/100

    for var1%=3 to 133

    for var2%=3 to 7

    var11#=1000*var2%/var1%
    var12#=var3%/var11#
    var51&=var12#*var4%
    var52&=var12#*var4%/1000
    var52&=var52&*1000
    var52&=var52&-var51&
    var4%=var4%+1

    if var52&>0 then

    print " ",var52&;

    end if
    if var52&<0 then

    var52&=-1*var52&
    print " ",var52&;

    end if

    next var2%

    var4%=var3%/100

    next var1%

    end

    That is equivalent to the following C/C++ code:

    //-----------------------------------------------------
    //
    // mariaRandom Generator
    //
    //
    // copyright Dzinleski Jasenko 2007 - 2009
    //-----------------------------------------------------
    #include <stdio.h>
    #define seed 11111
    #define outr 133
    #define inr 7
    #define rang 1000

    int main()
    {

    int i,j,k,n;
    double v11,v12;
    long v51,v52;

    printf("\n\n\nThe mariaRandom Generator\n");
    printf("\nWritten by Dzinleski Jasenko July,2007\n");
    printf("OS Win32 VRM 1.0.1\n\n");

    k=seed/100;

    for(i=3;i<outr;++i)
    {

    for(j=3;j<inr;++j)
    {

    v11=1000*j/i;
    v12=seed/v11;
    v51=v12*k;
    v52=v12*k/rang;
    v52=v52*rang;
    v52=v52-v51;
    ++k;

    if(v52>0)
    {

    printf(" %d",v52);

    }

    if(v52<0)
    {

    v52*=-1;
    printf(" %d",v52);

    }

    }

    k=seed/100;

    }


    return(0);

    }

    And here is a game of life using this but yet improoved random number generator
    Download a game of life VRM 1.2.1 at 17.07.2007 .
    Game of life executes via the following command line switches e.g.:r31 -s 31193 -g 50 where the number following -s is the random seed number (mostly over 10000) and the number following the -g switch is the number of generations produced (mostly over 5) .
    Similar but more sofisticated random key seed number distribution is used in THE RANDOM KEYS DISTRIBUTION ENCRYPTION ROUTINE providing strong message file encryption.


    And here is the same game of life using 100x100 cells that outputs the generations data in a graphics BMP file format .
    Download a game of life VRM 1.3.1 at 17.07.2007




    THE FAST (ASCII and Unicode) TEXT FILES SEARCH ROUTINE

    This is a fast text search routine that allows single (or quoted composite) string search throughout an ASCII or Unicode text (text containing) file(s) . Unicode search will also allow strings containing mixtures of different Unicode table(s).
    E.g.:
    1. (ASCII search) msearch3 <ASCII_input_filname.txt> <search_string>
    2. (Unicode search) msearch3 <Unicode_input_filname.txt>
    (search string in Unicode file uarg.txt and search results in Unicode file ures.txt)


    03.07.2008 VRM 1.1.1 Download File msearch3.zip

    THE FAST ASCII TEXT FILES SEARCH ROUTINE

    This is a fast text search routine that allows multi string (up to 10 search strings containing one or more words within) search throughout an ASCII text file . So, each search string (quoted) may have one or more words. The -s switch allows any match, while the -e switch allows only exact match.
    E.g.: C:\msearch -s(-e) "package install"+"media"+"component" -f "FreeBSD Handbook.htm"
    E.g.: C:\msearch -s(-e) "network devices installation" -f "FreeBSD Handbook.htm"
    E.g.:C:\msearch -s(-e) "trodes in his hands" -f "book_sd.txt"
    E.g.:C:\msearch -s(-e) "Bezukhov and Natasha"+"Buonaparte Napoleon"+"Pierre" -f "War_and_Peace_NT.txt"
    The program output will display all results along with their line number file positions, the unique and composite sentence search phrase matches together with their total occurrence count.

    15.04.2008 VRM 1.3.3 Download File msearch.zip

    THE ASCII TEXT FILES SENTENCE CONTEXT SEARCH ROUTINE

    This is a text file complex search routine that allows text search build on the context - sentence words concerning a given subject . This search allows automated search criteria build depending on sentence words contents and user choice . Sentence words files and their sentence links are built during the indexing phase for a given text file . After indexing, the routine will display all sentences for a chosen sentence subject (as enlisted in the words file) and allow detailed context search and all sentences display concerning the chosen context .
    For the indexing type:E.g.: C:\r113 -i "War_and_Peace_NT.txt"
    For the context search type:E.g.: C:\r113 -s(e) "Bagration" -f "War_and_Peace_NT.txt"
    The -s switch enables any match search when d was chosen, and -e switch enables only exact word match. The included files contain the examples book already indexed. Typically the search word is a name, or a subject that is being often described and attributed in the book text . So after viewing/choosing the desired sentence/search combination all text lines containing the chosen words will be displayed . Thus viewing book contents by desired subject details requires smaller amount of time .

    15.04.2008 VRM 1.3.0 Download File r113.zip

    THE FONT IMAGE RECOGNITION ROUTINE

    This routine creates a vector shape sequence file (using -i switch) out of an 100x100 pixels 24 bit colour depth black and white image representing a character true type image (font) or character freehand drawing . Then using the -c switch the two index files derived from two different images are compared and graphics match result is displayed .
    For the indexing type:
    E.g.: C:\cr13 -i "Drawing1.bmp" "Drawing1_Index.txt"
    For the comparison of two different index files type:
    E.g.: C:\cr13 -c "Drawing1_Index.txt" "Drawing2_Index.txt"
    At present the routine builds shape vectors on black/white bitmaps, it does not support different resolution nor colors/color depth.
    But how does it work?

    (1) indexing, creates vector txt file (that might be the meta character file) out of the bmp image file in the following manner:
    - inverts the b/w file matrix (the way human eye sees it),
    - searches for quadrants (10x10 pixels sized) with 40/60% b/w ratio, thus finding character image edges (up to 8 pairs in the same row),
    - creates vectors out of each quadrant,
    - shifts quadrants by (only) few pixels UP since bmp edges do not always REALLY represent character ID curves, repeating vector creation ...
    and
    (2) comparison of two vector files:
    - shifts back all X-axis values subtracting them by absolute minX value,
    - computes curve angles out of each quadrant values,
    - computes resultant angles out of quadrant pairs building most real character curves,
    - compares the two vector files angle pairs,
    - computes match statistics .


    This development is aimed for PDA users using easier ways for text input.
    To Maria Dzinleska

    27.04.2007 VRM 1.0.1 Download File cr13.zip

    THE ROUTINE THAT GENERATES THE PRIME NUMBERS KEY PAIR OUT OF THEIR PRODUCT

    These routines were written during and for the www.rsa.com prime key numbers context that requires finding the exact prime numbers key pair out of a very large (256,512...1024... bits long) product number. The routines were written in java and use the BIGINTEGER java class in order to compute the prime key pair .The starting point routine finds a prime numbers key pair with product_number_bit_length/2 bit length that give sufficient accuracy (near as far as possible) to the product number, the more the preciseness the more the computing time to spend . So the loop that computes the suggested starting prime number pair is limited with the corresponding number of equal product-target significant digits . The remaining procedures consequently perform a very long (all 1's and trailing ZEROS) 111 ... *10^N substraction (s) from the suggested key pair measuring the distance (difference) from the target product number by subsequent multiplication checks . At the point of diverging found and at a certain preciseness (number of equal significant digits) a new key pair may be generated through the first routine . Than the process has to be repeated while gaining more and more equal product-target significant digits .

    23.07.2006 Download File Welcome.zip

    How do these computations compute a very similar or near prime key pair out of a large product key?

    Exmining the bellow listed mariBasic code and its (partial) output shows a few number products appearing at large division loop distances and having a 0000 period between decimal remainder values . Testing those (listed) numbers might prove that most of them are prime numbers . Testing large (200 decimal or more) product keys in this way would take indefinite time . So, the WelcomeQ routine uses a substraction operation on a proposed prime key pair . The routine that generates prime key pairs that have a given decimal target product number match is based on a binary field seed number modification basing only on target match numbers as match search loop starting point . The substractor (having the (decimal) value of e.g. 1111111111000000000000000) shifts the 1111111111 period to the right by approoving that this way truncated prime key pair product matches more and more decimals to the target product number . Actually there are sets of prime kepairs obtaining a certain decimal match .Usually it is necessay to switch between different pairs in order to increase the decimal match of the product . And that is the main iteration of this method sometimes requiring examining and rejecting large number of prime key pairs in order to gain one or more decimal match more . Gaining a 100 decimals precisenes on a common PC computer thus would not be hard to achieve . These computations generate prime keys having computable decimal match gain or complete product number match compared to a given huge product number .

    Brief order and explanation of execution steps:

    (1) generate 5 or more (depending on computing resources) decimal match places vs known target number prime key pairs (number of generated pairs also depends on computing resources)

    (2) start subtracting by a given number of decimal 1 .... 1x10^X and multiplying each of primes in a key pair observing gain or loss in decimal match at product number vs target number . Observe match gain vs number of 1 ... 1 and X in 10^X in the subtraction factor . Thus prime distribution at that number point becomes visible .

    (3) choose a prime probe as a base for generating new sets (depending on computing resources) of prime key pairs gaining usually somewhat less decimal match places at product number vs target number .

    (4) iterate through the previos steps seeking a point at the prime distribution which indicates the existence of the absolute match key pair .

    var1%=0
    var2%=1234567
    var3%=0
    var5%=2
    var6%=0
    var7#=0
    var8&=0
    var9%=0
    var10%=10000
    var191%=0
    var111#=0
    var19%=10000
    var11%=17317
    var123%=91127
    var13%=13009
    var145%=98017
    var15%=12251
    var162%=98327
    var17%=33757

    var3%=var2%/2
    while(var5%<var3%)

    var7#=var10%*var2%/var5%
    var8&=var2%/var5%
    var8&=var7#-var8&*var10%

    if var8&=0 then

    print "=";
    print var5%;
    print "@";
    print var7#;
    print " ",var191%
    var191%=0+0

    end if

    var191%=var191%+1
    var5%=var5%+1
    wend

    end


    =205759@6.000063e+04 1
    =205760@6.000034e+04 1
    =205761@6.000005e+04 1
    =246909@5.000089e+04 41148
    =246910@5.000069e+04 1
    =246911@5.000049e+04 1
    =246912@5.000028e+04 1
    =246913@5.000008e+04 1
    =308635@4.000087e+04 61722
    =308636@4.000075e+04 1
    =308637@4.000062e+04 1
    =308638@4.000049e+04 1
    =308639@4.000036e+04 1
    =308640@4.000023e+04 1
    =308641@4.000010e+04 1
    =411509@3.000097e+04 102868
    =411510@3.000090e+04 1
    =411511@3.000083e+04 1
    =411512@3.000075e+04 1
    =411513@3.000068e+04 1
    =411514@3.000061e+04 1
    =411515@3.000053e+04 1
    =411516@3.000046e+04 1
    =411517@3.000039e+04 1
    =411518@3.000032e+04 1
    =411519@3.000024e+04 1
    =411520@3.000017e+04 1
    =411521@3.000010e+04 1
    =411522@3.000002e+04 1

    Dzinleski Jasenko - jasenko@unet.com.mk

    Mailing Address:
    +38922770296
    Dositej Obradovik 15/8
    1000 Skopje Republic of Macedonia


    All published data, executables and sources from this site described above apply to GNU General Public License and can be used, copied, sold, redistributed or used in any other way only by written permission of Jasenko Dzinleski . Copyright (C) from 2001 - 2009 and later by Jasenko Dzinleski
    This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version .
    This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the GNU General Public License for more details .
    You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc ., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA .