Mijn broncode

[Webmaster]

From: Cugel

Duidelijker. Daar gaat het om. En eenvoud maakt de zaak duidelijker.

----
En daar raak je precies het punt waar het om-draait !

Je rekent de verkeerde kant op en alleen maar met begrippen die je aangeleerd zijn
( of natuurlijk zelf hebt eigen gemaakt ). Er zijn maar twee in/outputs ; sound & vision.
Wel rekening houden met R,G,B en Zw en W.
Twee strings die synchroon lopen in de itteratie. De bit waarde van de kleur staat al vast
eer er gerekend gaat worden. De uitslag ( som ) van de eerste scene wordt alleen maar
vergeleken met een priemgetal omdat die nu eenmaal vastliggen van nature. Het verschil
wat je van dat priemgetal weer aftrekt geeft weer de waarde van de string en vice versa.
Je kunt dit inderdaad niet oneindig herhalen omdat je de priemgatallen die je gebruikt ook
moet opslaan zodat het maar steeds een fractie van het origineel blijft.
Stel je maar eens een pyramide voor( punt boven ) die naast een piramide staat die op zijn kop
staat. Beide piramides hebben dezelfde afmetingen en vormen zo elkaars complement.
De itteratie ziet er exact hetzelfde uit.

Een heel kort filmpje: 1 ( 104728 ) > de bovengrens was het 10.000e priemgetal.

Ga gerust heel moeilijke vragen bedenken...die los ik niet op voor je ( waarschijnlijk niemand )
Deze techniek is eerst terug naar af en helemaal overnieuw beginnen.

Suc1

[Webmaster]

From: Drazic

Als ik je goed begrijp zit je idee ongeveer zo in elkaar (corrigeer me als ik het fout heb graag):

- Elk frame van een film kun je weergeven als een getal dat tussen de 0 en een fixte
bovenwaarde (die bovenwaarde word bepaald door de kleurdiepte, resolutie, etc.
en ligt dus vast, ik noem deze bovenwaarde vanaf nu 'Y' )

- Deze frames verdeel je in blokken van bijvoorbeeld 100 frames, deze blokken met
frames noem ik vanaf nu ' Scenes'

- Vervolgens bekijk je van elke scene ( = 100 getallen tussen de 0 en Y)
wat het laagste en het hoogste getal zijn van die 100 getallen.
Er is een heele grote kans dat het laagste getal veel groter is dan 0,
en tevens een heeel grote kans dat het hoogste getal veel lager ligt dan Y.

- Met deze info kun je nu voor elke scene de bovengrens (Y) al een stuk verlagen ,
door een offset op te tellen bij elk afzonderlijk framegetal (die offset is het laagste
getal dat bij die 100 getallen van de betreffende scene zat) en de bovengrens Y word
nu: het grootste getal dat er tussen die 100 zat, minus die offset...

- Als je nu voor elke scene de offset en de bovengrens opslaat, kun je die 100 getallen
nu in verreweg de meeste gevallen in minder bits opslaan, ondanks dat je wat extra
info bij elke scene opslaat (nl. de offset en de nieuwe bovengrens)

- Nu ga je van elke scene weer opnieuw de getallen bekijken, en vervang je elk getal
door de volgende 2 getallen: - dichtsbijzijnde priemgetal, - verschil met dit priemgetal
Dit dichtbijliggende priemgetal noteer je niet met de absolute waarde (bijv. 2389) maar
door te zeggen het 1700e priemgetal vanaf 0... Das al een beetje kleiner 2389 word 1700,
en daar komt alleen nog een kleine correctie bij die je ook moet opslaan (bijv. framegetal ligt
113 hoger dan het 1700e priemgetal)

Is dit ongeveer wat je bedoeld? Zoja, dan maak ik dit verhaal nog ff af

[Webmaster]

From: Cugel

ff...?

Visueel zit je op de goede weg. Rekenkundig ziet het eruit als die piramide vorm ( de itteratie ).
Maar de waardes bewegen in een bolvorm ( met de waardes X,Y,Z ). Het nulpunt ( midden ) is steeds
het uitgangspunt om optimale spanning te houden in de verhouding van de waardes ). De database
schuift als het ware steeds het volgende priemgetal naar het midden toe en heeft dan weer steeds
diezelfde maximale waardes. Dit impliceert ook dat de waardes negatief kunnen zijn vectorieel gezien
maar worden wel absoluut gemeten. De waardes worden gekoppeld aan de spanning die op de horizontale
en verticale platen staan icm. het electronenkanon.

Zie het als een zygote die groeit vanuit de neurale buis. Met de juiste parameters komt er een plaatje uit van
een ..... . In dit geval een film of natuurlijk het reciproke deel.

[Webmaster]

