Mijn broncode (deel 2)

Forum: De Broncode (104 topics)

Topic: Mijn broncode (deel 2)

MatrixView
11-3-2005 10:26:00

[De eerste thread werd een beetje lang en onoverzichtelijk, vandaar: deel 2]

Cugel wrote:
"Je zou jezelf eens af moeten vragen in hoeveel signalen jijzelf beeld ontvangt met je ogen.
Maw...wat wordt er nu exact uitgezonden wat jij ontvangt en denkt/weet te zien.
Data is slim...wij rangschikken deze alleen fout met de huidige comm. methoden.
Lees eens wat over DNA/RNA!"

Dat is heel erg relatief, want dat kan voor iedere persoon anders zijn en ook zelfs van keer tot keer voor eenzelfde persoon verschillen. Ieder persoon merkt op/herkent andere details / kleuren en objecten. Ik denk niet dat je doelt op object-herkenning in voor en achtergrond, want al lijken we dit -als mensen- heel snel en gemakkelijk te doen, het is volgens mij toch een vrij ingewikkeld process in onze hersenen.

Als je het nog meer -basic- bedoelt, zien we gekleurde patronen en merken we de direct zichtbare verschillen op tussen vlakken in het beeld. Maar ook dat is relatief. Zelf ben ik bijvoorbeeld gedeeltelijk kleurenblind.

Ik denk niet dat we natuurlijke beelden als -simpel- moeten gaan afdoen. In een natuurlijk beeld zit een enorme hoeveelheid informatie... dit zijn geen Nijntje-tekeningen of Mondriaan-paintings (>1930).

De huidige digitale communicatie en opslag is vooral gericht op -foutvermindering-.
Bij Losless is dat -totaal- en bij Lossy is dat menselijk gezien en/of processgericht -goed genoeg-.
Uiteindelijk sturen we dus toch een enorme hoeveelheid informatie over en in binaire/digitale vorm ken ik daarvan aardig de beperkingen qua logische grootte.

Maar zoals ik al eens eerder zei, valt er toch nog een hoop winst te halen als je uitgaat van het feit dat er (zolang je maar klein genoeg gaat) altijd heel veel overeenkomsten zitten tussen 2 verschillende gegevens (bv files).

Bij films wordt er nu nog steeds voor een aantal frames binnen een film, (gelijkende) overeenkomsten bijgehouden en verschillen gecodeerd. Maar er wordt nog steeds niet gebruik gemaakt van de overeenkomsten die in tijd wat verder uit elkaar liggen OF (gelijkende) overeenkomsten tussen meerdere films. Daar is namelijk een database voor nodig.

Nu neem ik even een zeer simpel en stom voorbeeld: Denk aan 2 verschillende (horror)films... maar dan op (sub...)beeld-niveau. De (in ieder geval: gelijkende) overeenkomsten zijn enorm. Gemakshalve neem ik horrorfilms als voorbeeld, omdat deze nogal veel dezelfde donker gekleurde sub-beeldjes hebben...Maar dat kun je nog veel algemener maken als je de kleuren splitst (in analoge vorm is dit al zo) in basiskleuren. Daarmee bedoel ik het feit dat bv. 1000-den totaal verschillende kleuren toch allemaal uit exact dezelfde hoeveelheid groen bestaan.

Als je dit alles slim kunt coderen, door gebruik te maken van een database, waarin dergelijke (sub...sub.... beeldjes staan) of nog slimmer... formules die met een geringe hoeveelheid parameters een enorme hoeveelheid van (gerangschikte) sub beeldjes kunnen genereren... of nog mooier... formules die parameters voor volgende formules kunnen genereren die weer... etc...

Sloot maakte hier volgens mij grof gebruik van...maar zeker weten doe ik niks. Maar hoe maak je zoiets generiek voor iedere bestaande en toekomstige film...? Dat zie ik nog niet. Vandaar dat ik denk dat zijn methode lossy (gelijkend = genoeg) en gebruik maakte van een niet-generieke database (voor een beperkte hoeveelheid films).

Dan is er nog 't analoge verhaal... Hij was een tv-reparateur, geen wiskundige of informaticus en volgens mij al helemaal geen echte digitaal (binair) kenner. Nu weet ik zelf evenveel van analoge technologie als een pak hooi, maar daar wordt aan gewerkt.

