colejhudson/annotated_manelbrot.c

## annotated_manelbrot.c
#include <unistd.h>

float fractal_scale=0.075;
float fractal_vertical=2.1; // Vertical positioning of the fractal within the actual characters
float fractal_left_padding;
float r, O, l, I;
int _;
int display_horizontal_length = 150 ; // Seem to be related to the horiztonal size
int display_vertical_length = 8000; // Seems to be related to the display_vertical_length size

void main() {
  for(;
      // display_vertical_length mod display_horizontal_length means display_horizontal_length will never be bigger than display_vertical_length

      // The '(stmt, stmt), stmt' format returns the last stmt, see https://stackoverflow.com/questions/52550/what-does-the-comma-operator-do

      // The '-=' operator, when changed to a '+=' operator, seems to shift or pad (I'm not sure how to distinguish, maybe by changing the 'display' size),
      // the entire fractal upwards. That is shift up or bottom padding.
      display_vertical_length % display_horizontal_length || (fractal_vertical -= fractal_scale, fractal_left_padding = -5), display_vertical_length;

      // The constant number 15 seems to scale the fractal itself, on a log like scale, since the outter portions are most affects and
      // the inner portions the least
      15 -

        // The value of r seems to determine an inner log scale, such that when I change the assignment operator '=' to '+=', the null space of the fractal
        // is condensed and encroached upon by the rest of the fractal.

        // When I change the '*' sign in assigning to r, instead of forming a geometric shape, each of the letters is almost categorized. A way to check this
        // would be to see if it has much to do with the cyclic group - formed(?), referenced(?), implied(?) - from display_vertical_length mod display_horizontal_length

        // Flipping the comparison operator to '>' or the op '>=' does nothing of note so far as I can tell

        // Changing the assignment of l from '=' to '+=' seems to act in the same direction that swapping the assignment operator for 'r' did, that is,
        // it 'squishes' or 'compresses' the visiaul output of the fractal. Except whereas for r the squish occured as if a person were pushing in from
        // the left and the right, for l the squish is like someone pushing from top and bottom torwards the center.

        // When I multiply the value assigned to r, O * O, by any positive integer I seem to 'zoom out'. But, when I divide by a positive integer it seems
        // that I both 'zoom in' AND compress torwards the center from the left and the right. This suggests that when I was 'zooming out' I was also stretching
        // the visual output of the fractal. Curiously, at the extremity of 'zooming out', the fractal outer parts dont move in size, although the inner part does
        // move quite a bit. Although, this does keep with my prior that the fractal is exhibiting 'log-scale'-like scaling properties, not to mention, it is a
        // fractal.
        ( r = O * O) < ( l = I * I)

        // The '_' variable represents characters because when you change the '++' operator to the '--' operator, symbols unknown by the computer
        // are printed. Manipulating any part of the following expression just causes display output to totally malfunction.
        | ++_ == display_horizontal_length

        // If I change the '--' of display_vertical_length then the loop becomes endless.

        // Interestingly, if you add a '++' operator to the _ variable you get an evenly scaled zoom. Wait, no you don't you're just iterating one
        // character further. That is: same territory, different map.

        // Changing the value 6 in the mod operator seems to regulate 'noise', that is when I changed it to 1, the display became simple, or maybe
        // just very zoomed out. But I would expect to see complementary behavior when I make the value high, say 10, and while the output does become
        // chaotic, it doesn't become more zoomed in. It's important to remember that we're modding the _ variable, which is used for determing which
        // characters to print via character codes - 0-51 and so on - so we're categorizing into equivalence classes of remainders which means that we
        // cap the value outputted by the ternary operation, if true, otherwise 6.

        // ssize_t write(int fd, const void *buf, size_t count);
        // The following write syscall is writing to stdout, one character which is selected by the procedure added to the string. For example
        // write(1, "TE", 1) => T, and, write(1, 1 + "TE", 1) => E

        // Thus we must be modding by 6 because 'World!' is 6 characters long. It's important to note that the behavior of the output is such that
        // you only start seeing a lot of '!' characters torwards the middle. So, it must be that the operator '_ < display_horizontal_length', is
        // indicating something about how close _ is to the center of the display, or maybe the fractal? The outter most expression is indicating
        // when we are at the center and as such should print spaces.

        // That is, as we iterate and decrease the value of display_vertical_length to 0, we output the equivalence class each number falls into
        // in terms of its remainder mod 150,
        && write(1, (--display_vertical_length % display_horizontal_length ? (_ < display_horizontal_length ? --_ % 11 : 11) : 12) + "HelloWorld! \n", 1)

        // _Really_ interesting behavior occurs when you change the 0 in the assingment below to 1, 2, or -1. It seems I'm causing a whole new mathematical structure
        // to be displayed, but the output looks vaguely like a zoomed out version of the earlier fractal. And, by the time I use the integer 2, I get uniform plain
        // output with no features to note whatsoever. It's almost as if I'm adding or removing dimensions which lends to the complexity of the object. I'd have to
        // review my fractal knowledge. Whereas all the earlier adjustments felt like I was feeling the same part of the elephant from differing angles, upside down, etc,
        // this feels like a whole other part of the elephant.

        // Changing, getting rid of, or scaling the divisor to extermity changes absolutely nothing from what I can tell from the output.
        // Ditto for multiplication, addition, mod, and subtraction.
        && ( O = I = l = _ = r = 0, (fractal_left_padding += fractal_scale))) {
    // Changing the constant to multiple here again caused that log-y like squishing

    // Adding or subtracting the vertical positioning seems negligible as having any effect on the fractal, EXCEPT, that if you don't do either you completely
    // fuck up the output. Not sure if I'm still looking at the same map, territory, or gibberish.

    // OOOooo, changing addition to subtration in the last expresion, first operator, causes the fractal to be reflected 180 deg, AND, changing subtraction
    // to addition in the last expression, second operator, caused the fractal to become a diamond. Loss of randomness? Complexity? The fractal was already in the
    // vague shape of a diamond insofar as it would fit in one overlayed, so theirs definitely a mathematical explanation, as opposed to programming mishaps (which are
    // only incidentally mathematical in this case).
    O = I * 2 * O + fractal_vertical, I = l + fractal_left_padding - r;
  }
}

