Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - JohnUKresults

Pages: [1] 2 3
1
QB64 Discussion / Re: Maths accuracy
« on: June 14, 2021, 09:25:05 am »
Hi Dav

Thanks for that suggestion.

However, it's the calculation which is important, not the display of the result, so I will have to stick with multiplying the time to make an integer, doing the subtraction, and then putting the decimal point back into the right place for the results.

Like your idea though - might be useful for something else!

2
QB64 Discussion / Re: Maths accuracy
« on: May 26, 2021, 02:37:34 pm »
Thanks all

I just need to 2 decimal points, to take one number from the other and store in a variable (not to print)

I think I have a solution which probably does the job, if a bit untidily

Best wishes to all

3
QB64 Discussion / Re: Maths accuracy
« on: May 26, 2021, 12:39:06 pm »
Thanks

Appreciate all of that detailed explanation, but it's not for printing (hat would be simple), it's for storage and then manipulation, so I'll have to work with the integer method and string slicing I outlined earlier in my post:

Code: QB64: [Select]
  1.                finishseconds& = finishseconds! * 100
  2.                firststartsecs& = VAL(firststartsecs$) * 100
  3.                guntime& = finishseconds& - firststartsecs&
  4.                result$ = _TRIM$(STR$(guntime&))
  5.                length = LEN(result$)
  6.                sec1$ = LEFT$(result$, length - 2)
  7.                sec2$ = RIGHT$(result$, 2)
  8.                elapsed$ = sec1$ + "." + sec2$

4
QB64 Discussion / Re: Maths accuracy
« on: May 26, 2021, 11:19:22 am »
Thanks Felippe

That's all very interesting, but it doesn't answer the question as to whether anyone has a solution that they have tried and works :)

If it can't be done then I'll stick with my Heath Robinson fix. Just slows things down a bit when doing 5000 to 6000 calculations, but it's only a few seconds in the grand scheme of things!

Cheers

5
QB64 Discussion / Re: Maths accuracy
« on: May 26, 2021, 08:59:23 am »
Hi. Thanks for the reply.

For the moment I've had to resort to a somewhat Heath Robinson method to get this sorted, as this 3 decimal place issue could cause cumulative timing issues when fractions get added together (or subtracted)

This is what I'm currently doing. There must be a more elegant solution out there!

Firststartsec$ is a variable used to store the seconds equivalent of the first runner's time of day start time crossing the start line.

Subtracting a runner's finish time from that first start gives a gun elapsed time (as opposed to their personal time which is from when they crossed the start line until they finished)

Code: QB64: [Select]
  1.                finishseconds& = finishseconds! * 100
  2.                firststartsecs& = VAL(firststartsecs$) * 100
  3.                guntime& = finishseconds& - firststartsecs&
  4.                result$ = _TRIM$(STR$(guntime&))
  5.                length = LEN(result$)
  6.                sec1$ = LEFT$(result$, length - 2)
  7.                sec2$ = RIGHT$(result$, 2)
  8.                elapsed$ = sec1$ + "." + sec2$

6
QB64 Discussion / Maths accuracy
« on: May 26, 2021, 07:18:59 am »
Hi all

Trying to do this (although with figures from an array rather than directly programmed numbers - getting the same result):
Code: QB64: [Select]
  1. finishseconds! = 39818.38
  2. startseconds! = 34200.77
  3. PRINT finishseconds! - startseconds!

I should get 5617.61 but for some reason I'm getting 5617.609.

Why and how can I be sure to get the exact result I need? Should I use a different type of number?

I'm using type ! because the numbers could possibly go up to 86400 (number of seconds in 24 hours) and I need 2 decimal point accuracy (as that's what my timing system outputs).

Is there a better option, or alternatively, how can I make sure the answer always comes back rounded up to 5617.61?

Thanks

7
QB64 Discussion / Re: Dynamic Random Access Field creation
« on: May 26, 2021, 07:08:50 am »
Hi all

Thanks for all your suggestions

Decided to use 2D arrays instead!

However, I'm now experiencing another issue - mathematical accuracy! I'll post separately


