home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / INFO / MISC / TNH_PC.ZIP / RICE.NL < prev    next >
Encoding:
Text File  |  1987-01-14  |  4.3 KB  |  142 lines
  1. Storing Numbers In Random Files
  2.  
  3.               Peter Rice
  4.        Athens IBM PC User Group
  5.  
  6. No matter how expert you may be, it's
  7. always challenging to find your way
  8. around a new computer system. (New
  9. computer users, take heart: it is
  10. just as frustrating for experts as it
  11. is for you.) A case in point is the
  12. use of random files in Microsoft
  13. BASIC -- in particular, how to store
  14. and retrieve numbers from random
  15. files. I've had trouble with this
  16. myself, and others have told me of
  17. similar experiences.
  18.  
  19. Your source of information on this
  20. matter is the BASIC Manual, pages
  21. 4-63, 4-70 and B-9 to B-11. The
  22. process could be better explained
  23. with more good examples given. So
  24. here is an explanation and an
  25. example.
  26.  
  27. There are three kinds of numbers in
  28. BASIC: integers (stored in two
  29. bytes), single precision reals
  30. (stored in four bytes); and double
  31. precision reals (stored in eight
  32. bytes). BASIC knows which is which
  33. because of the way a variable is
  34. stored: one byte stores the type, the
  35. next three to x bytes store the
  36. variable name and the remaining bytes
  37. store the number.
  38.  
  39. All data stored in a random file is
  40. handled as string data. The FIELD
  41. statement, which defines a record,
  42. identifies the data with string
  43. names. The functions which move data
  44. in and out of this record are string
  45. functions. Your numbers must
  46. therefore be changed to strings to
  47. get them in, and must be converted
  48. back when getting them out.
  49.  
  50. One way to do this is to convert a
  51. number digit by digit into string
  52. digits: 0 becomes 48 (="0"); 1
  53. becomes 49 (="1"); etc. This is no
  54. problem -- in fact, CHR$ will do it
  55. nicely and VAL will convert back --
  56. but this takes up more  space on the
  57. disk than is necessary. MKS$ will
  58. convert your single precision number
  59. to a string by changing the first
  60. byte in the storage location of the
  61. number, making BASIC think that the
  62. four bytes which hold the number are
  63. a string. Try PRINT MKS$(44.7) to see
  64. what I mean. Then the number is
  65. stored in four bytes rather than the
  66. eight bytes that might be needed to
  67. store the eight digits of the number
  68. -- A great savings in storage space.
  69.  
  70. CVS will take a four byte string and
  71. convert it back. Of course, if the
  72. string wasn't created by MKS$ in the
  73. first place, garbage will result! To
  74. see this at work, enter the program
  75. below and run it.
  76.  
  77. 100 OPEN "TRIAL.LST" AS #1 LEN=20
  78. 110 FIELD #1,2 AS INTEGER$,4 AS
  79.     REALVAR$,8 AS DOUBLE$
  80. 120 'Get three numbers and store
  81.      them in a record
  82. 130 PRINT"Enter an integer, a real
  83.      number, a double precission
  84.      number"
  85. 140 INPUT A%,B,C#
  86. 150 LSET INTEGER$=MKI$(A%)
  87. 160 LSET REALVAR$=MKS$(B)
  88. 170 LSET DOUBLE$=MKD$(C#)
  89. 180 PUT 31,#1
  90. 190 'Now read the record and convert
  91.      back to numbers
  92. 200 GET #1,1
  93. 210 X%=CVI (INTEGER$)
  94. 220 Y=CVS (REALVAR$)
  95. 230 Z#=CVD (DOUBLE$)
  96. 240 PRINT X% "=" A%,Y "=" B,Z# "=" C#
  97. 250 END
  98.  
  99. You will notice that the INPUT
  100. statement expects three numbers
  101. separated by commas before you hit
  102. the return key. Also, don't give it a
  103. number that it can't take, such as
  104. 35550 for an integer. (The maximum
  105. integer allowed is 32767.) The output
  106. should be three equalities, with the
  107. numbers on each side identical. Now
  108. try changing the length of the
  109. strings by changing the numbers in
  110. the FIELD statement. If a number is
  111. too small, an "illegal function call"
  112. results. If the string is too big, it
  113. works fine because only the leftmost
  114. portion of the string is used.
  115.  
  116. Of course, if you should change an
  117. integer via MKI$ and store the result
  118. in a four byte string variable, then
  119. read it back with CVS, you will get
  120. garbage. It is like trying to read
  121. French with a German dictionary.
  122.  
  123. Also, be careful about reading random
  124. file records that you have not
  125. written. A random file works on the
  126. principle that the record that you
  127. want is just so far into the file. If
  128. you have not written that far into
  129. the file, BASIC has no way of knowing
  130. that. (Sequential files have
  131. end-of-file marks, but random files
  132. do not.) This means that you can read
  133. things that were put there by other
  134. files that have since been erased. Of
  135. course, trying to use CVI on such
  136. data will get nonsense.
  137.  
  138. The secret to getting these clever
  139. functions to work is to use them
  140. exactly right on strings of the right
  141. size.
  142.