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.


Topics - zaadstra

Pages: [1]
1
QB64 Discussion / Calculation difference between QB64 64 and 32 bit versions
« on: September 30, 2021, 10:13:42 am »
Hi,

Writing a little epoch calculator, I ran into an issue which looked like rounding.  However, the suspected part was a muliplication of huge numbers.

Inspired by this topic https://www.qb64.org/forum/index.php?topic=4210.0 "Possible error in INTEGER64 calculations",  I changed a variable in the suspected calculation to _INTEGER64 and got it working.
When noticing that I still was in QB64-32 I switched to QB64-64 and recompiled. And there the bug was back. I got it woriking by DIMming all variables to _INTEGER64.

Code: QB64: [Select]
  2.  
  3. '  2019:02:05 17:50:30
  4. tm$ = "1978:09:30 15:00:00"
  5. 'tm$ = "1970:01:02 00:00:00"
  6.  
  7. 'DIM tm_sec AS _INTEGER64
  8. 'DIM tm_min AS _INTEGER64
  9. 'DIM tm_hour AS _INTEGER64
  10. 'DIM tm_day AS _INTEGER64
  11. 'DIM tm_month AS _INTEGER64
  12. DIM tm_year AS _INTEGER64
  13. 'DIM tm_yday AS _INTEGER64
  14.  
  15. tm_sec = VAL(MID$(tm$, 18, 2))
  16. tm_min = VAL(MID$(tm$, 15, 2))
  17. tm_hour = VAL(MID$(tm$, 12, 2))
  18. tm_day = VAL(MID$(tm$, 9, 2))
  19. tm_month = VAL(MID$(tm$, 6, 2))
  20. tm_year = VAL(MID$(tm$, 1, 4)) - 1900
  21.  
  22. tm_yday = INT(275 * tm_month / 9) - (INT((tm_month + 9) / 12) * (1 + INT((tm_year - 4 * INT(tm_year / 4) + 2) / 3))) + tm_day - 30
  23.  
  24. tm_epoch&& = tm_sec + tm_min * 60 + tm_hour * 3600 + (tm_yday - 1) * 86400 + (tm_year - 70) * 31536000 + INT((tm_year - 69) / 4) * 86400 - INT((tm_year - 1) / 100) * 86400 + INT((tm_year + 299) / 400) * 86400
  25.  
  26. PRINT tm$
  27. PRINT tm_yday ' check: https://www.esrl.noaa.gov/gmd/grad/neubrew/Calendar.jsp?view=DOY&year=2021&col=4
  28. PRINT tm_epoch&& ' check: https://www.epochconverter.com/
  29. 'PRINT
  30. 'PRINT (tm_year - 70) * 31536000&& ' this is the bastard
  31. 'PRINT INT((tm_year - 69) / 4) * 86400
  32. 'PRINT INT((tm_year - 1) / 100)
  33. 'PRINT INT((tm_year + 299) / 400) * 86400

Output QB64-32:
Code: Text: [Select]
  1. 1978:09:30 15:00:00
  2.  273
  3.  276015600

Output QB64-64:
Code: Text: [Select]
  1. 1978:09:30 15:00:00
  2.  273
  3.  276015616

Removing the REMarks on all DIM lines makes QB64-64 print the same correct result as QB64-32.
When all DIM's are REMmed and only the output var tm_epoch is _INTEGER64, both compilers calculate the result wrong by 16.
Both QB64 32 and 64 bit are version 1.5.

Is this some magic, or reversed restrictictions making the smaller bit compiler run more accurate?
What are the common rules and best practices here?

2
QB64 Discussion / INT not always doing the INT thing
« on: April 26, 2021, 04:38:55 pm »
Hi all,

I have a little program copying stuff and printing progress.  The GB's are rounded to one decimal, like 89.3 GB.
Sometimes the number prints a lot of garbage, like 89.90000000001 GB.  I narrowed it down to the code below, which shows the same behaviour.

Code: QB64: [Select]
  3. allfolderstotal&& = 22123456789
  4. FOR sizedone&& = 1 TO allfolderstotal&& / 2 STEP RND * 100000000
  5.    _DELAY 0.050
  6.    PRINT STR$(INT(sizedone&& / 107374182.4) / 10) + " GB (" + LTRIM$(STR$(INT(sizedone&& / allfolderstotal&& * 100))) + "%)"

Part of the output:

