| Argument passing - Subroutines and Functions - Mike Pope |
| Caching in on the Frames Array - Mike Pope |
| QTIPS - Fast Dynamic Array Building |
| Creating Your Own Background Processes |
| @ATTACK - @Last.Select.Process |
| Reader's Forum |
| QTIPS - Menu Item Pre-Processing |
| VERBatim - V17 |
| VERBatim - V6 |
| VERBatim - V125 |
| Utility Diskette # 3 - Part I |
| Version 3 Technical Highlights - Copying Rows Programmatically |
| Version 3 TCL Subroutines - Copying Rows |
| Playing with Scan Codes |
| QTIPS - Compiling Protection Code |
| QTIPS - Invalid Code and Command |
| QTIPS - Code/Command Help |
| Compiling 64K on a Shoestring by Blaise Wrenn (LexStat Systems Ltd) |
| QTIPS - Command Line Options |
| QTIPS - Invalid Code and Command |
| QTIPS - Code/Command Help |
| Utility Diskette # 4 |
RevMedia FKB
| Document | V1I4A10 |
| Title | RTP Series - RTP33 |
| Keywords | RTP33 LOCATE BY |
| Text | The LOCATE processor Used for both LOCATE and LOCATE BY The AREV version of LOCATE BY works USING a binary chop algorithm unlike the G2 B version which uses a sequential search The binary chop is many times more efficient for finding a sorted place within an array (for those of you who have not encountered a binary chop before the algorithm (assuming a sorted array) bisects the array and sees if the middle value is above or below the value being sought It then takes the half that the value being sought is found in and bisects this This new middle value is compared to the value being sought and the same process is repeated This continues until a match is found and a value is returned If there are 64K values to be checked after one chop there will be 32K AFTER two chops 16K AFTER 3 8K AFTER 4 4K after 5 2K AFTER 6 1K AFTER 7 512 AFTER 8 256 AFTER 9 126 AFTER 10 64 after 11 32 AFTER 12 16 AFTER 13 8 AFTER 14 4 AFTER 15 2 and the sixteenth comparison would yield the result This is the worst case scenario! Sixteen comparisons in place of 64K comparisons A significant improvement!) If any readers still use G2 B we have a copy of $RTP33 which incorporates the new binary chop logic but for G2 B This speeds up all manner of things but especially the filing of records WITH large associated XREF records Send us a disk and we'd be glad to send you the code One point however if you know that the array is sorted and you want to check for the existence or non existence of a value within the array (without SETTING a pos correctly for insertion) the LOCATE command is always faster than the LOCATE BY Whilst this seems peculiar it has to do with the algorithm design ALSO remember that as pointed out in issue 1 of REVMEDIA a LOCATE BY "AR" will return the same position for 1 as for 01 (Volume 1 Issue 4 Pages 5 6) |
Page last modified: 08/02/03