Cugel, wat voor nut heeft ontwikkelings-biologische kennis van Dna/Rna in dit verhaal? Dit is geen afzeik-vraag!
Maar een term als: "data is slim" klinkt mij zo loos in de oren... Wat we ermee doen, DAT kan slim zijn, of hoe we het rangschikken kan OOK slim zijn...

Als er iets niet duidelijk is voor iemand in het hierbovenstaande wil ik dit best uiteenzetten.

CU guys.

Troebelwater 11-3-2005 20:47:00	Hallo allemaal, 'k heb de indruk dat jullie je bezig houden met compressie (als oplossing). Maar sloot had toch iets van algoritmen, dus dat je voor beeld een nummer verzint en dat omtovert naar een code?

MatrixView
12-3-2005 0:16:00

[quote]Hallo allemaal,
'k heb de indruk dat jullie je bezig houden met compressie (als oplossing).
Maar sloot had toch iets van algoritmen, dus dat je voor beeld een nummer verzint
en dat omtovert naar een code?[/quote]

Nou, om even een bridge over -troubled water- heen te leggen... dat ligt er maar net aan wat jij of Sloot onder compressie verstaat. In mijn bovenstaande concept heb ik het eerst nog maar even over rangschikking en codering van data in de database en laat ik de klassieke compressiemethoden even op stal.

Ieder beeld een nummer geven is niet genoeg... je zult onderdelen van dat beeld ook slim moeten "nummeren".

Lees de patenten van Sloot nog even door.

Troebelwater
12-3-2005 6:43:00

Heb ik gedaan, maar daar heb ik niet zo'n verstand van, i.e. beelden, analoge signalen, logische poorten etc.
'k programmeer zelf ook een beetje, vooral basic, of vba in excel.
C++, java, c# ken ik alleen voorwat betrefd kern statements, heb daar nooit iets zinnigs mee kunnen maken.
Geloof een venstertje in java en een applet met getekende rondjes er in :).

