Oops, total URL fuckup, here's the the tested errata: https://en.wikipedia.org/wiki/Mark_Benecke https://en.wikipedia.org/wiki/Wolfram%27s_2-state_3-symbol_Turing_machine https://en.wikipedia.org/wiki/Half-integers https://en.wikipedia.org/wiki/Quaternion_group https://en.wikipedia.org/wiki/Planck_constant https://en.wikipedia.org/wiki/Speed_of_light https://en.wikipedia.org/wiki/Theory_of_everything
Ik schreef: Chere Philippe, merci pour vous observationes, critiques et > recommendationes: > > On Fri, Jul 5, 2013 at 8:59 PM, Philippe Verdy <[email protected]> wrote: > >> Why did it reach the Unicode Sarasvati list ? >> > > Because Unicode is about Finding The Best Representation Of The Universe's > Codes (=Languages). > > >> If you ask for help about what's wrong about this undocumented program, >> may be you should consider just these loops: >> >> for(w=0;--w;)for(z=0;z--;)for(y=0;y--;)for(x=0;x--;) >> >> - the w loop will run from -1 to -127 then 128 to 1, so it will not run >> w=0 >> - the z, y, x loops will never run (the initial value is 0, you test it >> in the condition using post-decrementation, so this is the initial value >> your test) >> > > Right, my "Heureka"" was a premature ejeculation due to the compiler > accepting my program as syntactically correct and my psyche's reasoning > feeling overly confident that this was already it. I got suspicious after > the computation process taking 99% CPU load and a slim 384k for over a > couple of hours, and eventually found and fixed the second problem myself > but not the w=0. > > Talking to Doctor http://de.wikipedia.org/wiki/Marc_Benecke who certified > my weltformel seems lupenrein doktorabel to him, I decided to have to > rename w,x,y,z into h,i,j,k honor of http://de, > wikipedia.org/wiki/Plancksches_Wirkungsquantum and > http://en.wikipedia.org/wiki/Quaternion_groupand am still pondering > whether to > - go from signed char to unsigned char and just manually work with > 2-complement > - go from char to int but count h from 1 to 127 and i,j,k from -127 to 127 > - loopholing my miniature universe so that information from 127 propagates > in 1c to -128 even though the real universe seems to need at least > (2^2^256h)^4 if not infinite timespace > > In other words, the initialization makes nothing, and leaves all cells to >> their initial value 0 (from calloc) and only the following line sets it >> differently. >> > > >> >> b(10,0,0,0)=7; /* urknall! 10 is just random choice */ >> >> This is a case of over-optimization, using some untested assumptions. >> > > Assuming my initialization had succesfully filled with an equal > oscillating load of minuses and pluses, I just wanted to visualize the > electromagnetic vacuum wave before urknall for ten steps. These could of > cause also be reduced to zero, but I need exactly one mutating urknall to > turn the perfectly ordered harmony into a germ of life and chaos that can > evolve and create biological structures like hydrogen and Brad Pitt and > Angelina Jolie. > > Use integers in loops, and unsigned chars for your 4GB work buffer >> containing the hypercube: >> >> main(){int w,x,y,z; unsigned char*c=calloc(1L<<32,sizeof(unsigned >> char)); >> for(w=256;--w;)for(z=256;--z;)for(y=256;--y;)for(256=0;--x;)b(w,x,y, >> z)=(x+y+z)%2?1:4; >> >> Anyway this program is unnecessarily slow for computing 6 sets of 256x256 >> PPM bitmaps with RGB color space. >> > > I realized I tried to recompute each tomographic slice 64k times which > definitely shows another of the prototypes immaturity. > > You can certainly avoid allocating 4GB of memory (many systems have a >> total of 4GB including for the OS and shared memory space for transfering >> textures to video accelerators). >> > > You mean something like a growing cycle realloc(<<=4);ppm();free();? > > You should also avoid creating so many files per directory (the filesystem >> or your shell does not like sorting so many files, the implemetners of web >> browser caches know that and distribute files in separate directories. >> First, you have 6 distinct sets, which could have their own folder, then >> you have 65536 files per set, which you can split into 256 subsets of 256 >> files. >> >> - The files set p(w, x, 256, 256) should be in files >> "wx/<w>/<x>.extension" >> - The files set p(w, 256, y, 256) should be in files >> "wy/<w>/<y>.extension" >> - The files set p(w, 256, 256, z) should be in files >> "wy/<w>/<z>.extension" >> - The files set p(256, x, y, 256) should be in files >> "xy/<x>/<y>.extension" >> - The files set p(256, x, 256, z) should be in files >> "xz/<x>/<z>.extension" >> - The files set p(256, 256, y, z) should be in files >> "yz/<y>/<z>.extension" >> > > Perfect, I love your purely NoSQL model and will incorporate it and credit > you! > > This just means creating the 6 subdirectories "wx", "wy", "wz", "xy", "xz" >> and "xz", each one containing 256 subdirectories. >> > > And each of these 256 subdirs contain 256 subdirs containing 256 files > containing 256 rows of 256 colors. > They can each further by compressed by ppmlabel -text $filename $filename > | pamenlarge 4 | pnmtopng > $filename.png. > And any 256 further by combining the screenshots into three video/mp4 thru > ppmtompeg $CONFIG && ffmpeg $ARGS > > These bitmaps are also over large (PPM files for RGB color space with 1 >> bit per pixel are 8 times larger than necessary, using 1 full storage byte >> per pixel and per color plane, instead of just 1 bit). So each 256x256 >> bitmap takes 192KB + 13 bytes for the magic header. As you store all >> bitmaps in the same current directory, you'll get 256x256*6=393216 files, >> taking 193KB each, i.e. a giant storage space of 75,890,688 KB or 72.375 >> GB, instead of a bit more than 9.05 GB (yes I know that 1TB hard disks are >> common, but writing 72GB this way is really slow; and as you need to >> allocate more and more space for the directories, the current folder will >> be fragmented and will also fragment the storage for your bitmaps). >> > > I tried to first get it right and then get it fast but I started with > maximum SunOS4 brute force realizing 2^2^4 would not get me anywhere near > the needed 2^2^204 planck computations to compute the universe's complete > history until the universe's current IQ of 2^203h is light years ahead of a > single human's IQ of 2^2^48h synapses to which our synthetic computers > inferior at 2^2^32h and gearing toward superiority at 2^2^64h or even > 2^2^2^128 would never be getting brute-force but by only by intelligent > pattern recognition breaking the speed of light limit by intelligent > pattern abstraction. > > So really consider using a better format for bitmaps with a total color >> depth of 3 bits per pixel (you could even just start by using indexes >> colors instead of separate color planes, you'd already use 8 bits instead >> of 24 bits per pixel); there's also a PPM format for palettes with 16 >> indexed colors, it just uses 4 bits per pixel. >> > > Unfortunately the Jef Pokanzer's P6 format has not enough flexibility for > this, I have not yet researched whether switching to separate P4 PBM > bitmaps for the irgb colors would optimally pack the data or even bloat the > problem further. > > Note that these images are also highly compressible, there's lot of >> redundancy in their values. If you don't want to use PNG compression, use >> at least a zip archive creator that will compress your PPM streams on the >> fly: the zip file may contain the subdirectories, or you could create just >> 6*256=1536 archive files, each one containing 256 PPM streams, using a >> basic deflate compression method. >> > > I know, if you want to get an impression how the minimal universal machine > behaves before getting gridded, take popcorn and coke and sit back and > enjoy my first http://czyborra.com/thti/utm32.mp4 >
