v1.5 128 bit (and beyond) math *** COMPILER ERROR ***

[SpriggsySpriggs]

@madscijr
A number of forum members would welcome the feature of an immediate window, but despite request for same it would seem it is not going to happen with the developers.
...
I have never used any version of MS Office or accessories etc but in MS PDS 7.1 (30 year old BASIC) it still has very important and useful features (such as immediate window, etc) which despite calls is still lacking in QB64.

@Richard I think people fail to see how absolute a nightmare this would be to code. However, if you feel up to the challenge, please feel free to visit the GitHub and contribute.

[Richard]

@SpriggsySpriggs

Thanks for your reply.

I appreciate how to have an immediate window can be a huge effort - it was done 30 years ago in BASIC (probably then a much huger problem to achieve because of hardware/software limitations - making the whole program fit and work within 640Kbytes memory in MS PDS 7.1). To the best of my knowledge, PDS 7.1 was written in assembler and not by a "high-level language such as C etc.

A prerequsite to contributing say via GitHub I gather would be a thorough understanding of C++ (because of the self-compiling nature of QB64). I am not familiar with C++ (or C - probably could not tell the difference between the two).

I gather that it would not be possible/practical to contribute using QB64 basic code (correct me if I am wrong) - so I am stuck learning C++. My knowledge of C (C++) is what @SMcNeill mentioned in some replies and essentially your replies to others regarding of meanings of syntax.  I suppose, since I have been programming in BASIC many years, my greatest problem is C++ Syntax (BASIC is so very easy to "read" and understand).

So to get me started off - would you be kind enough to enlighten me on the correct way to syntax a C++ code for the following fundamentals (if there is more than one way please advise also):-

How to "comment' an existing or new line (also for a contiguous block of comments)

How to "label" an existing line  (eg to have a "line number" and the characters allowed for label and total length permitted for label)

How to "GOTO" (linenumber or label)

How to "CALL"