8
QB64 Discussion / Re: Dynamic Random Access Field creation
« on: May 25, 2021, 06:30:51 am »
ok thanks :-)

9
QB64 Discussion / Re: Dynamic Random Access Field creation
« on: May 24, 2021, 08:13:54 pm »
Sorry, that last comment should be directed to Spriggsy. Not sure why I put Felix!! I blame extreme old age and a late night ;-)

10
QB64 Discussion / Re: Dynamic Random Access Field creation
« on: May 24, 2021, 08:11:03 pm »
Thanks all. Food for thought.

I think I can't do what I want which is to create a record containing x number of fields which are not predefined. I probably didn't fully explain.

Race 1 may have 5 laps, each record containing a number (4 digits), a file pointer (also 4 digits which says which record in another random access file contains competitor information for that race number) and then 6 fields, one for each lap time plus one for the total of those times.

Race 2 might be 10 laps, so 2 x 4 character fields, plus 11 for laps and total.

What I am trying to discover is if there is a way to extend the FIELD line in the program to accommodate any number of laps without having to specify every field e.g. FIELD 1, 4 AS n$(1), 4 AS n$(2), 11 AS n$(3), 11 AS n$(4).... then up to 11 AS n$(×) where x is the number of laps plus 3 (plus 3 to allow for the 3 non-lap fields) just by specifying x at some point in the program.

All of the time fields in each record are the same size, it's just the first 2 which are 4 characters.

Suspect I can't do that.

Whilst I could temporarily work with arrays I would still need files to store that data for future access.

I had thought of sequential files but they are slower to handle and read from.

Felix - if I could handle MySQL I probably wouldn't be asking the question! :-)

Cheers

11
QB64 Discussion / Dynamic Random Access Field creation
« on: May 24, 2021, 01:38:50 pm »
Hi folks

I'm trying to figure out how to set up a random access file where I don't know the overall record size at the outset.

The purpose is to store a number of times for laps of a race. Each race will have its own number of laps which may be (for example) as few as 3 or as many as 12.

The first couple of fields will be of fixed size (4 characters each) to store a race number and also a record number pointer, to access a linked file. The remaining fields will store an 11 character content, which will be a time down to 2 decimal places, such as 01:14:23.21. However, the program needs to be able to set up the RA file on the fly, depending on the number of laps.

It's simple enough to define the total record size (8 plus (laps*11)) but I'm having a problem getting my head round how to set up the FIELD instruction for the file when I don't know how many separate fields will be within the file.

I could make the record size as big as I might ever need (e.g. 96 for 8 laps or 118 for 10 laps) but that seems a bit inefficient and also won't help if I then get a 20 lap race, without rewriting that part of the program.

Has anyone overcome this sort of problem previously?

I'm sure there's a relatively simple solution staring me in the face. If not, I'll go with the 20 lap option even though I may never get that many....

So you know, the number of laps is fixed at the outset of the program, after user input of the value. It's stored in a variables file so won't change after setup, and is read when that file is opened.

Thanks for your time and any input.

12
QB64 Discussion / Re: Is there some magic about the number 1?
« on: May 14, 2021, 12:49:23 pm »
Hi. That's nailed it. Knew it would be something stupid!!

Thanks for your pointer. :-)

13
QB64 Discussion / Re: Is there some magic about the number 1?
« on: May 14, 2021, 12:46:53 pm »
That's a plan!!

I'll try it with filenum%=20+x% first.

Don't want to use FREEFILE as I need to fix in my mind which filenumbers will be used for when I have to be looking through each of the lap files.

It's quite possible that 11 is already being used - hadn't thought of that.

Cheers

14
QB64 Discussion / Is there some magic about the number 1?
« on: May 14, 2021, 12:31:19 pm »
Hi folks

I have a short piece of code within a large program which is driving me mad!! It works fine if I run it as a stand alone bit of code but not when I have it within the program.

The object of the code is to set up some csv files with fixed data fields, the number and names of the files are "lap" plus the lap number. When I run as the separate little program, it correctly installs lap1, lap2 etc. but when I am running it within the main program, even though the inkeys pause shows the correct file name of lap1 having been strung together, it never opens a lap1 file. Frustratingly, if I set the loop to start at 0 it will open a lap 0, then skip lap1 and go to lap 2 - all subsequent lap files open just fine.