Maar 'k ben dus vanuit het perspectief van de pc aan't denken.
Zo vraag ik me alf af of je dmv een algo en een nummer een tekst kunt reconstrueren.
Omdat dat na mijn idee de kern van de zaak is, immers er was spraken van 5 algoritmen.
En kern gegevens die zijn dan gewoon hardware matig vast gelegd (kan best zijn dat ik nu aan't ijlen ben),
'k ben in de veronderstelling dat er bij een pc ook van alles is in gebakken.

Vanuit het perspectief van de pc kan je geloof ik zeggen, byte waarde en ascii tabel:
00000000 <=> NULL, waarmee ik wil zeggen de combinatie van "enen en nullen" is een
bepaalde waarde in de tabel

Als Sloot nu es alleen maar de enen heeft gebruik ipv een combinatie van, dan hoeft je de combinatie
van ook niet telkens te berekenen? (wanneer dat zo bij een pc het geval zou zijn, kan me niet voorstellen
dat een ascii tabel is in gebakken, dus vinden er telkens berekeningen plaats)

Al is het dan maar zoals bij C of C++, dat de ascii tabel in een array staat, dan heb je toch een constante pointer naar
het eerste element en vervolgens een berekening naar element x. 'k heb gelezen dat de benaderin van een willekeurig element in een array daarom altijd even snel is omdat je steeds dezelfde berekening hebt.
Wat 'k nu probeer te zeggen is, dan is er toch steeds praken van berekeningen, maar mischien is de inrichting
bij Sloot zo geweest dat het effect van de bewerking geen berekenig is geweest maar een effect zoals bij
bucket sort: element x, ok dan daarna toe, dus een toewijzings of schuif effect.

Hoe zien jullie dat, is bv een algo met een nummer om vervolgens een regeltekst te reproduseren überhaupt
wel mogelijk of ben ik gewoon helemaal verkeerd aan't denken?

grts

MatrixView
12-3-2005 17:04:00

Hoi TW,

De patenten van Sloot die iedereen kan inzien zijn toch vrij simpel... het gedeelte waar 't echt om draait heeft hij , om redenen waar we alleen naar kunnen gissen, weggelaten. Zoals hij zelf zei waren dit de formules die de sleutel aanmaakte behorende bij de opslag en natuurlijk de andere kant op (decodering).

Wat jij wilt weten is of dat uberhaupt kàn, als ik je goed begrijp... Laten we 's kijken naar het voorbeeld dat je gebruikt: kun je met een getal als input voor een -algoritme- (wat overigens een ruimer begrip is dan een -formule-), iedere zinvolle regel tekst produceren...? (nog afgezien van alle mogelijke talen en spelling)

Dat hangt van een aantal dingen af, denk ik:
- Hoe groot mag dat getal zijn?
- Hoe groot mag de database zijn? Of mag je daar geen gebruik van maken?
- Mag deze database dynamisch zijn? Of moet ie fixed zijn?
- Moet de database generic zijn of alleen voor een specifieke dataset?

Er zijn dus echt vele manieren om dit aan te pakken: Wat je bv. zou kunnen doen is met behulp van een fixed database de zin coderen naar een nummer (dat bij decodering/decompressie weer diezelfde zin moet opleveren).

Je database zou bijvoorbeeld alle characters, lettergrepen, woorden en veel gebruikte woord-combinaties kunnen bevatten, waarvoor voor ieder genoemd onderdeel een code bestaat. De meest gebruikte codes zou je een zo klein mogelijke code kunnen geven (=Huffman codering).

Je uiteindelijke nummer kan stukken kleiner zijn dan de opslaggrootte van de zin zelf (de database-grootte niet meegerekend).

Het probleem is dat -gemiddeld- de nummers toch niet echt superklein zijn en nog vervelender: Er zijn ZOVEEL verschillende zinnen die allemaal een uniek nummer moeten opleveren dat je niet een compressie-ratio krijgt waar je u tegen zegt.

De methode Lempel-Ziv lijkt hier een klein beetje op, al maakt die gebruik van een dynamische database, die weer opgebouwd wordt tijdens decodering/decompressie.

Het is toch erg handig om te weten wat er voor methoden bestaan, want anders ben ik bang dat je het wiel vroeg of laat opnieuw gaat uitvinden, en dat is echt zonde van je tijd.

Nog even over arrays: Je kunt een element uit een simpele array opvragen door bij het geheugen-adres van het eerste element het (indexnummer * grootte van het data-type ) op te tellen.

Troebelwater
14-3-2005 13:51:00

Op zich was 'k niet van plan om regels te hanteren, zoal hoe groot mag een getal zijn.
'k was ook niet van plan om iets met een database te doen voor verdere compressie.

Dus ik hanteer om te beginnen geen regels, omdat ik eerst de kern gedachte ga na jagen.
Die is naar ik denk, corrigeer me als ik het fout heb, het produceren van een algo of een formule om tekst naar
een getal of code om te zetten en dan vervolgens de code of het nummer met het algo terug omzetten naar tekst.

Ik acht het ook niet onwaarschijnlijk dat ik het wiel opnieuw aan het uitvinden ben :)

Maar dan nog de vraag, gaat het eigenlijk wel om een tekst om te zetten naar een getal met een algo?

Troebelwater 14-3-2005 19:04:00	P.s. bericht van MatrixView wordt ook gewaardeerd :)

Cugel
14-3-2005 23:15:00

[quote][

Cugel, wat voor nut heeft ontwikkelings-biologische kennis van Dna/Rna in dit verhaal? Dit is geen afzeik-vraag!
Maar een term als: "data is slim" klinkt mij zo loos in de oren... Wat we ermee doen, DAT kan slim zijn, of hoe we het rangschikken kan OOK slim zijn...

CU guys.
[/quote]

Sorry, zie mijn antwoord bij mythbusters..

DNA is eigenlijk ook een groeiende formule die altijd groeit in een bepaald Patroon daar de randwaarden altijd een format qua minimum en maximum hebben voor parameters. De ogen hebben
altijd een bereik wat vast ligt in een spectrum, het gehoor in een range aan frequenties.
De clou zit dus niet zo zeer in de data...(die is overal hetzelfde van origine) maar hoe je de formule laat groeien.
En die richting moet je dus eerst op. Niet eerst proberen om data zoals die nu opgeslagen wordt in dat systeem te stoppen, dat werkt nooit.