Code: Text: [Select]
  1.  8.2 GB (39%)
  2.  8.2 GB (40%)
  3.  8.300000000000001 GB (40%)
  4.  8.4 GB (40%)
  5.  8.4 GB (41%)
  6.  8.5 GB (41%)
  7.  8.6 GB (41%)
  8.  8.6 GB (42%)
  9.  8.7 GB (42%)
  10.  8.800000000000001 GB (42%)
  11.  8.800000000000001 GB (43%)
  12.  8.9 GB (43%)
  13.  9 GB (43%)
  14.  9 GB (44%)
  15.  9.1 GB (44%)
  16.  9.1 GB (44%)
  17.  9.2 GB (44%)
  18.  9.300000000000001 GB (45%)
  19.  9.300000000000001 GB (45%)
  20.  9.4 GB (45%)
  21.  9.5 GB (46%)

The interesting this is that the abnomalies always are on the same spots.   I tested with QB64 v1.4 32 and 64 bit, and v1.5 64 bit, all (un)behave the same.
Remove the /2 in the FOR line and you'll see that above 10 GB it does not happen up to 22 GB.  I have a progam screenshot of 89.9000000001 GB ... Again starting with an 8?
What is going on here?   Is it a bug or a feature? :-)

Actually, the /10 divide may be guilty instead of the INT ...

3
QB64 Discussion / QB64 1.5 keywords in capitals?
« on: April 24, 2021, 02:55:20 pm »
Hi,

Is there a way to change the auto correct for KEYWORDS in the IDE back to the old fashion? All keywords were shifted to capitals since ... uhhh .. ages!  Just switching back and forth between 1.4 and 1.5 and I just noticed that.
I think my code is less well readable as the capitals just made the difference between text and my variables.
Hoping there is an option, ... but I don't see it!

Code: QB64: [Select]
  1. Print "Hallo 1.5"
  2. x = InStr(d$, "Childish?")
  3.  

Code: QB64: [Select]
  1. PRINT "Hallo 1.4"
  2. x = INSTR(d$, "this_rocks")
  3.  

4
QB64 Discussion / Size of compiled exe
« on: February 23, 2021, 05:45:37 pm »
Hi,

I accidentally stumbled upon a view with an old QB45 version and the recompiled QB64 program. 
Then I thought: whoaaa what a difference!  It it possible (with options) do do anything about this, or optimize it somewhere?

40 KB against 1449 KB, that's a lot!

  [ You are not allowed to view this attachment ]  

5
QB64 Discussion / Unexpected behaviour of RUN statement
« on: January 02, 2021, 10:29:27 am »
Hi,

I ran into a strange thing in my program, which after narrowing down to a piece of test code, might be a bug in the RUN statement.

In my program I am using the bottom line (locate 25,1) as status line.  This all works fine, and the printing on that line and elsewhere on screen doesn't cause screen scrolling.  In some part of the program, I can choose to restart and do this with the RUN statement, as this makes sure all files are closed and variables 'forgotten'.

After this re-RUN, the program screen starts scrolling when printing on line 23.  This isn't an issue at first run.

This small piece of code shows the issue.  First time you see a scrolling counter, and the two bottom lines are static as expected.  After re-RUN, line 24 is also used and the screen starts scrolling.  The status line (25) then also scrolls away.

I've been messing with CLS, changing to different SCREEN, making sure last print command isn't at bottom etc.
It looks like a re-RUN isn't a 100% clean restart of the program?
If you enable the GOTO Start line (jumps to line 1) the program doesn't break.  But then all garbage is not cleared ;-)

Any thoughts?


Code: QB64: [Select]
  1. Start:
  2. LOCATE 25, 1
  3. PRINT "Nice status line! @"; TIME$;
  4. LOCATE 1, 1
  5.  
  6. FOR i = 1 TO 400
  7.    PRINT i
  8.    FOR j = 1 TO 2500000: NEXT
  10.  
  11. LOCATE 12, 12
  12. INPUT "Press enter to RUN"; x$
  14.  
  15. 'GOTO Start
  17.  

6
QB64 Discussion / PRINT USING for non US numbers
« on: December 29, 2020, 05:51:27 pm »
Hi,

I wonder if it is possible to setup PRINT USING to display (large) numbers, separated with points instead of comma's.  This is common in EU and possibly other areas.

Wiki http://www.qb64.org/wiki/PRINT_USING says:
  ,.    Comma to left of decimal point, prints a comma every 3 used # digit places left of the decimal point.

This gives me 324,653,221.  if programmed with PRINT USING "##############,."; a  (and I don't need decimals here).
Stripping to PRINT USING "##############,"; a      (undocumented on wiki) makes it even better to  324,653,221

But PRINT USING "##############."; a    doesn't do the trick.

I like to see my number as 324.653.221 with PRINT USING and preferrably without coding that myself in a Function ;-)

Is this possible?


Pages: [1]