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

[NOVARSEG]

It appears that DIM gig as STRING  * GIGABYTE does an initialization for the whole string to be spaces.

Anyway to do  DIM gig so that "NO INITIALIZATION OCCURS" (I know that this is a strange request)?

The essential action of DIM sets aside a memory block of bytes used for the variable that is DIMed. In QB45 you can see the memory allocation in the MAP file.

QB45 source code example.
DIM string1 AS STRING * 256

After compiling, the MAP file will show a length of 0100h in a memory segment called BC_DATA

I expect QB64 to be similar.   

128 bit variables are fast but not essential.  Try coding in 16 bit assembler and you will soon find out how wonderful and compact the code is.

Even with 16 bit assembler you are not limited to 16 bit variables. There is no limit to the number of digits after the decimal point.    128 bit math operations only do it faster.

[Richard]

Thanks @SpriggsySpriggs

As I said I am not experienced with C++ (or C etc).

I looked at some "C" forums earlier regarding math beyond 64 bits - but it seems there were no libraries available (or in progress) to handle beyond 64 bits. I did come across something about 128 bit registers (NOT cpu registers) in C, but there was mention something about problems actually using these registers to actually do some thing with (would be nice to string together a number of C++ 128 registers to do math - don't know how to do unfortunately)

Maybe I should learn how to C++ code - hate to think how long it would take me?

[NOVARSEG]

The latest Intel CPUs can do anything

[bplus]

I started looking at @bplus OHI and am a bit lost at this stage to "extract" the least code required to incorporate in my programs. (To be able to do many digits of resolution for the basics - add, subtract, multiply and divide). Has anyone previously done this?
.
Even if BPlus code is used, I will be limited - eg doing SQR, TAN, <>, arrays, input # etc would be a pain!

Here is the meat (make sure you are at Best Answer):
https://www.qb64.org/forum/index.php?topic=2921.msg121886#msg121886

Copy paste into your app and use (don't need demo code in main loop) just:
myNum$ = Mr$(StringNumber1$, operator$ (+ - * or /), StringNumber2$)  'simple call

I will be limited - eg doing SQR, TAN, <>, arrays, input # etc would be a pain!

If writing your own code routines is a pain, then yeah you are right!

Do you know about Taylor series?
Yeah it would be slower too than using professional means but aren't we hobby programmers anyway?
100 digit decimals for division but can customize with the Inverse code to 1000's or more.

Even if it's all a hack job, you have pretty good idea how your code works. ;-))

[bplus]

128 bit variable types do exist in C++

What kind of range does that give us for Integers and Floats?

And is there a way to run raw C++ code inside QB64? I think this was asked before for ASM or C but QB64 gets translated to C++ if I recall correctly?

[Richard]

@NOVARSEG
@bplus

Thanks for replies.

I admit that a "well-written", "hand crafted" , "optimized" assembly code would be the most elegant, resource efficient, fastest and possibly the easiest to understand and debug. At this stage I am not quite ready to attempt assembly programming (Intel x86 syntax) and incorporate this seaminglessly into QB64 programs. At present I would have to have a "stand alone" assembly program and "cheat" by saving and writing to a disk temp file for (assembly <-> QB64) program interchange as I cannot correctly pass data and commands between the two. Hopefully one day I will sort this out for me.

Yes I have heard about Taylor Series (and even used same) - and there were other series too (McClarens ???, etc). The "fun" starts when the Mathematical Field of "Numerical Analysis" is used (where upon many other things - an analysis is done to see how many "additions", "subtractions", etc is performed to do a certain task (and with corresponding correlation to precision/accuracy of answer at each stage). And to top this, for "certain kinds" of tasks - to use methods where a "seed" is used to "kick-off" an iteration process to rapidly converge upon the answer (when eg a predetermined accuracy say 5 decimal places is only needed). A simple example is to estimated factorial N (N!) = 1 * 2 * 3 *... (n-1) * n  if precision required is only say the most significant digit (or two) then Sterlings Approximation for factorial may be sufficient.




Now I am at a "cross-roads" - having to spread my resources over

- assembly programming (long term)
- BPlus OHI approach (maybe up and going quickly)
- GMP and similar packages (probably get lost along the way)
- Learning C++ and to use 128bit registers (learning curve for C++ to overcome)
- my approach to use _MEM tools (just starting - however _MEM expertise already available with QB64 forum members (particularly @SMcNeill)

Just a side note - although many topics/replies have been made regarding FLOAT vs LONG (double precision) - in a nutshell you "always" need more bits (80 verses 64) to get a more accurate result - one thing I noticed "missing" from all the topics I have read is actual possible "problems" with 64bit math (as performed by the Intel x64 cpu) and am not referring to it being only 64 bits. Maybe I should reply on this if anyone is interested (my reply would rely on documentation from INTEL). 

[NOVARSEG]

At 9:32 into video, there are 512 bit registers available.  Serious stuff.

[SMcNeill]

At 9:32 into video, there are 512 bit registers available.  Serious stuff.

Use the boost library for 1024-bit math/variables.  https://www.boost.org/doc/libs/1_54_0/libs/multiprecision/doc/html/boost_multiprecision/tut/ints/cpp_int.html

https://www.boost.org/doc/libs/1_76_0/libs/multiprecision/doc/html/boost_multiprecision/tut/ints/cpp_int.html

[SpriggsySpriggs]

What is the reason for needing such a large number right now?

[bplus]

What is the reason for needing such a large number right now?

What's 100! (exactly)

Public Key Cryptography comes to my mind first and playing with Number Theory.

[SpriggsySpriggs]

I highly doubt we're doing that in QB64, though. It's not really being used for any serious applications. Simple graphics demos and games.

[bplus]

And I am just talking about some of my interests (Prime Numbers included in Number Theory that lots of people like to dabble with)

Then there is also interest in precision beyond 16 decimal points and getting around Sci Notation.

[jack]

if you want to use a bignum library like GMP in BASIC then I suggest that you use another Basic compiler that supports operator overloading, it's the one that Pete hates :)
I mostly use that compiler and have written interface code that makes the use of the GMP library as easy to use as using built-in types like Integer or Double

[Richard]

@SpriggsySpriggs

As to your question on the need of such large numbers?

Initially side-stepping ...


Many, if not all, experienced QB64 developers @SpriggsySpriggs , @luke, @FellippeHeitor  et al and QB64 users may well recall the "debacle" about the Pentium Bug. These developers etc may also have contributed at the time, to workarounds such as software patches etc. For those interested refer links below.

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

https://www.techradar.com/au/news/computing-components/processors/pentium-fdiv-the-processor-bug-that-shook-the-world-1270773

The above links may be of a general reporting nature. However without reference to official INTEL publications/reports and better still with communication directly to the INTEL hardware/software engineers and contracted 3rd party research organizations involved directly at the time - the links highlight what I call as a potentially serious situation and also illustrates some commercial logistics problems (warranty, replacement, legal stuff etc).

Most people (including myself) fall into the trap of "ASSUME".

If you break up that word into ??? ? ?? (i.e. 3 words) you get the universally known phrase/sentence - "Never ASSUME because you make an ??? out of ? and ??"

Generally people assume that there are no bugs etc with computers and in particular the hardware (e.g. the processor chip itself) - although people generally accept and possibly expect bugs in software (take Windows 10 for instance).

So cutting a long story short - to check out a 64 bit division as reported by QB64 program and by which I gather that QB64 does not have original routine to perform the calculation - it just eventually relies on the say INTEL microprocessor calculating it - I will need more than 64 bits span for any technique I develop (if anything simply because of round-off errors). Similarly checking up on 80 bit division regarding FLOAT.

The above side-step (including links) is NOT my real concern - it goes deeper and more far reaching than this.

In my follow up of this reply to you I will relay to you my REAL concerns with 64 bit MATH  (actually I do not think QB64 is at fault - as it is, I gather only a messenger between the processor and the generated exe file when it comes to 64 bit math)

[George McGinn]

I can tell you that when I code scientific research projects (ie: for astronomers and physicists), numbers used in calculations and even displaying can be very large, where I may need 23+ decimals or even significant digits (or both!) for use in calculations.

Anything that displays or uses a mantissa less than that is useless to me in those cases.

Which is why I use string math routines (many I've written myself or with a programmer friend of mine). However, these too can have limitations and performance issues.

It would be nice, as for anyone who has ever needed to do math (even in R) with large numbers, after about 7 to 13 numbers, you will get garbage data, leftover from memory, that can adversely affect calculations. I say nice to have because I don't always work on projects that large, and when I do I have routines (like bplus has) that are adequate to do the job. It would be nice to have a language other than C/C++ or assembler (like BASIC) where those who do not want to learn C/C++ or assembler to have this capability.

Just my two-cents!

What is the reason for needing such a large number right now?