I can't see where it's going wrong. Why should it skip file 1 in the main program?

Ignore all the While inkey$="":wend bits - I just put those in so I could see the variables and file names.

Here are the code snippets - the first is the stand-alone version, modified slightly as it's not using a file name string or looking up in a separate random access file:
Code: QB64: [Select]
  1. REM *** create lap files ***
  2.  
  3. FOR x% = 1 TO 5
  4.     x$ = _TRIM$(STR$(x%))
  5.     PRINT x%, x$: WHILE INKEY$ = "": WEND
  6.     lapfile$ = "c:\race\rrclaps\test2\" + "lap" + x$ + ".csv"
  7.     PRINT lapfile$: WHILE INKEY$ = "": WEND
  8.     filenum% = 10 + x%
  9.     OPEN lapfile$ FOR OUTPUT AS filenum%
  10.     FOR y% = 1 TO 10
  11.         WRITE #filenum%, _TRIM$(STR$(y%)), "00:00:00.000", "00:00:00.000", "00:00:00.000"
  12.     NEXT y%
  13.  
  14. NEXT x%
  15.  
  16.  

This is the same code but within the main program, fil$ being the current file name and laps% being the number of laps to be run. File 5 stores a list of race numbers, test2 is the filename for testing, so it's hard-coded into the short program for clarity, but uses fhe fil$ name to point to the right folder in the main program:
Code: QB64: [Select]
  1.  
  2.             REM *** create lap files ***
  3.             FOR x% = 1 TO laps%
  4.                 x$ = _TRIM$(STR$(x%))
  5.                 PRINT x%, x$: WHILE INKEY$ = "": WEND
  6.                 lapfile$ = "c:\race\rrclaps\" + fil$ + "\" + "lap" + x$ + ".csv"
  7.                 PRINT lapfile$: WHILE INKEY$ = "": WEND
  8.                 filenum% = 10 + x%
  9.                 OPEN lapfile$ FOR OUTPUT AS filenum%
  10.                 FOR y% = 1 TO loaded%
  11.                     GET 5, y%
  12.                     WRITE #filenum%, _TRIM$(num$(1)), "00:00:00.000", "00:00:00.000", "00:00:00.000"
  13.                 NEXT y%
  14.             NEXT x%
  15.  

Anyone got any thoughts?

15
Hi

I use the view print commands in my program. Ignore the various variables shown, but the Head.Statusline prints various things at the top of the QB64 window by calling Window.High and then the Window.Low sub returns the focus to the lower part. I've set my top window as the top 4 lines and the bottom window as lines 5 to 25 (I'm sunning this program in the standard screen 0 or whatever QB64 defaults to). The bottom window can scroll happily with new text. I don't know if it would work the other way round i.e. to fix the lower window for information and scroll the top part.

Sorry if this code isn't copied in correctly - not sure how to do that!

SUB Head.StatusLine

    CALL Window.High: COLOR 0, 15
    LOCATE 2, 39: PRINT "[Using-> "; "c:\race\rrcmob\";
    PRINT "]"; SPACE$(32 - LEN("c:\race\rrcmob\"))
    LOCATE 3, 1: PRINT " [File: "; fil$; "]"; SPACE$(8 - LEN(fil$));
    PRINT TAB(19); "[Date: "; racedate$; "]";
    PRINT TAB(47); "[Recs:"; _TRIM$(STR$(loaded%)); "]   "; TAB(62); "[->";
    IF pr% = 0 THEN
        PRINT "Scrn ] ";
    ELSEIF pr% = 1 THEN
        PRINT "Print] ";
    ELSE
        PRINT "Disk ] ";
    END IF
    PRINT "         ";
    COLOR 7, 1: CALL Window.Low

END SUB

SUB Window.High

    VIEW PRINT 1 TO 4

END SUB

SUB Window.Low
 
    VIEW PRINT 5 TO 25

END SUB



Pages: [1] 2 3