## original_mandelbort.c
#include <unistd.h>
float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<L?--_
%6:6:7)+"World! \n",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;}
	#include <unistd.h>

	float fractal_scale=0.075;
	float fractal_vertical=2.1; // Vertical positioning of the fractal within the actual characters
	float fractal_left_padding;
	float r, O, l, I;
	int _;
	int display_horizontal_length = 150 ; // Seem to be related to the horiztonal size
	int display_vertical_length = 8000; // Seems to be related to the display_vertical_length size

	void main() {
	for(;
	// display_vertical_length mod display_horizontal_length means display_horizontal_length will never be bigger than display_vertical_length

	// The '(stmt, stmt), stmt' format returns the last stmt, see https://stackoverflow.com/questions/52550/what-does-the-comma-operator-do

	// The '-=' operator, when changed to a '+=' operator, seems to shift or pad (I'm not sure how to distinguish, maybe by changing the 'display' size),
	// the entire fractal upwards. That is shift up or bottom padding.
	display_vertical_length % display_horizontal_length \|\| (fractal_vertical -= fractal_scale, fractal_left_padding = -5), display_vertical_length;

	// The constant number 15 seems to scale the fractal itself, on a log like scale, since the outter portions are most affects and
	// the inner portions the least
	15 -

	// The value of r seems to determine an inner log scale, such that when I change the assignment operator '=' to '+=', the null space of the fractal
	// is condensed and encroached upon by the rest of the fractal.

	// When I change the '*' sign in assigning to r, instead of forming a geometric shape, each of the letters is almost categorized. A way to check this
	// would be to see if it has much to do with the cyclic group - formed(?), referenced(?), implied(?) - from display_vertical_length mod display_horizontal_length

	// Flipping the comparison operator to '>' or the op '>=' does nothing of note so far as I can tell

	// Changing the assignment of l from '=' to '+=' seems to act in the same direction that swapping the assignment operator for 'r' did, that is,
	// it 'squishes' or 'compresses' the visiaul output of the fractal. Except whereas for r the squish occured as if a person were pushing in from
	// the left and the right, for l the squish is like someone pushing from top and bottom torwards the center.

	// When I multiply the value assigned to r, O * O, by any positive integer I seem to 'zoom out'. But, when I divide by a positive integer it seems
	// that I both 'zoom in' AND compress torwards the center from the left and the right. This suggests that when I was 'zooming out' I was also stretching
	// the visual output of the fractal. Curiously, at the extremity of 'zooming out', the fractal outer parts dont move in size, although the inner part does
	// move quite a bit. Although, this does keep with my prior that the fractal is exhibiting 'log-scale'-like scaling properties, not to mention, it is a
	// fractal.
	( r = O * O) < ( l = I * I)

	// The '_' variable represents characters because when you change the '++' operator to the '--' operator, symbols unknown by the computer
	// are printed. Manipulating any part of the following expression just causes display output to totally malfunction.
	\| ++_ == display_horizontal_length

	// If I change the '--' of display_vertical_length then the loop becomes endless.

	// Interestingly, if you add a '++' operator to the _ variable you get an evenly scaled zoom. Wait, no you don't you're just iterating one
	// character further. That is: same territory, different map.

	// Changing the value 6 in the mod operator seems to regulate 'noise', that is when I changed it to 1, the display became simple, or maybe
	// just very zoomed out. But I would expect to see complementary behavior when I make the value high, say 10, and while the output does become
	// chaotic, it doesn't become more zoomed in. It's important to remember that we're modding the _ variable, which is used for determing which
	// characters to print via character codes - 0-51 and so on - so we're categorizing into equivalence classes of remainders which means that we
	// cap the value outputted by the ternary operation, if true, otherwise 6.

	// ssize_t write(int fd, const void *buf, size_t count);
	// The following write syscall is writing to stdout, one character which is selected by the procedure added to the string. For example
	// write(1, "TE", 1) => T, and, write(1, 1 + "TE", 1) => E

	// Thus we must be modding by 6 because 'World!' is 6 characters long. It's important to note that the behavior of the output is such that
	// you only start seeing a lot of '!' characters torwards the middle. So, it must be that the operator '_ < display_horizontal_length', is
	// indicating something about how close _ is to the center of the display, or maybe the fractal? The outter most expression is indicating
	// when we are at the center and as such should print spaces.

	// That is, as we iterate and decrease the value of display_vertical_length to 0, we output the equivalence class each number falls into
	// in terms of its remainder mod 150,
	&& write(1, (--display_vertical_length % display_horizontal_length ? (_ < display_horizontal_length ? --_ % 11 : 11) : 12) + "HelloWorld! \n", 1)

	// _Really_ interesting behavior occurs when you change the 0 in the assingment below to 1, 2, or -1. It seems I'm causing a whole new mathematical structure
	// to be displayed, but the output looks vaguely like a zoomed out version of the earlier fractal. And, by the time I use the integer 2, I get uniform plain
	// output with no features to note whatsoever. It's almost as if I'm adding or removing dimensions which lends to the complexity of the object. I'd have to
	// review my fractal knowledge. Whereas all the earlier adjustments felt like I was feeling the same part of the elephant from differing angles, upside down, etc,
	// this feels like a whole other part of the elephant.

	// Changing, getting rid of, or scaling the divisor to extermity changes absolutely nothing from what I can tell from the output.
	// Ditto for multiplication, addition, mod, and subtraction.
	&& ( O = I = l = _ = r = 0, (fractal_left_padding += fractal_scale))) {
	// Changing the constant to multiple here again caused that log-y like squishing

	// Adding or subtracting the vertical positioning seems negligible as having any effect on the fractal, EXCEPT, that if you don't do either you completely
	// fuck up the output. Not sure if I'm still looking at the same map, territory, or gibberish.

	// OOOooo, changing addition to subtration in the last expresion, first operator, causes the fractal to be reflected 180 deg, AND, changing subtraction
	// to addition in the last expression, second operator, caused the fractal to become a diamond. Loss of randomness? Complexity? The fractal was already in the
	// vague shape of a diamond insofar as it would fit in one overlayed, so theirs definitely a mathematical explanation, as opposed to programming mishaps (which are
	// only incidentally mathematical in this case).
	O = I * 2 * O + fractal_vertical, I = l + fractal_left_padding - r;
	}
	}
	#include <unistd.h>
	float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L\|\|
	(h-=o,T= -2),s;4 -(r=OO)<(l=II)\|++ _==L&&write(1,(--s%L?_<L?--_
	%6:6:7)+"World! \n",1)&&(O=I=l=_=r=0,T+=o /2))O=I2O+h,I=l+T-r;}