Hi very good program.
I would like to have only 3 colors to display the fractals (one color for each root).
n black color for diverging points. I wil appreciate if you can give some suggestions.
Maybe we are looking at this the wrong way.
Suppose your goal is to generate random numbers, WITHOUT replacement in the interval [0,2^200 - 1].
Yes, the odds of a collision are infinitesimal, but the point is as easily made for numbers in a smaller interval. Here I'll use 20 "digit" numbers, with each digit in base 1024.
n = 500000;
spares = 100;
B = floor(rand(n + spares,20)*1024);
Eliminate any collisions, although there essentially won't ever be any for numbers this large. Unique sorts them of course, so we now extract the number we originally wanted.
B = unique(B,'rows');
ind = randperm(n+spares);
B = B(ind(1:n),:);
Having done this, you can easily convert them into VPI numbers if you want them in a big decimal form for some reason, or simply leave then as they are. Or, suppose you wanted to use a decimal form, with bounds of [0,1e1000-1]. Here we could have used numbers with 100 base 1e10 digits. The same approach applies.
Generating a few spares is incredibly cheap here, so there is no real problem.
In fact, as long as you can factor the upper limit (+1) into a list of small primes, all of which are less than 2^53, one can always use a scheme as I have described above. The only problem is if you wanted to generate samples that lie in an interval like this:
[0, 12323242124232456456345346]
Of course, I've chosen the number 12323242124232456456345347 carefully, to be a large prime number. This is why my randint code is slow, as it allows any general upper limit. (I can certainly speed that up with some thought though, since I chose an algorithm that may not have been optimal for speed. I'll need to leave that for the future re-write.)
For this particular experiment, I'm clearly on the cusp of breaking into larger problems with a 2^60 size. Ideally my problem size gets up to 100-200 which, until now, didn't seem possible. It may not be. My problem is not in storing big integers (tried using uint64), but in manipulating them with existing functions. Much support has been added for these numbers, but many functions, like binary/decimal conversion, are limited by the 2^53 size. This is where your tools come in perfectly--if you'll recall you found me trying to convert binary to decimal with some inferior software.
I know a lot of people use this page to gripe about your software not being perfect for what they want -- I was trying to express my gratitude and contribute something that might be useful to you or someone. We're not all out to get you, John. Peace, love, and thanks for the software.
Peacefully Unforced,
Mike
While I'm happy to see that some find VPI useful, nothing forces you to use a tool that is designed to operate on numbers with hundreds or even many many thousands of decimal digits. If your goal really is nothing larger than that will fit into a 64 bit integer, then use uint64 for your operations. (Only 64 bits is amazingly small in context of the problems VPI is designed to handle.) VPI obviously cannot compete in speed with arithmetic on those numbers, as this is an issue of apples versus oranges.
One day I expect to get around to re-writing VPI, but even then I will not reasonably expect more than about 10-1 speedup in any tests I've done, and even that will force some potential compromises on my part.
Use the right tool for your problem. In this case, uint64 seems like a better choice.
Here are some stats on the big numbers. I think I will just write my code to ignore duplicates since it's not time effective to remove them. Sorting takes a little while, but I think I can work out of order just fine. So I'm good for now I think, just thought you'd be interested in some run times, and that you'd tell me if something looks off.
>> N=vpi(uint64(2^60))
>> tic,vsamples = randint(N,[500000,1]);toc
Elapsed time is 1138.346514 seconds.
>> tic, vsamplesU=unique(vsamples);toc
Elapsed time is 1811.413225 seconds.
>> tic,vsamplesS=sort(vsamples);toc
Elapsed time is 1833.296390 seconds.
I see also that unique() was contributed to the toolbox, so with only ~55 collisions per 500,000 samples, I could easily remove the duplicates using unique. I'm guessing that will be more efficient than the re-sampling approach.
Comment only