|
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 COMPRESSIONmdiff 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 Brothersoft.com
Jasenko Dzinleski at SourceForge.net
Jasenko Dzinleski at outYard.com - Find, share, sell and download digital goods
mariaBASIC at Brothersoft.com
123SQL 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 .
|