From: MatrixView

ff...?

Visueel zit je op de goede weg. Rekenkundig ziet het eruit als die piramide vorm ( de itteratie ).
Maar de waardes bewegen in een bolvorm ( met de waardes X,Y,Z ). Het nulpunt ( midden ) is steeds
het uitgangspunt om optimale spanning te houden in de verhouding van de waardes ). De database
schuift als het ware steeds het volgende priemgetal naar het midden toe en heeft dan weer steeds
diezelfde maximale waardes. Dit impliceert ook dat de waardes negatief kunnen zijn vectorieel gezien
maar worden wel absoluut gemeten. De waardes worden gekoppeld aan de spanning die op de horizontale
en verticale platen staan icm. het electronenkanon.

Zie het als een zygote die groeit vanuit de neurale buis. Met de juiste parameters komt er een plaatje uit van
een ..... . In dit geval een film of natuurlijk het reciproke deel.

Ja joh, slinger er nog maar wat termen bij... 't kan niet op! hahaha!

Weet je, ik kan er werkelijk geen touw aan vastknopen, hoe vager en mooier je 't probeert te verklaren, hoe minder ik je geloof... We hadden zo'n mooi voorbeeld, maar je wijkt er steeds weer vanaf...

Ik weet ook nog steeds niet wat je met horizontale en vertikale platen bedoelt... en nu wordt er ook nog een electronenkanon tussengeschoven en waardes die in een bolvorm bewegen... What the f*ck?

...'t heeft niks meer met eenvoud te maken... misschien is dat het wel, maar dan druk jij je nogal onbegrijpelijk en met veel poeha uit... is dat om ons te imponeren ofzo? ...ik raak daar niet van onder de indruk.

Jammer hoor.

[Webmaster]

From: Drazic

Beste Cugel,

Ik ben programmeur, en wil best samen met je je plan
gaan testen, maar net zoals Matrix volg ik het ff nie meer....
Kun je nie eens proberen mijn stappenplan een beetje af
te maken.. Dus gewoon in normaal nederlands, de handelingen
opsommen die je moet doen om van een scene met frames
naar een 'magisch getal' te komen (en andersom natuurlijk )

[Webmaster]

From: Weertj

Beste Cugel,

Ik ben programmeur, en wil best samen met je je plan
gaan testen, maar net zoals Matrix volg ik het ff nie meer....
Kun je nie eens proberen mijn stappenplan een beetje af
te maken.. Dus gewoon in normaal nederlands, de handelingen
opsommen die je moet doen om van een scene met frames
naar een 'magisch getal' te komen (en andersom natuurlijk )

Precies... dat laatste daar gaat het om.

En generiek algorithme (wat dit claimed te zijn) zal met een simpel voorbeeld verklaard kunnen.

Ik ben ook programmeur en wil ook best eens wat testen....


Jacco

[Webmaster]

From: Cugel

Jacco & Drazic,

Drazic zit op de goede weg..als je zijn ingeslagen weg volgt kom je vanzelf tegen waar het fout gaat.
Het klinkt mischien gek maar dan heb je gelijk de oplossing. Wellicht dat deze link
licht in de duisternis geeft: http://www.win.tue.nl/~jessers/aansluit ... tallen.htm

Stel je een simpel boek voor dat per bladzijde een resolutie heeft van een aantal letterplekken x regels
...dit is echt de laatste hint...ik lees eind april de oplossing wel van jullie.

Baai du wee; de hor. en vert. plaat zitten in een televisie en daar staat spanning op. De waarde van de spanning
bepaalt waar het deeltje dat afgeschoten wordt door het electronenkanon terecht komt ( bijv. linksonder in beeld ).

[Webmaster]

From: Drazic

Drazic zit op de goede weg..
als je zijn ingeslagen weg volgt
kom je vanzelf tegen waar het fout gaat.

Ik heb de ingeslagen weg al eens gevolgd,
en weet precies waar het fout gaat. In het
begin zijn de 'gaten' tussen de priemgetallen
vrij klein (en haal je dus weinig winst), en na
een tijdje worden de gaten groter, maar word
dus ook het verschil met de echte waarde groter
dus dan behaal je net zo min winst omdat je het
verschil ook nog moet op gaan slaan ...

Nou kun je natuurlijk een priemgetallen tabel
gebruiken die geoptimaliseerd is voor het frame
of stukje scene dat je wilt gaan coderen, maar
om diezelfde tabel aan de andere kant van het
netwerk weer te genereren kost bijna net zoveel
informatieoverdracht dan dat je het zonder
'priemgetallentruuk' had overgezonden...

