- n-ary roots from complex numbers... - 2 Updates
- A decent read/write mutex... - 1 Update
- storing/loading n-ary data via complex numbers... - 1 Update
| "Chris M. Thomasson" <invalid@invalid.invalid>: Apr 17 03:06PM -0700 On 4/17/2017 1:25 PM, David Brown wrote: > On 13/04/17 20:38, Chris M. Thomasson wrote: [...] > is fun and educational. Just don't be surprised when your double > precision numbers can't hold more than a couple of chars after > manipulation. So far, I can only store around 70 random bits in a complex number comprised of two 64-bit doubles, using heavy rounding. That is not that good. However, there are certain classes of data that sort of like to be stored. The tend to spiral in z^n+c. Think of zooming in on a spiral in a Julia set. They all hold data. We can store it within limit deliberately, or read it rather wildly from a random starting conditions. The fact that we can store data in the actual roots of z^n+c via (z-c)^(1/n) is just neat and very fun to me, and extremely educational: Especially when I get great feedback like this. :^) |
| David Brown <david.brown@hesbynett.no>: Apr 18 01:15AM +0200 On 17/04/17 23:53, Chris M. Thomasson wrote: > practical. However, it just might being useful in the sense of providing > security. Wrt somebody working in a niche field saying "I do not care > about the large ciphertext..." There are certainly situations in cryptography where the size of the encrypted message is of little matter. You will often use a large random key for the main data encryption algorithm, which must be fast and size efficient. The random key is then encrypted with an algorithm that must be very secure, but can be slow or space inefficient. > Love the polar form. Can you think of a fast way to add two complex > numbers together in polar form? I always have to convert them back to > Cartesian to perform the addition. Cartesian form is much easier for addition. Polar form is much easier for powers (including roots) and logarithms. Either form works fine for multiplication and division. > If this can be avoided, wrt gaining > the roots (z-c)^(1/n) from z^n+c, well, that would be great. I'm afraid not. > Converting back and forth between polar and Cartesian on every iteration > is very slow. Any more clever thoughts? :^) Yes - avoid iteration, and do the calculations directly! |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Apr 17 03:36PM -0700 On 4/15/2017 11:37 PM, Alf P. Steinbach wrote: > I'm not able to follow (grok) much of what you post, but I think, it's > somewhere on the cutting edge, and when you enjoy doing it then it's > worth doing regardless of interest. The enjoyment factor is extremely great for me! Thank you for the kind words Alf. I am thinking about how to bring about the idea of RCU to the group. So, I thought that showing a decent rw-mutex, and how to use it first would be prudent. As Bonita basically says, if one cannot use the basics (e.g., mutex, condvar, rw-mutex, ect...), they cannot be trusted to use anything else. > until they're simple to use for the average Joe Sheep, but the > techniques don't become simple until they've been used for some time, > which is where the specially interested play their rôle. ;-) Well, these type of algorithms are already in use, mainly in operating systems where the load and possibility for contention in locks is very great. Audio apps, commercial databases and games are another fertile ground for these types of exotic algorithms. Of course sharing is bad. Anytime one can gain an algorithm that does not need sharing, they should go for that first damn it! Heck, if one needs to use a mutex, that is sharing. Try to avoid that first. If one cannot, well, why not try to learn about how C++ provides the ability for code very efficient solutions to the problems at hand? |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Apr 17 03:24PM -0700 On 4/14/2017 10:45 AM, Chris M. Thomasson wrote: >> __________________________________________ > Fwiw, here are the outputs of the ct_store function I am getting from > two different compilers, MSVC and GCC: The gracious David Brown pointed out some of the major limits on this wrt storing data in the "n-ary roots from complex numbers..." thread. Well, this has a lot to do with the type of termination condition I am using here... There is not set block length. Now, the block length is variable for as soon as the ciphertext z gets decrypted, it goes up through the mapped roots and as soon as it gets close enough to the original z, it quits. Now, if anybody has played around with this, well, they have seen the error wrt the stored data not equaling the loaded data. However, if one examines the data that caused the error, its clear that the termination condition was not hit! Well, the accuracy can be increased by storing data in blocks such that the ct_load function just loads n chars and quits. It does not need to search for a termination condition in the iterates of raising z up through the root chain created by the ct_store function. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment