Re: weltformel.c asking for peer review

From: Roman Czyborra <roman_at_czyborra.com>
Date: Sat, 6 Jul 2013 00:39:25 +0200

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_group and 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 - 17:43:11 CDT

This archive was generated by hypermail 2.2.0 : Fri Jul 05 2013 - 17:43:12 CDT