REVMEDIA FKB Articles - AREV, OI, REV G, jREV, JCDC, LIVEWATER,ADVANCED REVELATION, OPENINSIGHT, REVELATION G

RevMedia FKB

Document	V2I4A5
Title	Base Conversions
Keywords	BASE CONVERSION ASCII OCONV ICONV SEQ
Text	Users of other SYSTEMS coming to AREV for the first time cannot help but notice that as a consequence of the lack of "typing" data is that all data is stored as ASCII strings WITH no specialised storage for integers or real numbers This is not a particularly efficient way of coping WITH integers one byte could be used to represent a number between 0 and 255 rather than just 0 and 9 as at present Normally this restriction is not a limitation but in the case of relational indexes it can severely limit our system As a rough rule of thumb assuming a five digit key only 8 10 000 record keys can be stored in a relational index In addition one BTREE node (being limited in size to around 1K) can only store 150 200 such keys meaning that every 150 200 keys returned from a BTREE EXTRACT operation requires an additional disk i/o It would therefore be a good idea were an alternative base to be used in place of base 10 for integer keys If a higher base such as base 210 were used two bytes could contain up to 44099 rather than 99 This sort of compaction more than doubles the amount of records possible to maintain in a relational index and does the same for BTREE nodes The choice of base within AREV is limited We need to express the number by storing ASCII characters If we used Base 256 CHAR(0) = 0 CHAR(1) = 1 CHAR(254) = 254 CHAR(1) : CHAR(1) = 257 (1 * 256 + 1) etc The system however uses characters above 246 as delimiters so characters above 246 could not be used as they would be treated as delimiters It might therefore seem reasonable to use Base 246 so these PROBLEMS are not encountered However the use of Base 246 is again precluded because as has been shown in REVMEDIA passim low ASCII characters can create PROBLEMS with keys A base starting at CHAR(33) (so as to avoid spaces in keys) and finishing below CHAR(247) is therefore desirable for personal reasons the author chooses to use Base 210 The best way to implement the use of another Base within AREV is as a User Defined Conversion On ICONV the routine must take an ASCII integer and process it to create the data in the alternative base On OCONV the routine must take the alternative base data and convert it back to a Base 10 integer The code presented below achieves this functionality If defaults to Base 210 but any base may be used by USING the option branch label on the ICONV/OCONV call The routine must be entered compiled and and catalogued Then to convert 2500 to Base 210 one would use INTERN = ICONV(2500 "[BASE]") To convert to Base 150 one would use INTERN = ICONV(2500 "[BASE 150]" TO OCONV reverse the exercise eg EXTERN = OCONV(INTERN "[BASE]") and EXTERN = OCONV(INTERN "[BASE 150]") respectively Note that this form of Base conversion is not what a mathematician would term a Base conversion but it achieves our required objectives SUBROUTINE BASE (TYPE PASSED BASE RET VAL) * * Author AMcA * Date July 1990 * Purpose Provide a base conversion conversion * Notes Note that 33 is added on ICONV subtracted on OCONV to * ensure that all stored characters are > " " thus zero * will always be stored as ! ( 0 + 33) = CHAR(33) * IF BASE = "" THEN BASE = 210 ; * Default BEGIN CASE CASE TYPE = "ICONV" GOSUB ICONV CASE TYPE = "OCONV" GOSUB OCONV END CASE RETURN ICONV: RETURNED = "" SAVE_PASSED = PASSED LOOP PASSED = INT(PASSED/BASE) WHILE PASSED DO IF PASSED > BASE THEN * * Just add in remainder and continue * RET VAL=CHAR(MOD(PASSED BASE)+33): RET VAL END ELSE RET VAL = CHAR(PASSED+33) : RET VAL END REPEAT * * Finally add on remainder * RET VAL := CHAR(MOD(SAVE_PASSED BASE) +33) RETURN OCONV: RET VAL = "" LENGTH = LEN(PASSED) FOR X = 1 TP LENGTH VALUE = SEQ(PASSED[X 1]) 33 * * If the variable is three characters long the first byte must be * multiplied by the base raised to the POWER 2 (length 1) the * second byte must be multiplied by the base raised to the POWER 1 * (length 2) and the final byte must be multiplied by 1 (that is the * same as the base raised to the POWER 0 (length 3) * VALUE = VALUE * (BASE^(LENGTH X)) NEXT RETURN (Volume 2 Issue 4 Pages 7 8)

[revmedia/copyrigh.htm]

Page last modified: 08/02/03