LB Booster
Programming >> Liberty BASIC language >> Numeric Field Length RAF
http://lbb.conforums.com/index.cgi?board=lblang&action=display&num=1445528204
Numeric Field Length RAF
Post by joker 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?
Re: Numeric Field Length RAF
Post by Richard Russell 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:
"0.3333"
"0.333333333   "

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.
Re: Numeric Field Length RAF
Post by joker 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.
Re: Numeric Field Length RAF
Post by Richard Russell 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.
Re: Numeric Field Length RAF
Post by joker 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! cheesy
Re: Numeric Field Length RAF
Post by Richard Russell 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:
  1. 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.

  2. 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.