Author |
Topic: Numeric Field Length RAF (Read 680 times) |
|
joker
Global Moderator
member is offline
Gender: 
Posts: 157
|
 |
Numeric Field Length RAF
« Thread started on: Oct 22nd, 2015, 3:36pm » |
|
Short of creating the following in a test, I have this question.
In the LB help file under FIELD, it doesn't really completely explain what is stored in a RAF via the FIELD statement via a NUMERIC variable.
NUMERIC can be a "million" bytes long so if I limit the length via the FIELD statement, what gets thrown out and what gets saved?
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Numeric Field Length RAF
« Reply #1 on: Oct 22nd, 2015, 9:16pm » |
|
on Oct 22nd, 2015, 3:36pm, pnlawrence wrote:| what is stored in a RAF via the FIELD statement via a NUMERIC variable. |
|
The numeric value is first converted into a string (equivalent to the STR$ function). If the resulting string is shorter than the specified field length, it is padded to that length with spaces. If the resulting string is longer than the specified field length, it is truncated.
It's not difficult to do the test:
Code: field1 = 1/3
field2 = 1/3
open "test.raf" for random as #1 len = 20
field #1, 6 as field1, 14 as field2
put #1, 1
close #1
open "test.raf" for random as #2 len = 20
field #2, 6 as field1$, 14 as field2$
get #2, 1
close #2
print chr$(34);field1$;chr$(34)
print chr$(34);field2$;chr$(34)
This program outputs:
Output from Code:
What the LB docs don't make clear is that a RANDOM file only contains strings. Specifying a numeric variable in a FIELD statement is just a shortcut for using STR$() when the field is written (PUT) and VAL() when the field is read (GET).
Richard.
|
|
|
|
joker
Global Moderator
member is offline
Gender:
Posts: 157
|
|
Re: Numeric Field Length RAF
« Reply #2 on: Oct 23rd, 2015, 12:09am » |
|
I'm away from my programming desk, but that makes sense. I just couldn't find anything like that in the literature available to me.
I'm converting everything to strings anyway, but I did have a number that needs a certain number of significant digits. I'll have to work that out.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Numeric Field Length RAF
« Reply #3 on: Oct 23rd, 2015, 09:01am » |
|
on Oct 23rd, 2015, 12:09am, pnlawrence wrote:| I'm converting everything to strings anyway, but I did have a number that needs a certain number of significant digits. I'll have to work that out. |
|
USING() will format a number to a given number of decimal places but LB 4 has no built-in mechanism for controlling the number of significant figures, which is a limitation. Fortunately LBB's USING() is extended and you can do it, but only by converting the number to scientific notation:
Code: pi = 4 * atn(1)
for i = 1 to 4
print using("#.####^^^^", pi)
pi *= 10
next i
Output from Code:3.1416E0
3.1416E1
3.1416E2
3.1416E3
More comprehensive control over numeric formatting can be achieved using Windows API calls, or by accessing BBC BASIC code from LBB, but they are 'advanced' techniques!
Note that LBB's floating-point ('real') variables have a precision of about 19 decimal digits compared with about 16 digits for LB 4.04 and 4.5.0. But when converted to a string, using STR$(), both LB and LBB preserve only 9 digits, so using numeric variables in a FIELD statement potentially results is a very significant loss of precision.
Richard.
|
|
Logged
|
|
|
|
joker
Global Moderator
member is offline
Gender:
Posts: 157
|
|
Re: Numeric Field Length RAF
« Reply #4 on: Oct 23rd, 2015, 10:16am » |
|
Of course, RAFs are not intended to be database files with all of their intended complications, but for a little bit I was encouraged with LBs "numeric" FIELD design.
Curses! Dashed again! 
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Numeric Field Length RAF
« Reply #5 on: Oct 23rd, 2015, 11:01am » |
|
on Oct 23rd, 2015, 10:16am, pnlawrence wrote:| for a little bit I was encouraged with LBs "numeric" FIELD design. |
|
A couple of points:
You can always do the numeric to string conversion yourself and then write the string to the RAF, that way you have complete control over precision etc.
Since LB/LBB can read and write any kind of file you can exactly reproduce the functionality of GET and PUT, or devise your own custom database format, using regular file-handling statements and functions such as PRINT# and INPUT$ in conjunction with SEEK. Richard.
|
|
Logged
|
|
|
|
|
