- C++ Middleware Writer - 1 Update
- Dynamic type - 1 Update
- Factory pattern and MIRSA C++ Guidelines on Dynamic Allocation - 2 Updates
- Array member initialization, gcc vs. clang - 2 Updates
- A case insensitive substring search? - 2 Updates
- Reverse Iteration Fractal Encryption... - 3 Updates
- "CppCast interview about the Oulu ISO C++ meeting" by Herb Sutter - 1 Update
- A case insensitive substring search? - 1 Update
| woodbrian77@gmail.com: Jul 06 12:05PM -0700 > for years. I claim the C++ Middleware Writer is G-d's gift to me > to save me. G-d used the ark to save Noah and I have a similar > tale to tell. Some ark news: http://www.foxnews.com/us/2016/07/06/noahs-ark-biblical-proportions-ready-to-open-in-kentucky.html?intcmp=hplnws I'm glad to hear they hired Amish people to build that. Their craftsmanship is excellent. By the grace of G-d, and with your thoughts and prayers, the same quality found in Amish work goes into the C++ Middleware Writer. Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 06 04:19PM +0100 On 5.07.2016 22:00, Cristiano wrote: > [...] > I used your solution because it better fits my original code (I already > use a class). Just an extra note: I noticed that in my axample of virtual interface I have failed to define a virtual destructor in the base class, one should always have that to avoid resource leaks or worse. Cheers Paavo |
| Mark <ma740988@gmail.com>: Jul 05 06:43PM -0700 On Saturday, July 2, 2016 at 1:13:58 PM UTC-4, Mr Flibble wrote: > As far as C++ is concerned and at its most basic level all the factory > pattern is is the calling of virtual functions. > /Flibble Do you have a reference or can you provide sample code illustrating factory design use withouth dynamic freestore-based allocation? Thanks Mark |
| scott@slp53.sl.home (Scott Lurndal): Jul 06 12:38PM >Do you have a reference or can you provide sample code illustrating factory design use withouth dynamic freestore-based allocation? >Thanks >Mark Simply add 'new' and 'delete' operator overrides to the class that the factory creates and have them allocate from a fixed length array of objects defined at compile time. Or create a pool allocator and initialize the pool at compile time. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 06 06:13AM >> struct B { int values[5] = {}; }; > hence, user provided default constructor or (not > mentioned in the error message) explicit initializer. What do you mean "explicit initializer"? The array is being initialized in both cases. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 06 09:33AM +0200 On 06.07.2016 08:13, Juha Nieminen wrote: >> mentioned in the error message) explicit initializer. > What do you mean "explicit initializer"? The array is being initialized > in both cases. Explicit initializer in the declaration of each constant. E.g., int const x = 42; // ← An explicit initializer. Cheers & hth., - Alf |
| ram@zedat.fu-berlin.de (Stefan Ram): Jun 29 05:24PM >It was always possible to use a custom character encoding, where >»SS« is represented by a single code point (character); it still >can be rendered »SS«, which is a question of I/O. And there even is a precedent for it: »"\n"« (one character), which sometimes is output as »"\015\012"« (two characters). |
| ram@zedat.fu-berlin.de (Stefan Ram): Jun 29 08:11PM >>which sometimes is output as »"\015\012"« (two characters). >But that would break the Unix-land convention for narrow streams, that >(in Unix-land) they only shuffle bytes, with no interpretation. In C++ we have 27.5.3.1.4p1 »binary« »perform input and output in binary mode (as opposed to text mode)« to shuffle bytes with no interpretation. Or, we have »text mode«, which is what I was thinking about above. However, since on input under »DOS« »\015\012« is being converted to »\n«, and then on output »\n« is being converted to »\015\012« again, a plain copy, even in text mode, would not modify the bytes »\015\012«. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Jun 29 07:49PM -0700 On 6/26/2016 8:52 AM, Peter Fairbrother wrote: > target set? (if so, please don't call it by two different names... ) > I initially thought it was the set of points which remain less than some > value after n iterations (presumably of x -> x^2 + c) - The n-th level set is the n-th node in the "tree" created by the bits in the plaintext bytes. So, if we store a byte per complex number we go down CHAR_BIT levels in the "root tree" where every left-right decision is a bit in a byte during reverse iteration. The level sets are basically the equipotential field lines of a Julia set. Here is an example rendering: https://en.wikibooks.org/wiki/Fractals/Iterations_in_the_complex_plane/Julia_set#/media/File:LCMJ_rabbit.jpg If you keep zooming out, they converge into a circle. If you zoom in, they start to flow around the highly intricate border structure of the fractal. > or possibly that > set minus the set for n-1 iterations - but I don't see how that would be > delimited by a circle. I think he means plotting the target set represented by the secret key (c), and taking the largest distance (z) gets from the origin during iteration of (c) on random data. (r) is the radius for a circle that the set is inscribed within. I will try to clarify this with Juaquin. > Can c be freely chosen from some large range? Well, kind of. Humm, these numbers are not going to be very large, but they can be very small, and describe precise Julia set locations in the Mandelbrot set. However, I have managed to store bytes in values of (c)'s that are fairly far away as well. Here are some example points, that are all valid secret key values of (c): http://colinlmiller.com/fractals/gallery.htm Many digits in these suckers, and there all VERY important! Basically, values of (c) are restricted by the level of precision used to represent them. This project would be really interesting with a bignum lib, but its still fun to pack information into floats. Here are some lower precision example points: {-1.295189; 0.440936} {-1.746695; 0.000037} {-0.74543, 0.11301} {0.0, 1.0} {0.0, -1.0} Yes, these points are mostly on the negative side of the real axes, but they contain fine grain structure, and can store data: more than a single byte. Also, you can get a finer grain point: real part = -1.985,540,371,654,130,485,531,439,267,191,269,851,811,165,434,636,382,820,704,394,766,801,377 imag part = +0.000,000,000,000,000,000,000,000,000,001,565,120,217,211,466,101,983,496,092,509,512,479,178 >> and applying inverse iteration, choosing roots >> by sign according to the bits in the sequence to be encoded. > Is that the actual encryption operation? Exactly yes. The ciphertext is the complex number result from reverse iteration. >> imaginary component of the escape orbit for each iteration. > This last part 5, decode by repeatedly iterating and taking the sign of > the imaginary parts as plaintext bits, seems like it would work. Actually, I found that Juaquin must have made an error here. So far, I can only decrypt the bits by using the sign of the real part during forward iteration. The imaginary part produces another byte value, that is not part of the plaintext, yet its definitely related in some way. I have not explored this "auxiliary" byte in any detail quite yet. Still, imho, its quite interesting. > but oh oh, what is an escape orbit? for each iteration? The escape orbit is the actual value of (z) during forward iteration. Actually, the signs and/or values of this number can be integrated into an escape condition to create many wonderful things. Pickover stalks, and my own field line escape condition work nicely: http://www.fractalforums.com/new-theories-and-research/plotting-field-lines-during-iteration/ (read all...) Ahh, well. Shi% hits the fan when one tries to store too many bits for the current level of precision. The crap arises in the from of (z) going extremely high, off to positive infinity. Or really low, if the secret key (c) was inside the non-escaping region of the set. The precision loss is apparent when you take a look at the digits of (z) during forward iteration, and compare them to the results of reverse iteration. > If you/he means the imaginary part of x, then it seems to make some sense. Humm... All of my "proof of concept" experimental code uses the real part. > But what is the imaginary component of the escape orbit of an iteration? The imaginary component of an escape orbit is the imaginary part of (z) of an iteration. > I still don't see how you get the initial ciphertext. Take a deep look at the (iterate_reverse) function in: http://pastebin.com/VsvH3HdE > Repeated reverse iterations and choosing which root to use, OK, I get > that. But how do you choose the starting point, given some > arbitrarily-chosen c? Ahhh. The starting point (z) can be very fairly far away from the origin, or it can be the origin itself. This point quickly converges into the Julia set of (c), in CHAR_BIT iterations with large (z) will still be fairly close to the set at the end. The origin point of (z) can actually plot the equipotential field when its very far away. I used a starting point of (0, 0) for my example code. Interestingly, the starting point of (z) can be random. > Assuming you can do that, as a cipher it seems to have several > disadvantages: first, it is computationally expensive. Agreed. The reverse formula is in polar form and uses square root and trig under iteration. Pretty expensive! > purposes, you need too be able to encrypt say 128 bits in a block - > there are some 64-bit block ciphers still around, but they are > deprecated, and some people say you need 256 bits in a block nowadays. Yeah. There are ways to pack more precision, but there is a limit... Go to high, and they start going out of control wrt decryption. > proof of security. > This is kinda a holy grail for some cryptologists, and if I am right > about that, it may have some limited use. I was kind of thinking along the same lines here. > Maybe if you are a chaos theorist .. > - Peter Fairbrother > ps ignore anything austinobyrne has to say - he is a well-known idiot. All that aside for a moment, well, it is still good to be friendly? :^o >> imbalance of the contractivity in the tree traversal of the >> Julia set." > ps nope, that makes no sense to me either .. It has to do with how much data the scheme can contain in a single complex number vs how big these darn things are going to actually be. AFAICT, they are related to the dimension of the fractal: https://en.wikipedia.org/wiki/Fractal_dimension I kind of boils down to the fact that we are storing single bits from basically one dimensional data (single number) into two dimensions (single number, comprised of two parts). The imaginary part takes up extra space in the ciphertext, the 2d point is bigger than the 1d point! I really need more time to work on this damn it! |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Jun 30 11:15AM -0700 I think I may have figured out a way to store two numbers in the range of -999999999999 to +999999999999, along with a byte. In addition to encrypting a byte with +- roots, we use an origin point for (z) that stores these two integers. I think the range of these extra numbers are around 6 bytes each. So, it looks like I can store 13 bytes in a single 16 byte complex number based on two 8 byte doubles. Now, this extra byte can be a random number, or hold anything we want. Humm... So, the idea is to simply set (z) to an origin point that contains actual data. This value of (z) will be restored during decryption. Here is some example data: Encrypting values: -12301, 989854412345 and 63 z = { -12301, 989854412345 } c = { -.74543, .11301 } _____________________________________ z[origin]:((-12301.000000000000000,989854412345.000000000000000) z[0]:(1) = (703510.625379827688448,703510.634121880866587) z[1]:(1) = (921.527561135795622,381.708887927776345) z[2]:(1) = (30.986873249490291,6.157379527378633) z[3]:(1) = (5.658407163514809,0.534105213067071) z[4]:(1) = (2.531946317498929,0.083156425978855) z[5]:(1) = (1.810371315513342,-0.008245152186550) z[6]:(-1) = (-1.599136856993362,0.037912687602776) z[7]:(-1) = (-0.040599543843387,0.924854139826196) Decryption: ------------------------------------------------------------ z[7]:(-1) = (-0.040599543843388,0.924854139826196) z[6]:(-1) = (-1.599136856993362,0.037912687602775) z[5]:(1) = (1.810371315513342,-0.008245152186545) z[4]:(1) = (2.531946317498928,0.083156425978872) z[3]:(1) = (5.658407163514803,0.534105213067157) z[2]:(1) = (30.986873249490127,6.157379527379598) z[1]:(1) = (921.527561135773453,381.708887927834041) z[0]:(1) = (703510.625379742938094,703510.634121970389970) z[end]:((-12301.000000000000000,989854412345.000000000000000) _____________________________________ pt:63 == db:63 This is working. BTW, I am also rounding the final numbers. This restores problems where the right number is just one digit off, but the decimal is very close like. 989854412344.789... This is experimental, but it seems to be working. Trial decrypt is very important here! ;^o |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Jun 30 01:23PM -0700 On 6/26/2016 8:52 AM, Peter Fairbrother wrote: > On 21/02/16 21:38, Chris M. Thomasson wrote: [...] > For example, what is the n-th level set? Is it the same thing as the > target set? (if so, please don't call it by two different names... ) [...] FWIW, here is an animation of the n-th level sets as anit-equipotentials: the field lines if you will. Basically the perpendicular field that can also be used to store data: https://en.wikibooks.org/wiki/Fractals/Iterations_in_the_complex_plane/Julia_set#/media/File:From_decomposition_to_checkerboard.gif Here is a fairly crude animation I made of field lines: http://funwithfractals.atspace.cc/ct_fdla_anime_test_0 (it runs a little slow on a phone...) |
| Lynn McGuire <lmc@winsim.com>: Jun 29 04:54PM -0500 "CppCast interview about the Oulu ISO C++ meeting" by Herb Sutter https://herbsutter.com/2016/06/27/cppcast-interview-about-the-oulu-iso-c-meeting/ "On Saturday afternoon, at the ISO C++ meeting in Oulu, Finland, we completed the feature set of C++17 and approved sending out the feature-complete document for its primary international comment ballot (aka "CD" or Committee Draft ballot)." Lynn |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 29 09:32PM +0200 On 29.06.2016 19:24, Stefan Ram wrote: >> can be rendered »SS«, which is a question of I/O. > And there even is a precedent for it: »"\n"« (one character), > which sometimes is output as »"\015\012"« (two characters). But that would break the Unix-land convention for narrow streams, that (in Unix-land) they only shuffle bytes, with no interpretation. Also keep in mind that in Unix-land the narrow streams are now usually UTF-8 encoded, with a variable number of bytes per Unicode code point. But I like the idea of the uppercase sharp S. I didn't know about it until your posting. Thanks! Cheers!, - Alf |
| 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