Re: weltformel.c asking for peer review

From: Roman Czyborra <roman_at_czyborra.com>
Date: Sat, 6 Jul 2013 01:04:03 +0200

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 <verdy_p_at_wanadoo.fr> 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
>
Received on Fri Jul 05 2013 - 18:07:01 CDT

This archive was generated by hypermail 2.2.0 : Fri Jul 05 2013 - 18:07:02 CDT