What I initially had in mind was using the latest development build (and repository of stable version) to "Add comments and line labels quite extensively" with notes I make as I try to understand the methodology of QB64. Over time, as the notated code is updated, to auto-self-recompile QB64 (in theory QB64 should still work exactly as before (comments and line labels should not change anything). When I think I have some snippets ready to try or test - insert into code with new notes and recompile (this would only be for me personally - too much can go wrong (almost guaranteed) to risk putting into GitHub.

IF I can get something going or has potential and needs some help - contact the forum for advice. It may never be that I directly change the GitHub repository (since I do not have enough proven experience) - but IF I can get something to work on my code, then to forward ALL code changes (and comments etc) to the forum (or say you) - keeping in mind what I produce may well end up breaking something else in QB64.

For a long time I was thinking about "changing/improving" QB64 (for the benefit of all) - but the C++ part of it was "my excuse" for not going anywhere (because on my lack of knowledge of C++). I did try looking at some C forums but did not seem useful for a beginner like me. In contrast, there were many BASIC forums (going back way long ago) being more friendly for beginners.

If anyone knows if there is a C++64 forum or similar along the lines and helpfulness of QB64 - please advise.

[madscijr]

@madscijr

Regarding your reply #130 (this thread)

A number of forum members would welcome the feature of an immediate window, but despite request for same it would seem it is not going to happen with the developers.

If you refer to the following replies from me:-

https://www.qb64.org/forum/index.php?topic=3947.30  see reply #34

https://www.qb64.org/forum/index.php?topic=1839.msg110823#msg110823 see reply #2

https://www.qb64.org/forum/index.php?topic=2276.msg116118#msg116118 see reply #8

I had experimented with dual instances of QB64 to simulate TRON-TROFF, breakpoints, watchpoints etc (from very old BASIC days) - and in principal an "immediate window" within the program (i.e. second instance BLOATED program) may, with care, give useful capability comparable to a true intermediate window. It is "messy" but with programming care it can be automated into programs (i.e. BLOAT original program (in instance #1), auto-insert TRON-TROFF flags, breakpoints, watchpoints, immediate window sort-of capability, logs, parsing original and replace with alternative code, etc. - and then UNBLOATING to recreate the original program after debugging/developing (in instance #2))

Of course, a cheap and nasty solution is to simply open up a "new instance" of QB64 to quickly test a snippet of code but of course it may not be so convenient in many cases because certain events/values may be required beforehand.

I have never used any version of MS Office or accessories etc but in MS PDS 7.1 (30 year old BASIC) it still has very important and useful features (such as immediate window, etc) which despite calls is still lacking in QB64.

For me, I may apply this technique (in the BLOATED program) to in  "parallel" with the math code of instance #1, simultaneously check all calculations etc with 128 bit computations and auto-insert relevant comments generated by instance #2 into the instance #1 (UNBLOATED) program.

Thans for the thoughtful and detailed response. All that seems like going through a lot more trouble than it's worth, without really getting the benefits of the immediate window - the ability to run commands and print values in realtime, in the scope of the immediately running program's current breakpoint, with access to the current program state.

As is, if you want to see the values at a given point in your program, you can do something like

Code: QB64: [Select]

1. $CONSOLE
2. _DELAY 4
3. _CONSOLE ON
4. ...your code...
5. _ECHO "my value=" + _trim$(str$(myvalue))
6. ...more code...
7. input "press enter to continue";in$
8. _CONSOLE OFF
9.  

(thanks to @SpriggsySpriggs for the tip)
or you can just write values and debug info to a log file.

But a true immediate window would behave like MS Office where you can step through your program and run code against the current state, kind of like how the command prompt works in Python.

Maybe it could be accomplished as part of an alternative IDE? I know people have talked about making a GUI IDE, that behaves more like a standard Windows (or Mac, or whatever flavor of Linux) app, with the more modern GUI controls, behaviors, keyboard shortcuts, etc.

[Richard]

I tested my test 128bit code in  both

v1.51 03bb0db    and      v1.51 2198409    dev builds and get the same message below for both:-

Compiler error (check for syntax errors) (Subscript out of range:9-12075)




Running the exact same test code in QB64 v1.5 (stable release) does not result in any error message (and the program runs as expected).

If the above message refers to line 9 this does not make sense as lines 8, 9, and 10 are either blank lines or a commented line.

The IDE for both dev builds does not indicate any errors.

Any suggestions on what is going on - my test code is using CONST, DIM SHARED and a lot of _MEM stuff (if that helps for suggestions)?

I repeat that no problems occur with the v1.5 stable release (Windows x64).

[SpriggsySpriggs]

The compiler issue has been discussed in other threads. We've been looking into it.

[Richard]

@SpriggsySpriggs

OK - will change my default QB64 back to stable build v1.5.

[George McGinn]

@SMcNeill, Sorry, I missed this post and felt a response to clarify was in order:

First, I never said that the TechBASIC results were correct. That came from a program I use to test number inaccuracies. I have this code written in C, various BASIC dialects, R, Python, FORTRAN, COBOL, and Assembler (NASM). And the program tests more than what I showed (that is a small part of it).

EDIT: I was reminded that powerof in Python is ** and not ^ (I've been coding in BASIC for a while I forgot). Anyway, my results are now: 5869713600000.0, which matches QB64. However, it looks like the conversion out of exponential numbers is only providing 8 significant digits, and we are losing the rest.

QB64 also isn't giving the correct answer either, because of how it (and many other languages for that matter) handles exponents, mantissa's, etc. Most of this is a limitation of either the hardware or the underlying bytecode that is used to create QB64 (in this case, C++).

I ran the same equation in IPYTHON (screen print attached) just to show you how different the results are, depending on the language.

I get  97828577532.0 vs QB64's 5869713600000 vs TechBASIC's 5869713489920.

Even when I ask Python to calculate all FLOAT, I get the same results.

In [3]: print(float(((186000 * 60 ^ 2) * 24) * 365.25))                                               
97828577532.0

In fact, I get less significant digits using Python than any BASIC interpreter/compiler!

Here is the real speed of light (it is more than 186,000 mi/sec):

The speed of light in imperial units and US units is based on an inch of exactly 2.54 cm and is exactly

    299792458 m/s × 100 cm/m × 1/2.54 in/cm

which is approximately 186282 miles, 698 yards, 2 feet, and 5 inches per second (Or accepted as 186282.397).

The numbers used and the formulas used are just to test how accurate (precision) the mantissa and exponential calculations are.

  [ You are not allowed to view this attachment ]  

Why does the techbasic on the ipad print the wrong answer? 

((186000 * 60 ^ 2) * 24) * 365.25 = 5869713600000 (at least according to both google and my windows calculator, which is what I lazily used to check results), which is what QB64 gives us.  The screen shot of your ipad is showing the result as 5869713489920.

I must be missing something here, as it seems QB64 is giving us the correct answers while the mobile device screenshot you posted isn't.

[Richard]

@GeorgeMcGinn

If I may further confuse the issue -  referring to

https://www.unitconverters.net/length/inches-to-mm.htm

  [ You are not allowed to view this attachment ]  

So in 2019 the metre has been re-defined based on changes made to the definition of a second - should I take it that the inch conversion, being defined by that 25.4 conversion factor, prior to 2019 is not the exact same quantity of physical length "distance" as to from 2019 onwards?

If this is so, calculations involved sending a probe to the planet Pluto (yes I still call it a planet) made prior to 2019 may be out by a few feet when the same calculations are done after 2019. Not that it really matters, since the mission success rate is questionable for such great distances :)

[NOVARSEG]

from https://en.wikipedia.org/wiki/2019_redefinition_of_the_SI_base_units

Previous definition: The second is the duration of 9192631770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom.
2019 definition: The second, symbol s, is the SI unit of time. It is defined by taking the fixed numerical value of the caesium frequency ΔνCs, the unperturbed ground-state hyperfine transition frequency of the caesium-133 atom,[40] to be 9192631770 when expressed in the unit Hz, which is equal to s−1.
The second may be expressed directly in terms of the defining constants:

1 s =
9192631770
/
ΔνCs
.

[Richard]

@NOVARSEG

Yes, if you are equivalently rearranging an "equation" to derive a time standard, you can come up with a non-changed assignment to be used as a standard (and that in itself may never change).

I suppose the "real problem" is how to obtain reproducibility in practice.

Take for example the scientific experiment conducted many years ago (I think it was about something like does time change when traveling at different velocities, and for that matter is the speed of light an absolute constant or does it vary say when light is "launched" from a moving source). Briefly the experiment involved two sets of "portable atomic clocks" (they may have  been refrigerator sized units) and were probably "claimed to have been synchronized to each other". These were placed on to I think "domestic airlines" travelling in opposite directions with scientists accompanying - the objective I think was to see if there were any time differences... All that I ever heard further was that "it would take many months to analyze the results". (Never did find out what the "answer" was).

A more recent "interesting" experiment was to do with the detection of so-called gravity waves. Totally forgotten on the measuring methods used but what I vaguely recall afterwards was that the manufacturer of the components used for the experiment was changing the device specifications and effectively throwing in  "adjustment factors" to increase sensitivity. So by conveniently "ignoring noise and random events" one could conclude they have found gravity waves.

In general, to me it seems that when when the definitions change for a standard - there is no statement from those in the know  as to how a "before" and "after" definition change affects things - so if you had a "metre length" from "before" and placed beside from "after", can it be shown that both are the same length (to the best experimental accuracy techniques). Can an atomic clock be sure to always "tick" correctly - in particular never miss a beat or worse still, never have time phase changes for the transition "ticks".

So to summarize, with definition changes, an inch from a while ago may not be exactly the same as an inch from today (may be 99.9999% similar) and without ultra high certainty/precision, life becomes difficult because of propagation of errors.

[luke]

There is no need to use floating point maths at all for the above calculation.

18600 * 60^2 * 24 * 365.25 = 18600 * 60^2 * 24 * (365 + 1/4) = 18600 * 60^2 * 24 * 365 + (18600 * 60^2 * 24) / 4.

The expression being divided by 4 is obviously a multiple of 4 (24 = 6 * 4), so the division is exact. You can now evaluate the entire thing with nay but integers in sight.

But in any case, I'm failing to detect any actual problem among your messages.

[George McGinn]

@Richard, my post mentions CENTIMETERS where yours is in MILLIMETERS.

The results are the same (25.4mm = 2.54cm) when comparing distances.

EDIT: Converting distance by time is tricky due to time dilation, among other factors. It isn't as simple as made here. (See: https://opentextbc.ca/universityphysicsv3openstax/chapter/time-dilation/)

@GeorgeMcGinn

If I may further confuse the issue -  referring to

https://www.unitconverters.net/length/inches-to-mm.htm

  [ You are not allowed to view this attachment ]  

So in 2019 the metre has been re-defined based on changes made to the definition of a second - should I take it that the inch conversion, being defined by that 25.4 conversion factor, prior to 2019 is not the exact same quantity of physical length "distance" as to from 2019 onwards?

If this is so, calculations involved sending a probe to the planet Pluto (yes I still call it a planet) made prior to 2019 may be out by a few feet when the same calculations are done after 2019. Not that it really matters, since the mission success rate is questionable for such great distances :)

[bplus]

5,878,625,370,000 miles
In a vacuum, light travels at 670,616,629 mph (1,079,252,849 km/h). To find the distance of a light-year, you multiply this speed by the number of hours in a year (8,766). The result: One light-year equals 5,878,625,370,000 miles (9.5 trillion km).May 31, 2019

Code: QB64: [Select]

1. Print "Light year miles:"; 670616629.0 * 8766
2. Print "Light year miles:"; 670616629&& * 8766

Needs the && on the big number or .0

[Richard]

@SMcNeill

Regarding free memory available...

Is there a limit, if you compile with the 64-bit version of QB64?  I guess if you max out ram + hard drive usage, but that’s either one massive program or one helluva memory leak!

On my setup with 32 GByte memory (of which 10 GByte is configured as a RAM drive) with Windows 10 x64 - for my 128bit Math Code Project...

In my case it is critical that calculations are completed within a 3-day computer run session (it does not matter how many times I retry a 3-day session, just can not take longer than 3 days per run). So to this end I am evaluating various coding methods to be "time efficient" and so trying out _MEM type stuff ranging from BIT to INTEGER64 with associated timing comparisons. Because of the size of numbers and the method used to process same - I need to be mindful of how much memory is available, as my estimation for memory use is far from perfect (partly because I do not fully understand how Windows 10 allocates memory). So to avoid running into "Out of Memory" errors at run time - the reason for monitoring Free Memory Available.

As I wanted to investigate the practicality of using _UNSIGNED _BIT variables it was important to establish if a BIT array would always pack 8 bits per byte into memory (the ideal case) or if a byte was used for each bit. Below is my test program (based on @moises1953 code)

Code: QB64: [Select]

1. TYPE MEMORYSTATUSEX 'MemStat
2.     dwLength AS LONG: dwMemoryLoad AS LONG: ullTotalPhys AS _UNSIGNED _INTEGER64
3.     ullAvailPhys AS _UNSIGNED _INTEGER64: ullTotalPageFile AS _UNSIGNED _INTEGER64
4.     ullAvailPageFile AS _UNSIGNED _INTEGER64: ullTotalVirtual AS _UNSIGNED _INTEGER64
5.     ullAvailVirtual AS _UNSIGNED _INTEGER64: ullAvailExtendedVirtual AS _UNSIGNED _INTEGER64
6. END TYPE
7. DECLARE CUSTOMTYPE LIBRARY 'Memory Information using KERNEL32
8.     FUNCTION GlobalMemoryStatusEx& (Mstat AS MEMORYSTATUSEX)
9. END DECLARE
10. DIM MemStat AS MEMORYSTATUSEX: DIM Result AS LONG: Result& = 0: PRINT: PRINT: COLOR 7
11. MemStat.dwLength = LEN(MemStat)
12. Result = GlobalMemoryStatusEx&(MemStat): before&& = MemStat.ullAvailPhys
13. PRINT "Free phys mem"; USING "##,###,###,###"; before&&;: COLOR 14:
14. h& = 799999999: DIM h~`(0 TO h&): PRINT " DIM h~`(0-"; LTRIM$(STR$(h&)); ")";: COLOR 7
15. FOR hh& = 0 TO h&: h~`(hh&) = 1: NEXT
16. Result = GlobalMemoryStatusEx&(MemStat): after&& = MemStat.ullAvailPhys
17. PRINT USING "##,###,###,###"; after&&;: COLOR 10:
18. PRINT " delta=";: PRINT USING "###,###,###"; before&& - after&&: END
19.  

The results for various numbers of bits (as multiples of 8 bits) as in a BIT array versus free memory loss due to the creation of the BIT array is below


  [ You are not allowed to view this attachment ]  


So trying to appreciate how Windows 10 allocates memory, from the larger of sizes of the BIT array it would sort of suggest to me that 8bits (in a BIT array) are packed into a byte.  Of interest if I try to have a BIT array (0 TO 7999999999) i.e. 8 Giga bits I get an out of memory error at run time (even though I have (32 - 10) GBytes ram still available for system memory.
 




As a side note I have problems with trying to use BIT stuff, e.g. consider the statement


DIM m1 AS _UNSIGNED _BIT * 56: m1 = 0   ' this line is line... as below

looking at the number after "*" the results (IDE error)

'*  56  OK
'*  57  Compiler error (check for syntax errors) (Reference:9-21340) on line ...
'*  58  Cannot create a bit variable of sie >24 bits on line ...
'* 100  Too many characters in number after * on line ...

it would have been nice to have say DIM m1 as _UNSIGNED _BIT *1024 ' or much bigger - so I am confused with the results above.


Also, unless I am doing something wrong (quite possible), I cannot seem to be able to do something like

MEMGET m, m.offset, h~` ' i.e. any reference to a BIT variable


Similarly, trying to be fully versatile with _MEM stuff (experimental trials by me) I also have problems such as



z~%% = MEMNEW(1)::::::::: z~%% = 0 '                      1 bytes for ~%%

'In file included from qbx.cpp:2216:
'..\\temp\\main.txt: In function 'void SUB_L1_INITIALIZATION()':
'..\\temp\\main.txt:3112:59: error: cannot convert 'mem_block' to 'unsigned char' in assignment
' *_SUB_L1_INITIALIZATION_UBYTE_Z=(func156=func__memnew( 1 ));
'                                                           ^
'compilation terminated due to -Wfatal-errors.





z~% = MEMNEW(2)::::::::: z~% = 0 '                      2 bytes for ~%

'In file included from qbx.cpp:2216:
'..\\temp\\main.txt: In function 'void SUB_L1_INITIALIZATION()':
'..\\temp\\main.txt:3112:62: error: cannot convert 'mem_block' to 'short unsigned int' in assignment
' *_SUB_L1_INITIALIZATION_UINTEGER_Z=(func156=func__memnew( 2 ));
'                                                              ^
'compilation terminated due to -Wfatal-errors.


So far I think I am OK with the other variable types possibilities in the above scenarios.

Many thanks again for your informative tutorials (videos) on _MEM and my 128bit Math Code Project (NOT in competition with other forum members, or your C library link, etc) is my first application of _MEM with encouraging results (though slow at present).

Please supply any comments you may have  regarding above.

[NOVARSEG]

@Richard

Some basic MEM stuff

Should be able to do math calcs with 3 separate memory blocks.  The first 2 block can be the 2 variables to divide / multiply etc

The 3rd 2048 bit memory block is for final results .It can be made as large as you want etc.   The correct offsets need to used.

 MEM  does not support _UNSIGNED _BIT

Code: QB64: [Select]

1. DIM Byte1 AS _UNSIGNED _BYTE
2. DIM Byte2 AS _UNSIGNED _BYTE
3. DIM Byte3 AS _UNSIGNED _BYTE
4.  
5. DIM m1 AS STRING * 128 '1024 bits
6. DIM m2 AS STRING * 128 '1024 bits
7. DIM m3 AS STRING * 256 '2048 bits
8.  
9. DIM mm1 AS _MEM
10. mm1 = _MEM(m1)
11.  
12. DIM mm2 AS _MEM
13. mm2 = _MEM(m2)
14.  
15. DIM mm3 AS _MEM
16. mm3 = _MEM(m3)
17.  
18. Byte1 = _MEMGET(mm1, mm1.OFFSET, _UNSIGNED _BYTE)
19.  
20. Byte2 = _MEMGET(mm2, mm2.OFFSET, _UNSIGNED _BYTE)
21.  
22. _MEMPUT mm3, mm3.OFFSET, Byte3