+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Works in Progress (https://qb64phoenix.com/forum/forumdisplay.php?fid=9)
+---- Thread: b+ String Math Update (/showthread.php?tid=924)
RE: b+ String Math Update - Pete - 04-03-2025
Wow! It's all that's and a pound-and-a-half of bananas. I'll even through in a grapefruit... because my wife really hates those.
Long enough ago it's hard for me to remember, but I thought I maxed out in multiplication at 8-digits at a time.
Pete
RE: b+ String Math Update - SMcNeill - 04-03-2025
You have 20 digits for unsigned integer 64.
9 digits x 9 digits should always be less than 18 digits. Right?
RE: b+ String Math Update - Pete - 04-03-2025
Well if we take 999999999 * 999999999 = 999999998000000001 (18-digits) so the 9 x 9 appears to be withing the type limit.
Ah, I think I see why I went with eight. I used _Integer64, which tops out at 8 x 8. While 9 x 9 works with the unsigned type. Now if folks read this and say, but the unsigned type can handle 20 digits, don't forget that the max number is: 18,446,744,073,709,551,615 so no, 10 x 10 as in 9999999999 * 9999999999 is not going to be less than that 18... max.
Pete
RE: b+ String Math Update - SMcNeill - 04-03-2025
Even an integer 64 handles up to 19 digits without problem: 9,223,372,036,854,775,807
Since 9 digits * 9 digits = max 18 digits, you'd still be able to hold the answer without overflow.
As for tracking any sort of sign.... *WHY* for goodness's sake?!
Do this:
positive * positive = positive
negative * negative = positive
positive * negative = negative
negative * positive = negative
Simple rule, settled from the beginning with your numbers and now you're only dealing with the positive values with the sign safely already stored off to the side.
3 * 3 .... positive numbers only
-3 * -3 .... negative * negative = positive so it's just the same as 3 * 3
-3 * 3 .... negative * positive = negated (3 * 3)
Either way, you're always just doing multiplication with positive values... The sign of the answer is sorted out easily elsewhere in the code.
RE: b+ String Math Update - Pete - 04-03-2025
Right usable with _integer64 and one more, 19, with _unsigned _integer64.
I think we both approached this by stripping out signs, decimal, etc.
Well, I'm stumped why I topped out my approach at 8, since signs were not an issue for me either, I could have used 9.
I would probably look into Jack's method if I ever go back to expanding on the project. Things like higher order roots really started to slow down my string calc routine. It would do them, but not as fast as online versions for those types of calculation.
Pete
RE: b+ String Math Update - bplus - 04-04-2025
It works! from years ago!
Code: (Select All)
Function mult$ (a$, b$) 'assume both positive integers prechecked as all digits strings
Dim As Long la, lb, m, g, dp
Dim As _Unsigned _Integer64 v18, sd, co
Dim f18$, f1$, t$, build$, accum$
If a$ = "0" Then mult$ = "0": Exit Function
If b$ = "0" Then mult$ = "0": Exit Function
If a$ = "1" Then mult$ = b$: Exit Function
If b$ = "1" Then mult$ = a$: Exit Function
'find the longer number and make it a mult of 18 to take 18 digits at a time from it
la = Len(a$): lb = Len(b$)
If la > lb Then
m = Int(la / 18) + 1
f18$ = Right$(String$(m * 18, "0") + a$, m * 18)
f1$ = b$
Else
m = Int(lb / 18) + 1
f18$ = Right$(String$(m * 18, "0") + b$, m * 18)
f1$ = a$
End If
For dp = Len(f1$) To 1 Step -1 'dp = digit position of the f1$
build$ = "" 'line builder
co = 0
'now taking 18 digits at a time Thanks Steve McNeill
For g = 1 To m
v18 = Val(Mid$(f18$, (m - g) * 18 + 1, 18))
sd = Val(Mid$(f1$, dp, 1))
t$ = Right$(String$(19, "0") + _Trim$(Str$(v18 * sd + co)), 19)
co = Val(Mid$(t$, 1, 1))
build$ = Mid$(t$, 2) + build$
Next g
If co Then build$ = _Trim$(Str$(co)) + build$
If dp = Len(f1$) Then
accum$ = build$
Else
accum$ = add$(accum$, build$ + String$(Len(f1$) - dp, "0"))
End If
Next dp
mult$ = accum$
End FunctionRE: b+ String Math Update - Dragoncat - 04-04-2025
I am talking about base conversion though that HAS to be done a digit at a time well except for the decimal base 10 math stuff I am tired I need to sleep where can I get the latest string math librarys for arbitrary presiscion and I'll sleep on it I am dead tiredd
RE: b+ String Math Update - Dragoncat - 04-04-2025
(04-02-2025, 01:35 PM)bplus Wrote: Man! using 2 digits for one so you can do different bases blows my mind! How in the world.... !?!?
I do have code somewhere for converting decimal to any base using one symbol for going beyond 9 for digits eh the alphabet but you do run out of symbols to act as digits pretty quick.
2 digits ???
how 'bout 2 lines to rep one digit you can start to stack symbols over symbols.
Oh I know use an array() and index so you wont even be limited to 2 digits!!!
However big your array is how many symbols you can use!
BTW what would the purpose be for a huge base like 1K of symbols, base 1024 ?
Would that help speed up our string math?
I don't know probably not
the conversion time would slow it down a bit
CHARACTER SET? CHINEESE has a lot of character!! maybe you or I can encode chinese just for fun and challenge? 430 characters might not encode all of chinese but the 430 most common chinese chars mig alow you to comunbucate litttle better? with a chineese?
RE: b+ String Math Update - SMcNeill - 04-04-2025
(04-04-2025, 06:42 AM)Dragoncat Wrote: I don't know probably not
the conversion time would slow it down a bit
CHARACTER SET? CHINEESE has a lot of character!! maybe you or I can encode chinese just for fun and challenge? 430 characters might not encode all of chinese but the 430 most common chinese chars mig alow you to comunbucate litttle better? with a chineese?
You don't need Chinese. Just use regular numbers.
Let me illustrate simply:
00 = 0
01 = 1
02 = 2
03 = 3
04 = 4
05 = 5
06 = 6
07 = 7
08 = 8
09 = 9
10 = 10
11 = 11
12 = 12
13 = 13
14 = 14
15 = 15
The above is a perfectly valid hexadecimal representation. Now, sure, we're used to seeing it as 0-F, but the above is just as valid. Let's compare it for quick instance:
1515 -- This is the value for 255. Normally we'd see it as FF, but there's nothing in the world wrong with representing it this way. What we have is: (15) * 16 ^ 2 + (15) * 16 ^ 1 = 255
0000 -- This is 0.
0100 -- This is 16.
0200 -- This is 32.
0210 -- This is 42.
It's perfect valid base 16-math representation.
So that said, we can also do the same for base-1000 math.
000 = 0
100 = 100
999 = 999
So:
100 000 = 100,000
003 = 3
097 = 97
097 097 = 97,097
This is perfectly acceptable base-1000 math.
Note, however, that you can't just write a value without leading 0s.
1 -- this is an invalid syntax. We don't have enough digits to know what to do with it.
11 -- this is why that's an invalid syntax. If 1 above is 1, then would 11 be 2 instances of 1, or is it an instance of 11? There has to be a natural separator to tell you what it is. Leading 0's are important so that you can track proper base position.
001 = 1
011 = 11
See? With the above, there's no ambiguity. For my base-1000 math, all my numbers are represented by "3-number symbols".
That's all you need to represent any level base math that you want in the world. Sure, later you might substitute some chart to associate symbols to it, but those aren't needed. Saying 10 = A, 11 = B, 12 = C... isn't any more representative of your math base than just saying 10, 11, 12...
1515 is just as much hex for 255 as FF would be.
You don't have to go all funky symbols to represent those values. Plain numbers work just fine.
RE: b+ String Math Update - Dragoncat - 04-11-2025
yes I understand that, thanks I just wanted it to be "compact"
I guess we can just use numbers 0000 through 9999 say 4 digits of decimal numbers for bases 2 to 10000?
it can be in a string form for storage then extracted into some variable for manipulations / calculations?