I'm multiplying several prime numbers but my products are getting too big. When I get to about 12 or 13 prime numbers being multiplied, I'm losing accuracy in the answers. I'm using Double to hold the product. Is there something bigger?
Printable View
I'm multiplying several prime numbers but my products are getting too big. When I get to about 12 or 13 prime numbers being multiplied, I'm losing accuracy in the answers. I'm using Double to hold the product. Is there something bigger?
There's nothing bigger that's natively supported. When people need larger number support, they usually store the numbers in strings (or string-like objects) and write their own arithmetic functions. There's probably an infinite-integer-precision library around here somewhere. If you're familiar with Python, that's what it uses.
Decimal datatype is a subtype in Variant. It can hold much bigger numbers. You need to use CDec() to convert a number to a Decimal.
Hi, i'm using this:
but it has limitation within the Decimal range, about 29 digit number..Code:Private Sub Command1_Click()
Dim ResultNum As Variant
ResultNum = CDec(13 ^ 14)
Text1.Text = ResultNum
End Sub
CMIIW
Have a look at this if it is relevant to your case.
Why do you need such incredible accuracy, beyond what double precision supplies? Just curious.
In building a "word game" program, I've given each word a value. The value is the product of several prime numbers. Each letter in the alphabet is assigned a prime number. e = 2, t is 3, z is 101 and is the largest. When you have a really long word that multiplies some of the larger prime numbers, (especially words with several "z"s) the product get big in a hurry.
It seems that you really do not need prime numbers multiplied to get larger numbers. Why not just use long strings of letters, randomly assigned to the strings? For example, I could easily build a string of 10,000 or so letters in length, and each letter in the alphabet would be randomly assigned to the string. Primes would be irrelevant.Quote:
Originally Posted by DroopyPawn
I need to be able to divide the value of one word by the value of another word and see if the remainder is zero. If it is, then the first word's letters are a subset of the second word's letters. (Think ANAGRAM). But I'm open to ideas other than the prime product to check for subsets of letters.
...Actually, I think I just had an idea that might work even better/faster than what I'm already trying. When I used the word "subset", it made me think of counting the letters in each word and comparing. If there are more of any specific letter in the dictionary word than there are in my word, then my word is not a subset of the dictionary word. I'll find the total of all the differences (a1-a2, b1-b2, c1-c2.....z1-z1) and if it's more than the number of blank tiles (think scrabble) then I have an anagram.
There are a number of easier ways to check for anagrams. I have to admit mapping them to primes and using multiplication is clever, and in an abstract space it's a very nice solution.
I can't take all the credit for the prime products idea but I did get it working.
The problem is that the product increases exponentially-ish. With some 13-letter (and smaller) words, it works fine. But with an 8-letter z-word, it blows up. Of course, I don't really need to know any 8-letter z-words (and I doubt that any even exist) but there are other legal words that blow up the code. It's starts returning words that simply are not subsets of the original word.
Therefore, when the prime products get really big, I need to be able to calculate them accurately. Any more ideas? Do you think the variant type would go further?
Variant wouldn't help; it would max out at the accuracy of the other data types. One simple solution (if your counting scheme didn't work for anagram checking for whatever reason) is to take a word, loop through each letter in it, and successively find and delete those letters from the other word. If the words were terribly long you'd want to sort them beforehand, but that's a non-issue for word-length words.
Doing actual string manipulations like this over a whole dictionary would take a while. If you'd like more optimized solutions I can come up with them.
My PrimeProduct idea seems to be the fastest thing I've come up with yet but it has the limitation of products being too big long words or words with less frequent letters (like Q and Z). Counting the different letters in my word and in each dictionary word returns the correct results EVERY time but runs slower.
I'm using PrimeProducts to anagram words with only letters and words with only 1 blank tile (think Scrabble). With 2 or more blank tiles, the loops are too long (a little less than 26^26 times the number of words in the dictionary. So for 2+ blanks, I use the letter counting method. With really long words, it takes about 4 seconds or less. I think I've optimized that code about as much as I can. I only have to loop through the dictionary list one time now but there are a few more calculations to do each time.
If you can come up with something better/faster, I'd love to see it.
I'm also interested in programming some wildcards for "EndsWith", "StartsWith", and "Contains". Finding words that end with "gry" is pretty simple - one time through the dictionary using right. One time though the dictionary using InStrB() will tell me all the words that "conatin 'and'". But I'm not sure how I'm going to find words that "end with gr*" or "ends with a*m" or contains "b*m", for example.
Be very careful in such situations. If you convert a number using CDec, accuracy is not guaranteed at all. Try this code:Quote:
Originally Posted by edhanz
You'll getCode:Debug.Print CDec(13) * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13 * 13
Debug.Print CDec(13) ^ 20
Debug.Print CDec(13 ^ 20)
19004963774880799438801
1,90049637748808E+22
19004963774880800000000
The explanation is simple. In the first case, you start off with decimal 13, you multiply it by integer 13, and you'll get a decimal, and so on, because this is how VB works. Start with decimals, perform additions, or multiplications, or some other simple calculations, and you'll get decimals. You don't lose accuracy.
In the second case, you start with a decimal, but then you raise it to the 20th power, and the result comes out as a double.
In the third case, you start off with a double (13^20) and you can't hope to gain accuracy by converting it to decimals.
In the end, my suggestion is: whatever you're trying to do, start off with decimals and only perform simple calculations, step by step, like I did. Only in this case won't you lose accuracy.
If I can solve the huge product problem, I'd still like to use this idea for finding anagrams of words. But, I've improved my code that anagrams with wildcards now to the point that it's fast enough to use with no wildcards too.
I'm now able to take a long word like "panthers" and add wildcards to it to get all possible anagrams in my dictionary.
Number of "*", time to fully anagram (in seconds)
1, 0.578125
2, 0.9375
3, 1.25
4, 1.515625
5, 1.71875
This is a huge improvement over my original code. It was taking more than 13 seconds to anagram moderately large words with only 2 wildcards. These times are slightly inaccurate because I was using the Windows Timer to time the code but they're close enough. The times vary by as much as 0.2 but I can live with that.
Furthermore, the issue of returning invalid words because of the inability of DOUBLE to accurately multiply large prime products is no longer an issue because the new code returns correct results every time.
You have a dictionary and are checking to see if the word you have is an anagram of something? If so, for each word you could generate a UDT which keeps track of the total number of letters in the word, and the number of each letter. Checking for anagrams using these constructs would be quite quick, and dealing with wildcards would be trivial. Optimizations are readily possible, too, using the length of each word.