Tenzij jij dus een methode denkt te hebben om
priemgetallen te genereren die gunstig zijn voor
een bepaald frame/scene, werkt jouw idee niet.
Zelfs niet als je 100 tabellen zou opslaan en bij
elk frame/scene zou aangeven welke van die 100
de decoder moet gebruiken (de gunstigste die de
encoder heeft kunnen vinden), zijn er altijd nog
frames die juist groeien omdat er geen van de 100
gunstig genoeg is...

Het word een heel ander verhaal als alle waardes
van de frames of scenes vrij dicht bij elkaar liggen
of gesorteerd zijn, maar hoe krijg je ze dichtbij elkaar
of hoe hef je de sortering weer op (zonder extra info
op te hoeven slaan)?

Kortom, uiteindelijk loop je vast...

Het klinkt mischien gek maar
dan heb je gelijk de oplossing.

Nee hoor.. Ik niet iig En als jij um
wel hebt ben ik zeer benieuwd en wil
ik je graag helpen Een paar pagina's
terug schreef je dat jouw idee een soort
opensource moest worden net als Linux,
waarom geef je niet wat meer info over
je plan vrij dan?

Wellicht dat deze link licht in de duisternis
geeft: http://www.win.tue.nl/~jessers/aansluit ... tallen.htm

Niet echt.. Bovendien kende ik de link al van
toen ik zelf met een soortgelijk idee bezig
was (naar aanleiding van het boek, net zoals jij)

Dus Cugel, ik word het steeds meer met
MatrixView eens: OF we werken samen
met z'n 3-en je idee uit om te zien of het
werkt, OF je moet ophouden met beweren
dat het werkt.... Aan jou de keus

[Webmaster]

From: MatrixView

Hello again,

voor iedereen en in het bijzonder Juffrouw Cugel:
(Drazic en Jacco hebben geen uitleg nodig waarschijnlijk)

De onderstaande 2 stukjes komen uit de FAQ van de comp.compression newsgroup:
http://www.faqs.org/faqs/compression-fa ... ion-8.html
------------------------------------------------------------------------------------------------

Yet another popular idea is to split the input bit stream into a sequence of
large numbers, and factorize those numbers. Unfortunately, the number of bits
required to encode the factors and their exponents is on average not smaller
than the number of bits of the original bit stream, so this scheme too cannot
compress all data. Another idea also related to primes is to encode each
number as an index into a table of primes and an offset relative to the indexed
prime; this idea doesn't work either because the number of bits required to
encode the index, the offset and the separation between index and offset
is on average not smaller than the number of bits of the original bit stream.

------------------------------------------------------------------------------------------------

9.2 The counting argument

Theorem:
No program can compress without loss *all* files of size >= N bits, for
any given integer N >= 0.

Proof:
Assume that the program can compress without loss all files of size >= N
bits. Compress with this program all the 2^N files which have exactly N
bits. All compressed files have at most N-1 bits, so there are at most
(2^N)-1 different compressed files [2^(N-1) files of size N-1, 2^(N-2) of
size N-2, and so on, down to 1 file of size 0]. So at least two different
input files must compress to the same output file. Hence the compression
program cannot be lossless.

The proof is called the "counting argument". It uses the so-called pigeon-hole
principle: you can't put 16 pigeons into 15 holes without using one of the
holes twice.

------------------------------------------------------------------------------------------------


@Drazic

Het word een heel ander verhaal als alle waardes
van de frames of scenes vrij dicht bij elkaar liggen
of gesorteerd zijn, maar hoe krijg je ze dichtbij elkaar
of hoe hef je de sortering weer op (zonder extra info
op te hoeven slaan)?

't is niet helemaal wat je zoekt, maar een "Burrows-Wheeler transform"
komt het dichtst in de buurt (behoeft nog wel een indexnr naast de gesorteerde data)

@Jacco,
Zijn wij nu echt de enigen die van mening zijn dat Sloot niet lossless werkte?

[Webmaster]

From: Cugel

Hello again,

voor iedereen en in het bijzonder Juffrouw Cugel:
(Drazic en Jacco hebben geen uitleg nodig waarschijnlijk)

Yet another popular idea is to split the input bit stream into a sequence of
large numbers, and factorize those numbers. Unfortunately, the number of bits
required to encode the factors and their exponents is on average not smaller
than the number of bits of the original bit stream, so this scheme too cannot
compress all data. Another idea also related to primes is to encode each
number as an index into a table of primes and an offset relative to the indexed
prime; this idea doesn't work either because the number of bits required to
encode the index, the offset and the separation between index and offset
is on average not smaller than the number of bits of the original bit stream.

The above is absolutely true. Altough completely false if you give the primenumber
a number of its position. The lowest number is the start of your index.
Ever realized that the positionnumber of a primenumber can be generated the same
as a primenumber and become a primenumber itself...Think guys...think!

CU