Forum: De Broncode (104 topics)
|
|
Cugel
29-1-2005 23:10:00 |
Als je een film in stukken hakt waarvan
de optelsom een benadering heeft van een
bepaald priemgetal kun je daarvan het
verschil weergeven. Stel dat het eerste
deel de optelsom van 10 is dan pak je 11
als eerste hoger priemgetal en word dat
deel weergegeven als het getal één. Het
maakt dus niet uit hoe groot de optelsom
is, als het verschil met dat priemgetal
maar klein blijft. Als je dan nog eens
alle optelsommen van alle scenes achter
elkaar zet
heb je weer een getal wat je kunt
verkleinen door het te vergelijken met
een priem getal en voila....geef alle
itteraties een nummer en sein dat eerst
over het netwerk en daarna het
uiteindelijke nr ( getal ) wat dus de
gehele film weergeeft. Als beveiliging
jun je deze hele code weer in je
piramidemodel stoppen en zo weet je dus
nooit welk getal nu de film voorstelt.
Bijna een oneindige verkleining dus. Je
kunt dus oneindig veel films op één CD
kwijt.
Boven in de piramide stop je één getal
samen met de itteratie code en naar
beneden toe rekent zich een uitslag uit
die weer te zien is als film...
waar of niet waar ? |
|
weertj
30-1-2005 10:50:00 |
[quote]Als je een film in stukken hakt
waarvan de optelsom een benadering heeft
van een bepaald priemgetal kun je
daarvan het verschil weergeven. Stel dat
het eerste deel de optelsom van 10 is
dan pak je 11 als eerste hoger
priemgetal en word dat deel weergegeven
als het getal één. Het maakt dus niet
uit hoe groot de optelsom is, als het
verschil met dat priemgetal maar klein
blijft. Als je dan nog eens alle
optelsommen van alle scenes achter
elkaar zet
heb je weer een getal wat je kunt
verkleinen door het te vergelijken met
een priem getal en voila....geef alle
itteraties een nummer en sein dat eerst
over het netwerk en daarna het
uiteindelijke nr ( getal ) wat dus de
gehele film weergeeft. Als beveiliging
jun je deze hele code weer in je
piramidemodel stoppen en zo weet je dus
nooit welk getal nu de film voorstelt.
Bijna een oneindige verkleining dus. Je
kunt dus oneindig veel films op één CD
kwijt.
Boven in de piramide stop je één getal
samen met de itteratie code en naar
beneden toe rekent zich een uitslag uit
die weer te zien is als film...
waar of niet waar ?[/quote]
niet waar
Ik heb de getallen (bytes);
20 87 234 5 0 24 87 165 89 64 3 6 100 9
250 210
Probeer het hier maar 'ns mee. Coderen
en(!) decoderen.
suc6
Jacco
|
|
Cugel
31-1-2005 22:24:00 |
niet waar
Ik heb de getallen (bytes);
20 87 234 5 0 24 87 165 89 64 3 6 100 9
250 210
Probeer het hier maar 'ns mee. Coderen
en(!) decoderen.
suc6
Jacco
Er zijn oneindig veel oplossingen.
Neem bijv dat getal 20 > dat kun je
opslaan als: 3,9 ( 3 lager dan het 9e
priemgetal )
Het getal 87 > 2,24 ( 2 lager dan het
24e priemgetal )
Als je ook nog eens vast houdt aan de
regel dat een oneven getal tov. het
hoger gelegen priemgetal even is en vice
versa kom je heel erg ver.
De rest kun je zelf makkelijk uit laten
rekenen. Als alle max. waardes van elke
originele optelsom niet hoger dan bijv.
1009 komt en niet lager dan zeg 5 kun je
de piramide zichzelf de ordes laten
vaststellen. Dit wordt aan het begin van
de string weergegeven zodat de
ontvangende kant weet hoe de getallen
uitgerekend moeten worden. Zo kun je per
stap nog verder gaan door weer een orde
lager te gaan.
Als je er vanuit gaat dat het werkt moet
je alleen een afspraak over de
uitzonderingen maken ( en dat zijn er
erg veel! ).
Suc1,4
Jacco
[/quote] |
|
weertj
31-1-2005 22:57:00 |
[quote]
Er zijn oneindig veel oplossingen.
Neem bijv dat getal 20 > dat kun je
opslaan als: 3,9 ( 3 lager dan het 9e
priemgetal )
Het getal 87 > 2,24 ( 2 lager dan het
24e priemgetal )
Als je ook nog eens vast houdt aan de
regel dat een oneven getal tov. het
hoger gelegen priemgetal even is en vice
versa kom je heel erg ver.
De rest kun je zelf makkelijk uit laten
rekenen. Als alle max. waardes van elke
originele optelsom niet hoger dan bijv.
1009 komt en niet lager dan zeg 5 kun je
de piramide zichzelf de ordes laten
vaststellen. Dit wordt aan het begin van
de string weergegeven zodat de
ontvangende kant weet hoe de getallen
uitgerekend moeten worden. Zo kun je per
stap nog verder gaan door weer een orde
lager te gaan.
Als je er vanuit gaat dat het werkt moet
je alleen een afspraak over de
uitzonderingen maken ( en dat zijn er
erg veel! ).
Suc1,4
[/quote]
Klinkt allemaal erg wazig. In woorden
kan het algoritme niet volgen. Ik hoef
ook geen wiskundig bewijs te zien maar
een simpele cijfer oefening moet toch
kunnen?
Ik zie een soort Huffmann er in...
piramide is een binaire boom in IT.
Om bij de eerste twee getallen te
beginnen
20 -> 3,9
87 -> 2,24
Wat doen we met 3,9 en 2,24... hoe slaan
we die op?.... het zijn floating point
getallen. Elke floating getal kost zeker
4 bytes... we kunnen het ook fix point
opslaan maar kost het nog altijd 2 bytes
per getal.
Dus voorlopig is de "compressie" -100%
;-)
Hoe verder?
Jacco
|
|
Cugel
1-2-2005 22:34:00 |
[quote][quote]
Om bij de eerste twee getallen te
beginnen
20 -> 3,9
87 -> 2,24
Wat doen we met 3,9 en 2,24... hoe slaan
we die op?.... het zijn floating point
getallen. Elke floating getal kost zeker
4 bytes... we kunnen het ook fix point
opslaan maar kost het nog altijd 2 bytes
per getal.
Dus voorlopig is de "compressie" -100%
;-)
Hoe verder?
Verder;
Met een film is het het makkelijkst als
je begrijpt wat er precies opgelagen
wordt per pixel op een bepaald tijdstip.
De drie primaire kleuren kun je in
procenten weergeven tov. de verandering
van de pixel. Je moet dus van elke scene
( als je de film in zeg 30 stukken knipt
) wel steeds het laatste plaatje in het
RAM geheugen zetten om het eerste
plaatje van de nieuwe scene uit te
rekenen. Dit kost wel wat extra
rekentijd maar geen opslag op de disc of
USB stick.
Met geluid kun je dat per kanaal
hetzelfde doen. Als je de sinus max. 1
laat zijn heb je altijd een straal die
varieert vanaf het nulpunt en dus als
het ware een op- en neerwaardse beweging
maakt. Hier kies je gewoon wat gemiddeld
het beste uitkomt, dus waarschijnlijk
het verschil tov. 1 (eventueel kun je
met een differentieel ook de
oppervalktes uitrekenen en dat dus ook
weer vergelijken met het dichstbijzijnde
priemgetal. De priemgetallen set kan dus
per kleur en geluidskanaal verschillen
en wordt ook per scene opgegeven. In het
rom/ram geheugen moet natuurlijk wel een
priemgetallen generator zitten anders
zou je alle priemgetallen op moeten
slaan en zit je toch weer aan veel
opslagcapaciteit ).
Theoretisch is dit naar mijn mening goed
mogelijk. Jan heeft het nl. ook moeten
doen met componenten die hij toen
voorhanden had. Vanuit ons huidige
standpunt was dat toen erg primitief en
zo moet je het ook "terugdenken".
Het probleem zit hem echter in de heel
grote getallen en de rekentijd die je
hebt tov. de refreshrate.
Als de totaalsom van de eerste scene zeg
104723 ( teruggerekend naar binair naar
decimaal ) is dan is het verschil maar 6
met het volgende priemgetal. Als je dan
de piramide laat beginnen met bijv.
104701 dan geef je dit weer weer als
6,6. Dit kost je wel je floating point
ruimte maar veel minder ruimte dan
104723 binair weergegeven.
Nog heel wat te doen dus.
[/quote]
|
|
ralphs
2-2-2005 0:13:00 |
Gefeliciteerd, jullie komen in de buurt.
Gr, Ralph |
|
Cugel
2-2-2005 21:15:00 |
[quote]Gefeliciteerd, jullie komen in de
buurt.
Gr, Ralph[/quote]
Ralph,
De buurt is erg groot en erg simpel. De
moeilijkheid zit hem alleen in de
codering van de priemgetal piramide per
scene...thats all.
Heeft één van jullie wel eens
uitgerekend wat dat aan
opslagcappaciteit scheelt. Ga maar eens
rekenen met de TB's aan storage van een
gemiddelde bank..je komt dan al snel aan
een schijf van 20 GB waar je meer dan
genoeg aan hebt. Wereldwijd zou dat een
enorme afname van de energiebehoefte tot
gevolg hebben en een enorme snelheids
performance over een gewone koperen
leiding. Met een 56K6 modem kun je dan
net zo snel werken als nu met glas!
|
|
ralphs
4-2-2005 23:56:00 |
Cugel,
Als je slim bent hou je op met posten,
werk mee aan een nieuw patent. Neem
contact met me op, dan vertel ik je
meer. Dan kan je volgend jaar met
pensioen.
gr, Ralph |
|
Cugel
5-2-2005 21:24:00 |
[quote]Cugel,
Als je slim bent hou je op met posten,
werk mee aan een nieuw patent. Neem
contact met me op, dan vertel ik je
meer. Dan kan je volgend jaar met
pensioen.
gr, Ralph[/quote]
Ralph,
De vinding gaat binnenkort wereldwijd
toegepast worden ala Linux. Het is en
blijft een natuurlijk metafysich
fenomeen dat aan iedereen toebehoort. Ik
wil absoluut niet rijk worden want dat
ben ik al. En met pensioen wil ik al
helemaal niet. Er komt geen patent voor
mijn vorm daar ik het complementerende
deel nog niet verteld heb. Die
priemgetallen
business is nog maar peanuts vergeleken
bij exact dezelfde toepassing op de DNA
string. Dit is pas het begin...lees eens
wat meer over Imhotep, over natuurlijke
low frequenty amplifiers en de stand van
de Cheops pyramide op Tep Zepi...wellicht
dat er meer mensen wakker worden.
|
|
MatrixView
5-2-2005 22:41:00 |
[quote][quote]Cugel,
Als je slim bent hou je op met posten,
werk mee aan een nieuw patent. Neem
contact met me op, dan vertel ik je
meer. Dan kan je volgend jaar met
pensioen.
gr, Ralph[/quote]
Ralph,
De vinding gaat binnenkort wereldwijd
toegepast worden ala Linux. Het is en
blijft een natuurlijk metafysich
fenomeen dat aan iedereen toebehoort. Ik
wil absoluut niet rijk worden want dat
ben ik al. En met pensioen wil ik al
helemaal niet. Er komt geen patent voor
mijn vorm daar ik het complementerende
deel nog niet verteld heb. Die
priemgetallen
business is nog maar peanuts vergeleken
bij exact dezelfde toepassing op de DNA
string. Dit is pas het begin...lees eens
wat meer over Imhotep, over natuurlijke
low frequenty amplifiers en de stand van
de Cheops pyramide op Tep Zepi...wellicht
dat er meer mensen wakker
worden.[/quote]
hahahahahaha! Ik denk dat jij wakker
moet worden. Serieus.
Volgens mij zijn er hier teveel mensen
die zelfs in Lord of the Rings (willen)
geloven...
Complotten, esoterische bullshit... zero
point energy...etc...
't stikt van die sites op 't web...
Ik wil/kan best buiten de standaard
denken hoor, maar de tijd van efteling
heb ik echt gehad.
Nou, ik zie jullie wel op 't journaal:
"2 hobbits bedenken uitvinding van de
eeuw." Ik kan niet wachten, dus schiet
maar gauw op...
|
|
ralphs
6-2-2005 12:17:00 |
Cugel, stop met posten, serieus.
De dna toepassingen zijn eindeloos, maar
als de verkeerde mensen hiermee aan de
haal gaan heb je iets dat krachtiger is
dan een atoombom. Denk na voordat je nu
nog stappen zet, lees literatuur op
internet. De wil toch niet iemand worden
die de geschiedenis boeken in gaat als
iemand erger dan stalin, hitler of
mister dynamiet.
Gr, Ralph |
|
MatrixView
6-2-2005 17:47:00 |
[quote]Cugel, stop met posten, serieus.
De dna toepassingen zijn eindeloos, maar
als de verkeerde mensen hiermee aan de
haal gaan heb je iets dat krachtiger is
dan een atoombom. Denk na voordat je nu
nog stappen zet, lees literatuur op
internet. De wil toch niet iemand worden
die de geschiedenis boeken in gaat als
iemand erger dan stalin, hitler of
mister dynamiet.
Gr, Ralph[/quote]
Ralph, stop jij ook gelijk met posten!
Je kraamt steeds grotere onzin uit... 't
was erg vermakelijk, maar 't begint nu
echt irritant te worden.
Compressie/codering is een serieus
onderwerp, waar je geen kaas van hebt
gegeten, dat is me wel duidelijk
geworden. Je fantasie na het lezen van
Smits' boek is een beetje teveel op hol
geslagen...
Ik raad je aan om niet verder te
fantaseren, maar om ECHT eens aan het
programmeren en testen te slaan...
Je zult er dan snel achter komen dat je
ideetjes NIET werken. :-)
het volgen van de newsgroepen:
comp.compression en
comp.compression.research is ook een
goede klets water over je plaat.
Je hoort echt thuis tussen een kudde
klingonsprekende paranoïde nerds die met
pindakaas op hun hoofd in een
graancirkel dansen om free-energie op te
wekken.
Trek een blauwe jurk aan en probeer het
in een veehal in Tiel.... mafketel.
|
|
Cugel
7-2-2005 21:05:00 |
[quote][quote
hahahahahaha! Ik denk dat jij wakker
moet worden. Serieus.
Volgens mij zijn er hier teveel mensen
die zelfs in Lord of the Rings (willen)
geloven...
Complotten, esoterische bullshit... zero
point energy...etc...
't stikt van die sites op 't web...
Ik wil/kan best buiten de standaard
denken hoor, maar de tijd van efteling
heb ik echt gehad.
Nou, ik zie jullie wel op 't journaal:
"2 hobbits bedenken uitvinding van de
eeuw." Ik kan niet wachten, dus schiet
maar gauw op...
Geen complot geen esoterische bullshit.
Als je DNA opslaat en wacht op de juiste
parameters totdat het zichzelf uitpakt
zul je het op een bepaalde manier willen
coderen zoals nu het geval is met de
vorm van DNA zoals die in de natuur
voorkomt. Ergo moet er een trigger zijn
die overal in het heelal voorkomt en dat
is de low freq van... Het DNA klapt
zichzelf dan uit aan de hand van
parameters ( priemgetalgewijs ) en
groeit aan de hand van de combinaties
die de hoeveelheid van die trigger
uitzend.
"in leven" wordt de reeks aangepast maar
er wordt wel steeds gekoezen voor een
mogelijkheid die altijd al aanwezig is
geweest. Andersom werkt dit precies
hetzelfde.
In principe kun je dus ook een Hobbit
reconstrueren. Het is ook niet zo gek
dat iedereen anders denkt en doet maar
dit is wel gelimmiteerd aan het aantal
mogelijkheden per itteratie. Een reactie
als bovenstaand is dan ook niet
"vreemd".
[/quote] |
|
MatrixView
7-2-2005 23:39:00 |
[quote] Geen complot geen esoterische
bullshit.
Als je DNA opslaat en wacht op de juiste
parameters totdat het zichzelf uitpakt
zul je het op een bepaalde manier willen
coderen zoals nu het geval is met de
vorm van DNA zoals die in de natuur
voorkomt. Ergo moet er een trigger zijn
die overal in het heelal voorkomt en dat
is de low freq van... Het DNA klapt
zichzelf dan uit aan de hand van
parameters ( priemgetalgewijs ) en
groeit aan de hand van de combinaties
die de hoeveelheid van die trigger
uitzend.
"in leven" wordt de reeks aangepast maar
er wordt wel steeds gekoezen voor een
mogelijkheid die altijd al aanwezig is
geweest. Andersom werkt dit precies
hetzelfde.
In principe kun je dus ook een Hobbit
reconstrueren. Het is ook niet zo gek
dat iedereen anders denkt en doet maar
dit is wel gelimmiteerd aan het aantal
mogelijkheden per itteratie. Een reactie
als bovenstaand is dan ook niet
"vreemd".
[/quote]
Cugel, lieve jongen,
Laat ik nou toevallig dagelijks de
automatisering verzorgen in een lab vol
ontwikkellingsbiologen... I'm not
kidding!
En ik durf mezelf niet eens expert te
noemen op dat gebied... Maar jij weet
ècht niet waarover je praat, kolere zeg,
wat een ontzettende stierenpoep!
Whoahahaha!
Als ik jou was zou ik die jip-en-janneke
aflevering van Discovery, waarvan je 3
woorden hebt onthouden en vermengd met
je priemgetallen fetish, nog maar eens
goed bekijken. :-)
Dit forum heeft geen kloot meer met
Sloot's uitvinding te maken... Gelul in
de ruimte en gelul over Pieper. Jammer.
Logging Out. |
|
Cugel
8-2-2005 21:41:00 |
Zozo....en jouw moeten we wel geloven.
a) ben ik geen jongen
b) weet ik wel waarover ik praat ( jij
leeft nog in het tijdperk dat de aarde
weer plat is waarschijnlijk )
c) Jan Sloot heeft inderdaad niets
uitgevonden, het is er altijd al
geweest. Gewoon een natuurlijk fenomeen.
d) Ik ga Fiep een mailtje sturen :-)
|
|
MatrixView
9-2-2005 0:25:00 |
Dag wijffie,
[quote]
Zozo....en jouw moeten we wel geloven.
[/quote]
Niks moet. Ik zeg alleen dat jij uit je
nek lult. That much I know.
[quote]
a) ben ik geen jongen
[/quote]
Tja... dat verklaart een hoop. Ik zal er
in het vervolg rekening mee houden.
Hey, maar eh... hoe bevalt die LOI
cursus Windows 98 nou? Of doe je
Astrologie?
[quote]
b) weet ik wel waarover ik praat ( jij
leeft nog in het tijdperk dat de aarde
weer plat is waarschijnlijk )
[/quote]
Nice. I'll take you to the edge of the
earth and then push you over it...
[quote]
c) Jan Sloot heeft inderdaad niets
uitgevonden, het is er altijd al
geweest. Gewoon een natuurlijk fenomeen.
[/quote]
't is heel fijn dat jij al weet hoe
Sloot 't precies geflikt heeft en dat je
dat zo prachtig weet te koppelen aan een
natuurlijk fenomeen... Ik ben zelf nog
steeds bij het stadium dat ik ernstig
twijfel aan zijn uitspraken... Tenzij
jij "The Counting Argument" wiskundig
kunt weerleggen... wiskundig... dus niet
de stand van Toetanchamon's erectie
erbij gaan halen, a.u.b.
[quote]
d) Ik ga Fiep een mailtje sturen :-)
[/quote]
Doe Jip de groeten van me; Janneke
niet... da's zo'n slet.
Volgens mij dwaal ik af... komt allemaal
door jou...
|
|
Cugel
9-2-2005 21:36:00 |
Jij weet waarschijnlijk wel dat een film
een wis/natuurkundig maximum heeft qua
grootte.
Dit houdt in dat er een gem. onder- en
bovenwaarde is voor alle signalen per
film.
De priemgetallen die rond die grenzen
liggen, liggen dus als het ware vast.
Dit houdt in dat je ergens bij het
20.000e priemgetal begint en bij het ~
eindigt.
Wiskundig gezien integreer je dus tussen
een range van mogelijkheden.
De kneep zit 'm in de afspraken die je
maakt per scene of per tijdseenheid
die een priemgetal benaderd qua
totaalsom.
De database of index is op deze manier
moeilijk over te sturen..maar je kunt de
generator ook standaardiseren.
En dit wil natuurlijk niemand want dat
is commercieel niet aantrekkelijk.
Zelfs met Win 98 SE en een cursus van de
LOI kom je er ook wel uit.
|
|
MatrixView
9-2-2005 23:34:00 |
[quote]Jij weet waarschijnlijk wel dat
een film een wis/natuurkundig maximum
heeft qua grootte.[/quote]
Grootte van wat? Aantal kleuren?
Resolutie? Speelduur? Tenzij je over
deze parameters afspraken maakt (grenzen
stelt), kan een film in principe
oneindig groot zijn. Dus verklaar je
nader.
[quote]Dit houdt in dat er een gem.
onder- en bovenwaarde is voor alle
signalen per film.[/quote]
Weer zo lekker vaag.... Welke signalen?
...Kleur? ...Geluidsfrequentie? En die
onder en bovenwaarde...? van wat? Het
aantal keer dat een signaal voorkomt? De
hoogte of duur van een gedigitaliseerd
"signaal"?
[quote]De priemgetallen die rond die
grenzen liggen, liggen dus als het ware
vast.
Dit houdt in dat je ergens bij het
20.000e priemgetal begint en bij het ~
eindigt.[/quote]
... Nog vager... Zolang ik niet weet wat
je met je "grenzen" bedoelt, ligt er
voor mij helemaal niks vast.
En wat is er zo speciaal aan het
20.000ste prime volgens jou?
[quote]Wiskundig gezien integreer je dus
tussen een range van mogelijkheden.
De kneep zit 'm in de afspraken die je
maakt per scene of per tijdseenheid
die een priemgetal benaderd qua
totaalsom. [/quote]
Nu mag je mij eens vertellen waarom je
denkt zo zeker te weten dat Sloot
gebruik maakte van priemgetallen en
andere vage dingen die je eruit flapt?
Sloot was geen wiskundige en rekenkracht
was ook niet erg super eind 90-er jaren.
[quote]De database of index is op deze
manier moeilijk over te sturen..maar je
kunt de generator ook standaardiseren.
En dit wil natuurlijk niemand want dat
is commercieel niet
aantrekkelijk.[/quote]
Alle nadelen van Sloot's uitvinding
(mocht ie werken) wegen niet af tegen de
voordelen.
Any major company would jump the
bandwagon in a heartbeat....
Maar al die commerciele aspecten
interesseren me geen drol, so let's just
skip that.
M'n bullshit-detector rinkelt nog
voordurend, mede doordat ik al meerdere
van die vage prime-number ideetjes
voorbij heb zien komen op de
verschillende fora en newsgroups...
Iedere week komt er wel weer zo'n flippo
die denkt/zegt ieder type data iteratief
te kunnen verkleinen... Als hen dan
uitgelegd wordt dat dat onmogelijk is
(met wiskundig bewijs) hoor je er niks
meer van... waarschijnlijk ruw uit de
droom ontwaakt. :-)
Vandaar mijn uitdaging voor jou (die nog
steeds staat): Weerleg "The Counting
Argument" (ookwel genoemd: "The
Pigeonhole Principle")
Iedereen die denkt data te kunnen
(blijven) verkleinen zou met deze stof
bekend moeten zijn. Look it up.
|
|
Cugel
10-2-2005 21:41:00 |
Om het wat eenvoudiger te maken:
Ieder pixel heeft een maximum waarde qua
kleur(soort) en diepte. bij een res. van
bijv. 800x 600
hebben dus al die pixels een bepaalde
waarde. Als je voor het gemak het geluid
per kanaal per seconde
bekijkt heb je daar ook een maximale en
minimale waarde in de bandbreedte zeg.
20 Hz - 20 kHz.
Bij de opname kun je dus al heel snel
een onder en bovenwaarde van de kleur en
diepte bepalen.
En dat is weer af te bepalen aan de hand
hoe je de verticale en horizontale
platen aanstuurt(stuurde) in de
tijd van Sloot. Hij heeft waarschijnlijk
een film bekeken op een osciloscope (
moet je ook eens doen ).
Zo'n osci geeft gelijk realtime een
gemmidelde weer en de onder- en boven
grens. Vergelijk dit met het
dichstbijzijnde priemgetal ( dat 20000e
was zomaar een voorbeeld ) en voila. Het
is niet de data die je
bekijkt maar de waarde ervan die achter
elkaar "het scherm op wordt geschoten".
Dit doe je in zulke hapjes dat je niet
in de knoei komt met je refreshrate
Vraag maar eens aan je collega's wat er
zou gebeuren als je elk roosje van een
bloemkool een verschillend
kleurtje zou geven en dit proces omkeert
van groei naar krimpen. Als elk roosje
een pixelwaarde weergeeft zit er als het
ware een film aan de buitenkant. De
kunst is dus om elk roosje een ander
waarde te geven....in japan zijn ze al
heel erg ver hiermee en daar hebben ze
ook al de link gelegd tussen DNA en
priem itteraties aangezwengeld door
low freq. radiation van stoffen die in
het gehele heelal voorkomen.
een film aan de buitenkant
Waarschijnlijk moet het proces van
waarde generaties wel omgedraaid worden
van de meeste fenomenen opdat het
natuurlijk blijft. We zijn gewoon
verkeerd om begonnen. |
|
MatrixView
11-2-2005 0:32:00 |
>Om het wat eenvoudiger te maken:
Duidelijker. Daar gaat het om. En
eenvoud maakt de zaak duidelijker. Maar
goed, I'll play your game... kijken waar
we uitkomen... mijn vermoeden en logica
zegt me dat me dat we eindigen zoals
iedere discussie over "oneindige
compressie"... maar ik ben benieuwd of
je me ergens kunt verrassen... ik sta
ervoor open, maar ik zie 't niet
gebeuren...
>Ieder pixel heeft een maximum waarde
qua kleur(soort) en diepte. bij een res.
van bijv. 800x 600
hebben dus al die pixels een bepaalde
waarde. Als je voor het gemak het geluid
per kanaal per seconde
bekijkt heb je daar ook een maximale en
minimale waarde in de bandbreedte zeg.
20 Hz - 20 kHz.
Ok, laten we in deze thread voor het
gemak een film van 800x640 in 32 bits
kleur aannemen. 25 frames per sec.
Speelduur 100 minuten. De macroblokken
houden we even op 16x16 pixels (dus
50x40 blokken per frame en 4 bytes per
pixel). Geluid laten we voor 't gemak
even achterwege. OK?
>Bij de opname kun je dus al heel snel
een onder en bovenwaarde van de kleur en
diepte bepalen.
Als je 1 pixel dat pikzwart is treft in
een blok nemen we een waarde van 0 aan
voor die pixel. Als in datzelfde blok
een fel-witte pixel voorkomt heeft die
de waarde 2^32. De onderwaarde is dan 0
en de bovenwaarde 2^32ste-1. (Ik begrijp
dat dit een extreem voorbeeld is, want
de meeste blokken zullen een onder en
bovenwaarde hebben die niet zo heel ver
van elkaar liggen, vanwege de grote
correlatie inter en intra blok en frame
(scene) gewijs.)
>En dat is weer af te bepalen aan de
hand hoe je de verticale en horizontale
platen aanstuurt(stuurde) in de
tijd van Sloot. Hij heeft waarschijnlijk
een film bekeken op een osciloscope (
moet je ook eens doen ).
Zo'n osci geeft gelijk realtime een
gemmidelde weer en de onder- en boven
grens. Vergelijk dit met het
dichstbijzijnde priemgetal ( dat 20000e
was zomaar een voorbeeld ) en voila. Het
is niet de data die je
bekijkt maar de waarde ervan die achter
elkaar "het scherm op wordt geschoten".
Ok, dat hij wel eens een film bekeken
heeft op een oscilloscope is zeer
aannemelijk. TV-reparateurs hebben vaak
zo'n ding tussen hun gereedschap. Dus we
hebben nu een extreme onder en
bovenwaarde van 0 resp. (2^32)-1. Let
wel dat als je zoals jij zegt met
gemiddelden gaat werken, je geen exacte
registratie doet en dus LOSSY gaat
compressen! Laten we het exact houden
(LOSSLESS), dus wat ga je doen met je
"gemiddelden"? Als je alleen de
gemiddelde boven en onderwaarde opslaat
van kleuren in een macroblok, weet je
nog bar weinig over de kleurwaarde van
iedere pixel binnen het macroblok (wat
nodig is voor een exacte weergave)...
dus wat ga je doen? De gemiddelden zijn
alleen handig voor 't verkleinen van het
verschil van iedere pixel-kleurwaarde.
Wat bedoel je met de horizontale en
vericale platen? De macroblokken?
Voordat we elkaar begrijpen moeten we
eerst dezelfde taal spreken...
>Dit doe je in zulke hapjes dat je niet
in de knoei komt met je refreshrate
Wat bedoel je? 1 Hapje = 1 Macroblok? En
met refreshrate? = na exact 16x16 pixels
een nieuwe boven en onderwaarde
registreren??? Dus... wat heb jij nu en
hoe ga je verder? Wat sla jij op en op
welke wijze? Wees zo simpel en duidelijk
mogelijk aub. dat scheelt verwarring en
dus tijd. Bovendien kan iedereen het dan
volgen.
>Vraag maar eens aan je collega's wat er
zou gebeuren als je elk roosje van een
bloemkool een verschillend
kleurtje zou geven en dit proces omkeert
van groei naar krimpen. Als elk roosje
een pixelwaarde weergeeft zit er als het
ware een film aan de buitenkant. De
kunst is dus om elk roosje een ander
waarde te geven....in japan zijn ze al
heel erg ver hiermee en daar hebben ze
ook al de link gelegd tussen DNA en
priem itteraties aangezwengeld door
low freq. radiation van stoffen die in
het gehele heelal voorkomen.
een film aan de buitenkant.
Waarschijnlijk moet het proces van
waarde generaties wel omgedraaid worden
van de meeste fenomenen opdat het
natuurlijk blijft. We zijn gewoon
verkeerd om begonnen.
First things first.... Laten we nog even
niet gaan filosoferen, maar bij het
voorbeeld blijven. :-)
Till next time.
|
|
Cugel
12-2-2005 22:45:00 |
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 |
|
Drazic
14-2-2005 17:14:00 |
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 :-p
|
|
Cugel
14-2-2005 22:57:00 |
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.
[/quote] |
|
MatrixView
15-2-2005 1:05:00 |
[quote]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.
[/quote]
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. |
|
Drazic
15-2-2005 10:32:00 |
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 :-) )
|
|
weertj
15-2-2005 12:58:00 |
[quote]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 :-) )[/quote]
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
|
|
Cugel
15-2-2005 23:01:00 |
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/aansluiting/priemgetallen.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 ).
|
|
Drazic
16-2-2005 13:17:00 |
> 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 :-p En als jij um
wel hebt ben ik zeer benieuwd en wil
ik je graag helpen :-p 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/aansluiting/priemgetallen.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
|
|
MatrixView
16-2-2005 20:26:00 |
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-faq/part1/section-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
[quote]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)?[/quote]
'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? |
|
Cugel
16-2-2005 21:11:00 |
[quote]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
|
|
MatrixView
16-2-2005 22:03:00 |
[quote]
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
[/quote]
Lieve schat, ik denk dat je nog eens
naar de testbank moet, want ook dit zal
je niet veel winst geven na een paar
iteraties. Dat komt omdat iedere vorm
van data ná een kleinere transformatie
van diezelfde data relatief steeds meer
informatie bevat. Het klote hiervan is
dat je data dan gemiddeld steeds
moeilijker kleiner te transformeren valt
in de volgende iteratie...
Ik vraag me nog maar 1 ding af: Beweer
jij iedere willekeurige data met "jouw"
methode te kunnen verkleinen (iteratief
zelfs, zoals je zegt) en van daaruit
weer tot de exacte originele data te
kunnen komen?
P.S. Zovelen zijn je voorgegaan met
eenzelfde idee. Het is op zich een mooi
streven, want er spreekt hoop uit, maar
wiskunde liegt nou eenmaal niet... Ik
begrijp je koppige enthousiasme wel,
maar ja...
I was once a believer too.... tòt dat f*cking
duivengat! Ignorance is bliss... :-)
Succes. |
|
Drazic
18-2-2005 18:44:00 |
@Matrix:
Volgens mij heeft Sloot himself
gezegd dat het lossless zou zijn?
Bovendien zou zijn vinding voor
alle vormen van data werken,
maar niet alles kun je lossy opslaan.
Dus het moet wel lossles zijn.
btw, kijk hier eens is wel interessant:
http://www3.sympatico.ca/mt0000/bicom/bicom.html
|
|
MatrixView
18-2-2005 21:49:00 |
[quote]@Matrix:
Volgens mij heeft Sloot himself
gezegd dat het lossless zou zijn?
Bovendien zou zijn vinding voor
alle vormen van data werken,
maar niet alles kun je lossy opslaan.
Dus het moet wel lossles zijn.
btw, kijk hier eens is wel interessant:
http://www3.sympatico.ca/mt0000/bicom/bicom.html
[/quote]
Hoi Drazic,
Thanx for the link, maar ik kende 'm al...
datacompressie is een beetje een hobby
van me... :-)
Grappig hè, die eigenschap van (de PPM
variant) BiCOM... je kunt ook een
normale file zien als gecompresste file
en daarmee gaan decompressen...
Ja, over Sloot en (zijn) uitspraken...
Ik zou 't graag geloven, maar helaas is
dat niet mogelijk... je kan niet
-iedere- data-file lossless tot 1024
bytes terugbrengen (ook niet met behulp
van 400MB generic database)... zie
bewijs in deze thread.
Maar dit kan wellicht wel als je lossy
compresst... (alleen laat de kwaliteit
dan waarschijnlijk erg te wensen
over)... en het zou alleen voor
(bewegende) beelden en geluid kunnen...
Fouten in tekst en binaries zijn
ongeoorloofd.
De repa-base zou dus wel lossless
geweest moeten zijn, maar had
waarschijnlijk niet zo'n geweldige
compressie-ratio)
Het zou wellicht ook kunnen als de
database niet generic is. (dan heb je
dus ook een database-verstuur-probleem)
Zelf denk ik dat het een combinatie is
van beiden. Sloot's database was
waarschijnlijk NIET generic en hij
compresste ook NIET lossless...
(Hij/iemand) heeft dus een "beetje"
gejokt... (Wat toch echt niet ondenkbaar
is voor iemand die diep in de schulden
zit en zich met een leugen daaruit zou
kunnen redden). Maar goed, dat is mijn
mening.
Zou Sloot dan nog wel een interessante
uitvinding hebben? Dat denk ik wel, want
tegenwoordig worden de overeenkomsten
van micro-stukjes film/beeld/geluid
tussen verschillende films nog steeds
niet (slim) gecodeerd.
Sloot deed dit wel in zijn codebook
(database). Hij sloeg alle
gedetailleerde onderdelen van een aantal
films maar eenmalig op (dezelde (of
gelijkende) onderdelen, kregen eenzelfde
code).
Wat betreft het lossy verhaal:
Je zou voor de grap 's even 1 van Sloots
verwezen patenten moeten doornemen. Het
beschrijft een Quantifier die gelijkende
stukjes data eenzelfde code geeft (niet
zijn patent). Er werd ook van nog meer
andere slimme ideeen (patenten) gebruik
gemaakt. De combinatie is waarschijnlijk
uniek.
Groet,
MatrixView. |
|
Cugel
21-2-2005 21:54:00 |
Wat betreft het lossy verhaal:
Je zou voor de grap 's even 1 van Sloots
verwezen patenten moeten doornemen. Het
beschrijft een Quantifier die gelijkende
stukjes data eenzelfde code geeft (niet
zijn patent). Er werd ook van nog meer
andere slimme ideeen (patenten) gebruik
gemaakt. De combinatie is waarschijnlijk
uniek.
Groet,
MatrixView.[/quote]
Heeft één van jullie wel eens wat
gelezen van over kleurenpercentages en
de maximale verhoudingen daarvan.
Elektrisch gezien kom je dan op een wel
heel erg interessante database uit...wel
5 om te verstaan. Voor het geluid
doe je exact hetzelfde. Optisch gezien
zet je die 5 tegenover elkaar. Je geeft
elke key ( pixel ) een tijdcode mee.
En die tijdcode daar gaat het om op de
keycard. Het enige dat je uitrekend zijn
die tijdcodes en dat loopt gewoon op
net als van 1 t/m 10.000.000
tellen....en de scenes geef je ook weer
in de database als een reeks van een
waarde.
Jullie begrepen al dat juist die waarde
een eitje is om weer te geven als
priemgetal.
Als je dus een fout in de reeks maakt
krijg je helaas wel een wending in de
film die de regiseur nog niet bedacht
had.
Geschiedenis is dus maar net afhankelijk
hoe je het weergeeft of wie het
geschreven heeft....
|
|
Drazic
22-2-2005 12:57:00 |
@MatrixView:
[quote]Thanx for the link, maar ik kende
'm al... datacompressie is een beetje
een hobby van me... :-)
Grappig hè, die eigenschap van (de PPM
variant) BiCOM... je kunt ook een
normale file zien als gecompresste file
en daarmee gaan decompressen...[/quote]
Precies! En als je de output daarvan nou
ook weer eens zou zien als een
gecompressede file, en dat
weer gaat uitpakken, en de output
daarvan weer uitpakken, etc. dan kom je
na 100x herhalen op een
heeeeeeel groot bestand uit... Volgens
jou therorie kan ik dit bestand nooit in
1024 bytes kwijt. Volgens
de wet van Shannon of het pigeon hole
effect ook niet. Maar als ik het kleine
bestand waar ik mee
begonnen ben + het aantal herhalingen
opsla, is dat misschien amper 1024
bytes, en daar kan ik dus
foutloos een bestand van een paar gig
mee genereren. Het probleem is alleen
hoe je dit process
omdraait zodat je zelf het bestand van 1
gig voor het kiezen hebt, en
bruteforcend een weg zoekt
naar het meest optimale kleine bestand
:-p
Je zou ook bijv. een md5 hash van een
groot databestand op kunnen slaan,
vervolgens bruteforcen
(eventueel vanaf een meegegeven offset)
tot je bij de goede md5+data uitkomt, en
dan opslaan
hoeveel collisions (=zelfde md5 met
andere brondata) je onderweg bent tegen
gekomen tot de md5
en data kloppend zijn. De ontvanger
hoeft nu alleen maar de md5 hash +
collisionsaantal te ontvangen
en zou dan collisions kunnen gaan
genereren totdat de collisioncount
bereikt is, en voila data is weer
terug in orginele staat. Heb dit nooit
uitgeprobeerd, en kost misschien wel
veel cpu, maar is misschien
een ideetje? Er worden vrijwel geen
collisions gevonden voor hashes als MD5
dus waarschijnlijk blijft
de collisioncount die je moet opslaan
vrij laag altijd (misschien wel meestal
1 of 2)
[quote]Heeft één van jullie wel eens wat
gelezen van over kleurenpercentages
en de maximale verhoudingen
daarvan.[/quote]
Ja... Sloot had het over 3D coderen ipv
de gebruikelijke 2D. Mijn idee is dat
hij over 3D
sprak omdat hij behalve de RGB waardes
van een pixel ook de verandering in
intensiteit
opsloeg oid (bedoel je dat met
kleurenpercentages?)
[quote]Elektrisch gezien kom je dan op
een wel heel erg interessante database
uit...[/quote]
Verklaar je nader...
[quote]Je geeft elke key ( pixel ) een
tijdcode mee. En die tijdcode daar gaat
het om op de
keycard. Het enige dat je uitrekend zijn
die tijdcodes en dat loopt gewoon op net
als van
1 t/m 10.000.000 tellen....en de scenes
geef je ook weer in de database als een
reeks van
een waarde. Jullie begrepen al dat juist
die waarde een eitje is om weer te geven
als priemgetal.[/quote]
Ik snap het nut van je tijdcode nog niet
echt... Normaal staan de frames toch
zowiezo al gesorteerd
op tijd zou je zeggen... En je pixels
dus ook...Enigste reden om een tijdcode
op te gaan slaan (die
ik kan bedenken) is wanneer je sommige
frames/pixels weglaat, en de film toch
nog synchroon met
het orgineel wilt kunnen afspelen, of
wil je alleen nog maar tijdcodes opslaan
en niet de bijhorende kleuren?
Die tijdcodes kun iid heel efficient
opslaan, maar je hoe kom je aan de
database die je de goede kleur vertelt
voor elke tijdcode? Kortom, ik snap je
plan nog niet helemaal, maar ben erg
benieuwd naar wat je bedoeld :-)
|
|
MatrixView
22-2-2005 14:18:00 |
[quote]@MatrixView:
Precies! En als je de output daarvan nou
ook weer eens zou zien als een
gecompressede file, en dat
weer gaat uitpakken, en de output
daarvan weer uitpakken, etc. dan kom je
na 100x herhalen op een
heeeeeeel groot bestand uit... Volgens
jou therorie kan ik dit bestand nooit in
1024 bytes kwijt. Volgens
de wet van Shannon of het pigeon hole
effect ook niet. Maar als ik het kleine
bestand waar ik mee
begonnen ben + het aantal herhalingen
opsla, is dat misschien amper 1024
bytes, en daar kan ik dus
foutloos een bestand van een paar gig
mee genereren. Het probleem is alleen
hoe je dit process
omdraait zodat je zelf het bestand van 1
gig voor het kiezen hebt, en
bruteforcend een weg zoekt
naar het meest optimale kleine bestand
:-p [/quote]
Hoi Drazic,
:-) Het is een leuk idee dat je oppert,
maar je vergeet 1 ding... Jij begint al
met een file die kleiner is dan 1024
bytes (dus een compressed file waarvan
je al weet dat die na N x compressen
kleiner zal zijn dan 1024 bytes). Maar
dat wil natuurlijk NIET zeggen dat
-IEDERE- file tot kleiner dan 1024 bytes
gecompressed kan worden.
Probeer maar eens ieder mogelijk bestand
van 1025 bytes in 1024 bytes te
stoppen... Dat zijn 2^(1025*8)
verschillende files... en die kunnen
helaas niet allemaal uniek zijn binnen
2^(1024*8) files...
OF
Neem iedere willekeurige file en ga die
met Bicom iteratief compressen... Je
zult er dan bij bijna iedere file al
snel achter komen, dat je compressed
file GROTER begint te worden na een
aantal iteraties... Het aantal files dat
dus lossless in 1024 bytes gepakt kan
worden is dus enorm klein (t.o.v. ieder
willekeurig ander bestand)
[quote]
Je zou ook bijv. een md5 hash van een
groot databestand op kunnen slaan,
vervolgens bruteforcen
(eventueel vanaf een meegegeven offset)
tot je bij de goede md5+data uitkomt, en
dan opslaan
hoeveel collisions (=zelfde md5 met
andere brondata) je onderweg bent tegen
gekomen tot de md5
en data kloppend zijn. De ontvanger
hoeft nu alleen maar de md5 hash +
collisionsaantal te ontvangen
en zou dan collisions kunnen gaan
genereren totdat de collisioncount
bereikt is, en voila data is weer
terug in orginele staat. Heb dit nooit
uitgeprobeerd, en kost misschien wel
veel cpu, maar is misschien
een ideetje? Er worden vrijwel geen
collisions gevonden voor hashes als MD5
dus waarschijnlijk blijft
de collisioncount die je moet opslaan
vrij laag altijd (misschien wel meestal
1 of 2) [/quote]
Helaas...MD5 bevat niet de INFORMATIE
uit het originele bestand... Uit
(alleen) een MD5 bestand kun je dus niet
het origineel toveren...
Tenzij MD5 voor iedere file uniek is
(wat niet zo is) en er een database
bestaat waar alle mogelijke files in
staan (en dat is onmogelijk) met
bijbehorende MD5 waarden, begin je hier
niks mee.
[quote]Heeft één van jullie wel eens wat
gelezen van over kleurenpercentages
en de maximale verhoudingen
daarvan.[/quote]
@Cugel
Nee. Maar ik vrees dat jij ons er
"alles" over gaat vertellen in je eigen
vage onbegrijpelijke uitleg.
[quote]Elektrisch gezien kom je dan op
een wel heel erg interessante database
uit...
Je geeft elke key ( pixel ) een tijdcode
mee. En die tijdcode daar gaat het om op
de
keycard. Het enige dat je uitrekend zijn
die tijdcodes en dat loopt gewoon op net
als van
1 t/m 10.000.000 tellen....en de scenes
geef je ook weer in de database als een
reeks van
een waarde. Jullie begrepen al dat juist
die waarde een eitje is om weer te geven
als priemgetal.[/quote]
Zoals Drazic al zei: leg uit... (liefst
met links en duidelijke taal, want de
onbegrepen New Wave "professor"
uithangen, dat kan iedereen.)
|
|
Drazic
22-2-2005 15:19:00 |
@MatrixView
[quote] Helaas...MD5 bevat niet de
INFORMATIE uit het originele bestand...
Uit (alleen) een MD5 bestand kun je dus
niet het origineel toveren... [/quote]
Uit ALLEEN een MD5 niet, maar de truuk
zit hem in dat je het collision nummer
ook op slaat. Ik zal me ff nader
verklaren (in tegenstelling tot Cugel
lol),
stel ik heb de volgende string: "MatrixView"
en daar bereken ik de MD5 voor.
Vervolgens ga ik voor string "AAAAAAAA",
"AAAAAAAB" , "AAAAAAAC" etc. de
hashes berekenenen... Tot ik aan de
orginele string kom ("MatrixView" in dit
geval, ongeveer op de helft, dus hoef
niet door te gaan tot "zzzzzzzz").
Als ik noteer hoeveel strings ik
onderweg tegen ben gekomen met dezelfde
MD5 hash als "MatrixView" (in veel
gevallen zijn dit er 0 en anders 1 of
2),
dan kan ik de tekst weer uitpakken door
vanaf een vast punt strings te gaan
genereren ("AAAAAAA" in dit voorbeeld)
en als ik de gezochte md5 hash tegenkom
bij een van die strings, hoog ik het
collision nummer weer op zoals
hierboven,
en als dat nummer gelijk is aan het
nummer dat doorgegeven is door de
compressor, dan weet ik dat de huidige
string ("MatrixView") de goede moet
zijn....
[quote]Tenzij MD5 voor iedere file uniek
is (wat niet zo is)[quote]
Daar dient dat extra getalletje juist
voor dat naast elke md5 word opgeslagen
door de compressor, ik noem het de 'collision
count' vanaf nu :-p
De vraag is nu alleen of een MD5 +
Collision count minder dataopslag
vereist
als het orgineel. Ik denk van wel, maar
heb dit nooit uitgerekend of getest tot
nu toe...
|
|
MatrixView
22-2-2005 18:59:00 |
[quote] Daar dient dat extra getalletje
juist voor dat naast elke md5 word
opgeslagen
door de compressor, ik noem het de 'collision
count' vanaf nu :-p
De vraag is nu alleen of een MD5 +
Collision count minder dataopslag
vereist
als het orgineel. Ik denk van wel, maar
heb dit nooit uitgerekend of getest tot
nu toe... [/quote]
Hey Drazic,
Bedankt voor je duidelijke uitleg. Dat
zouden meer mensen moeten doen.
Praktisch gezien zijn computers niet
snel genoeg om de "collision count" van
een file met een beetje grootte te
berekenen. Deze collision count is
namelijk (in tegenstelling tot wat je
denkt) ENORM groot als de MD5 file veel
kleiner is dan de originele file.
Nu theoretisch:
Neem dit hele simpele voorbeeld: stel je
voor dat er maar 256 orginele files
bestaan. Die zijn dus lossless
uncompressed op te slaan in 8 bits.
Laten we zeggen dat hun MD5 opgeslagen
wordt in 4 bits. (klinkt aardig, want
dat is 50% compressie)... Maar helaas
zijn er dan maar 2^4 = 16 verschillende
(unieke) MD5 files.
Nu, hoe groot is de collision count? Er
zijn dus 256 - 16 = 240 files die een
bijbehorende MD5 file hebben die exact
dezelfde is als van (in ieder geval) 1
andere originele file. Als het goed
verdeeld is, is je collision count
maximaal
240/16=15 en minimaal 0. En gemiddeld
heb je 'm dus te pakken bij (15+0)/2=7,5
(= tussen de 7 en de 8). Om de waarde
van de collision count op te slaan heb
je gemiddeld dus 3,5 bits (= 4 bits)
nodig.
Dus de MD5 + Collision Count zijn
gemiddeld op te slaan in 4 + 4 = 8
bits... (=zelfde als aantal orginele
files)
Kut hè...
In onze "echte" wereld komen we niet
veel md5 collisions tegen omdat we
praktisch gezien niet werken met iedere
mogelijke file. (Met z'n allen hebben we
zelfs maar een heel klein percentage van
alle mogelijke files).
|
|
Drazic
22-2-2005 20:47:00 |
@Matrix
[quote]Deze collision count is namelijk
(in tegenstelling tot wat je denkt)
ENORM groot als de MD5 file veel kleiner
is dan de originele file.[/quote]
Dat valt wel mee... Als je de data in
blokken van een bepaalde grootte
verdeeld, bijvoorbeeld 500 tekens, dan
kunnen collisions alleen binnen een
relatief kleine range optreden.
Bovendien hebben de collisions een heel
handige eigenschap die misschien
uitgebuit kan worden: de spreiding over
de range is heel erg regelmatig...!
[quote]Praktisch gezien zijn computers
niet snel genoeg om de "collision count"
van een file met een beetje grootte te
berekenen. [/quote]
Als je weer van bijv. 500 tekens
uitgaat, dan zou je alle mogelijke
hashes van data van 500 tekens in
een (hardwarematige?) lookup table
kunnen plaatsen, bovendien kost een hash
over kleinere blokken
berekenen veel sneller dan voor "een
file met een beetje grootte"....
[quote]Nu theoretisch:
<snip>
Dus de MD5 + Collision Count zijn
gemiddeld op te slaan in 4 + 4 = 8
bits... (=zelfde als aantal orginele
files)[/quote]
Bedankt voor het rekenwerk!
Waarschijnlijk heb je wel gelijk, maar
ik was maar een beetje aant brainstormen
in dit topic :-p Het enigste wat ik er
op aan wil merken is dat een MD5 die 50%
van de orginele data in beslag
neemt zeer zeldzaam is :-) Gaat vrijwel
altijd om minder dan een procent en toch
zijn er tot op heden nauwelijks
collisions gevonden.. Hoe verklaar je
dat? :-p Bovendien is de bloklengte van
mijn ideetje fixed, wat de kans op
collisions aanmerkelijk verminderd..
Laten we blijven zoeken :-p
|
|
Cugel
22-2-2005 21:37:00 |
[quote][quote][quote]
Een kleurendatabase kun je percentueel
verdelen in stapjes van 1% per kleur.
Per kleur dus maar 100 plaatsen, lagere
percentages zie je niet!
Per pixel ( oplopend per 1/seconde
afhankelijk van de refreshrate ) heb je
dus altijd
een bepaalde waarde die wordt ingelezen
tijdens het filmen.
Als we de R-database nemen van bijv.
10%R per pixel hoef je daar alleen maar
aan te
geven welke seconde(s) dat voorkomt.
Deze reeks daar gaat het om...die loopt
gewoon
als counter van 0 naar hoe lang de film
duurt. Per database geef je dus eerst
aan wanneer
ze "op mogen treden". Het grappige is
dat het complement van de kleuren
zichzelf uitrekend
tot 100% tenzij R of G beide al 100%
aangeven. Als er dus niets veranderd aan
een specifieke
pixel sla je dus ook niets op. bij bijv.
een res van 800 x 600 heeft pixel 1
(~sec =1 ) de positie
linksboven op een tv. Na ~sec=480000 heb
je de pixelwaarde van de pixel
rechtsonder berekend.
~sec=4800001 is weer linksboven etc.
etc. Het enige wat je dus moet doen is
opslaan bij welke pixel
de percentuele eigenschappen horen. Dit
ziet er gek genoeg bijna in 100% van de
gevallen uit als
een piramide vorm en de "secondeplekken"
kun je weer vergelijken met een
priemgetal.
In de tussentijd van de refreshrate heb
je dus tijd om te rekenen, maar dan wel
voor elke kleur appart.
Op de X-as staat het percentage van de
kleur, op de Y-as de helderheid en op de
Z-as de tijdstippen
dat het voorkomt. Probeer het eens uit
op een velletje papier of in Excel. Je
ziet dat er een max en min
is aan de waarden. Het eerste plaatje
moet dus opgeslagen worden juist op de
64Kb USB stick en heeft
een nr. om deze op te roepen. De strings
voor de settings van de X, Y, Z waarde
gaan als priemgetalnr
door. De kneep zat/zit 'm dus ook in de
kwaliteit van dat eerste plaatje.
Je moet je wel voorstellen dat juist het
afstellen van kleuren en de
eigenschappen van een kleurenkanon
Jan Sloots' paradepaardje waren. Door
het uitlezen van de tv kon hij zo zien
waar de fout zat.
Elke tv had zijn eigen
karaktereigenschappen...vandaar ook dat
je eens een film door een osciloscoop
moet
kijken...dan zie je meteen wat er gaande
is.
|
|
MatrixView
22-2-2005 22:06:00 |
Hi again,
[quote]
Dat valt wel mee... Als je de data in
blokken van een bepaalde grootte
verdeeld, bijvoorbeeld 500 tekens, dan
kunnen collisions alleen binnen een
relatief kleine range optreden.
Bovendien hebben de collisions een heel
handige eigenschap die misschien
uitgebuit kan worden: de spreiding over
de range is heel erg regelmatig...!
Als je weer van bijv. 500 tekens
uitgaat, dan zou je alle mogelijke
hashes van data van 500 tekens in
een (hardwarematige?) lookup table
kunnen plaatsen, bovendien kost een hash
over kleinere blokken
berekenen veel sneller dan voor "een
file met een beetje grootte"....
[/quote]
Hoe groter de md5 file, hoe kleiner het
aantal collisions en andersom... :-)
[quote]
Bedankt voor het rekenwerk!
Waarschijnlijk heb je wel gelijk, maar
ik was maar een beetje aant brainstormen
in dit topic :-p Het enigste wat ik er
op aan wil merken is dat een MD5 die 50%
van de orginele data in beslag
neemt zeer zeldzaam is :-) Gaat vrijwel
altijd om minder dan een procent en toch
zijn er tot op heden nauwelijks
collisions gevonden.. Hoe verklaar je
dat? :-p Bovendien is de bloklengte van
mijn ideetje fixed, wat de kans op
collisions aanmerkelijk verminderd..
Laten we blijven zoeken :-p
[/quote]
Geen dank. De 50% was een voorbeeld om
te laten zien hoevel collisions er
kunnen optreden bij zelfs een relatief
zeer grote md5 file. ... de collisions
bij een relatief kleine md5 file zijn
nog veel groter!!!
Ik denk dat je je nog steeds verkijkt
hierop.... Welke methode je ook gebruikt
om data lossless te verkleinen (Hetzij
de md5 methode, hetzij de primenumber,
hetzij welke bekende of nog onbekende
compressie methode dan ook) Het is
ONMOGELIJK om IEDERE file van N bits,
lossless te verkleinen tot N-1 bits.
(=pigeonhole)
Zoals ik al zei kom je in het dageliijks
leven bij bestaande files niet veel
collisions tegen. Omdat zelfs ALLE
bestaande files op de wereld maar een te
verwaarlozen percentage is van alle
MOGELIJKE (bestaande EN (nog)
onbestaande) files. Dus ook de
collisions die men tegenkomt zijn maar
een te verwaarlozen percentage van het
aantal mogelijke collisions.
Kortom, tenzij je alle bestaande files
in kaart brengt met hun md5('s) EN
iedereen verbiedt om nog nieuwe files
aan te maken (da's lastig hoor! ;-)),
zal jouw md5 compressie methode helaas
niet gaan werken...
Ik wil best met je meedenken hoor, maar
zolang je nog geloofd/hoopt dat er een
methode bestaat die iedere file lossless
kan verkleinen heeft 't weinig zin. Vaak
duurt 't even voor dat iemand wil
geloven dat 't echt niet kan...
I've been there...
Lossy EN / OF een beperkte dataset, is
een totaal ander verhaal (dat is WEL
mogelijk). |
|
MatrixView
22-2-2005 22:44:00 |
[quote]
Een kleurendatabase kun je percentueel
verdelen in stapjes van 1% per kleur.
Per kleur dus maar 100 plaatsen, lagere
percentages zie je niet!
Per pixel ( oplopend per 1/seconde
afhankelijk van de refreshrate ) heb je
dus altijd
een bepaalde waarde die wordt ingelezen
tijdens het filmen.
[/quote]
@Cugel
Dat is al een stuk duidelijker (hou
vast!), hoewel ik nog niet helemaal kan
overzien hoe inventief of bruikbaar dit
is voor -iedere- soort data. Het klinkt
wel erg "lossy" die procentuele
kleurverdeling, vandaar dat 't ook mijn
aandacht trekt. Bovendien, een Quantizer
is ook een "verdeler" Maar goed,
100x100x100 = 1 miljoen mogelijke
kleuren... da's veel, maar genoeg?
Wat gebeurt er met je data als je als
origineel ruis treft ipv een zeer
correlerend video beeld? Al eens
geprobeerd?
Hoeveel en welk rekenwerk heeft je
methode nodig? Waar liggen de
moeilijkheden en wat denk je eraan te
doen? |
|
Drazic
23-2-2005 0:43:00 |
@Matrix
Dank voor de verheldering :-p
En wat betreft Cugel's idee:
Het hoeft helemaal niet voor
alle data te werken..! Als dit
zou kloppen wat hij zegt is
het al revolutonair genoeg
denk ik, ken verder ook
geen andere videocompressie
die zo werkt!! Jij wel?
@Cugel
Ben heel benieuwd naar die
Excel sheets... Want vooral
die pyramide vorm zou heel
goed te compressen zijn!!
Ik heb nu geblowed, maar
zal morgen nog eens rustig
(en nuchter) je verhaal
nalezen, en misschien dat
ik er dan meer op aan te
merken heb, maar tot nu
toe wil ik niets liever dan
meehelpen aan je research!!!
Heb zo'n voorgevoel dat
we op de goede weg zitten :-)
Sloot zou trots op je zijn :-p
|
|
MatrixView
23-2-2005 9:21:00 |
[quote]En wat betreft Cugel's idee: Het
hoeft helemaal niet voor alle data te
werken..! Als dit zou kloppen wat hij
zegt is het al revolutonair genoeg denk
ik, ken verder ook geen andere
videocompressie die zo werkt!! Jij wel?
[/quote]
True, het hoeft niet persé voor alle
data te werken. De meeste bestaande
codecs zijn gericht op een bepaald type
data. (bv mp3, xvid en de betere
aanstormende AAC en AVC). Of het
revolutionair is kan ik nu nog niet
beoordelen. Ook niet of het uberhaupt
werkt... Erg positief ben ik dus (nog)
niet.
[quote]
@Cugel
Ben heel benieuwd naar die Excel
sheets... Want vooral die pyramide vorm
zou heel goed te compressen zijn!! Ik
heb nu geblowed, maar zal morgen nog
eens rustig (en nuchter) je verhaal
nalezen, en misschien dat ik er dan meer
op aan te merken heb, maar tot nu toe
wil ik niets liever dan meehelpen aan je
research!!! Heb zo'n voorgevoel dat we
op de goede weg zitten :-) Sloot zou
trots op je zijn :-p
[/quote]
Ok, snel ff een "grouphug" dan!
Geintje.... Nee, sorry ik weet echt niet
of Cugel hier op de "goede weg" zit.
Maar dat komt misschien omdat ik nooit
een blowtje rook... ;-)
Ben alleen geintrigeerd omdat de methode
"lossy" lijkt te zijn, maar tegelijk
verwacht ik ook nogal wat problemen die
ervoor zorgen dat de methode wellicht
helemaal niet werkt. Ben bv erg benieuwd
hoe Cugel de methode generic denkt te
gaan maken...
Het is al een stukje duidelijker waar ie
heen wil, maar zolang ik nog niet alles
begrijp, kan ik hem niet helpen.
FF afw88 dus, voordat we conclusies
trekken... |
|
Drazic
23-2-2005 20:27:00 |
[quote] FF afw88 dus, voordat we
conclusies trekken... [/quote]
Ben al de hele dag aant afw88 :-p Hoop
niet Cugel plots een hartaanval heeft
gekregen...
|
|
Cugel
23-2-2005 23:21:00 |
[quote]
Een hartaanval...nee ik niet hoor. En
blowen doe ik ook niet. Een mindfuck kun
je ook krijgen
als je het boek der iluminanten leest en
is waarschijnlijk goedkoper en gezonder!
Nu over het rekenwerk. Staan jullie wel
eens stil dat deze methode van Jan heel
veel lijkt op het Seti
project ? Er wordt geprobeerd om
allerlei signalen te doorgronden of ze
een bepaalde betekenis hebben.
Er wordt vanuit gegaan dat deze signalen
een bepaalde logica moeten bezitten om
intelligentie te herkennen
over en weer. Met Jans' methode kun je
als het ware slechts één ping geven en
alle data over geseind hebben
zonder dat de ontvanger doorheeft dat
dat een bepaalde waarde heeft als je
geen afspraak had gemaakt met de
"overkant".
Maw. het rekenwerk begint pas echt als
het Ram geheugen vol zit en er een soort
voorlooptijd met beeld ontstaat.
Het opgebouwde beeld moet dus altijd
binnen de refreshtijd berekend zijn.
Kennen jullie de programmeertaal FUP of
AWL nog uit de oudheid ? Zoek het eens
op en vraag je dan eens af waarom
Windows bestaat en waarom alles nog zo
traag is. Het antwoord om oneindig snel
en oneidig klein te gaan is er al (
lang)....maar in één keer geïntroduceerd
staat de hele economie die om IT is
opgebouwd op zijn kop en stort de
geldwereld in één keer in elkaar. De
taart is al lang gebakken en elke dag
wordt er een stukje van gegeten.
Helaas kan ik niet meer vertellen want
dan gooi ik mijn eigen glas in.
100495
|
|
MatrixView
24-2-2005 10:53:00 |
[quote]
Een hartaanval...nee ik niet hoor. En
blowen doe ik ook niet. Een mindfuck kun
je ook krijgen
als je het boek der iluminanten leest en
is waarschijnlijk goedkoper en gezonder!
Nu over het rekenwerk. Staan jullie wel
eens stil dat deze methode van Jan heel
veel lijkt op het Seti
project ? Er wordt geprobeerd om
allerlei signalen te doorgronden of ze
een bepaalde betekenis hebben.
Er wordt vanuit gegaan dat deze signalen
een bepaalde logica moeten bezitten om
intelligentie te herkennen
over en weer. Met Jans' methode kun je
als het ware slechts één ping geven en
alle data over geseind hebben
zonder dat de ontvanger doorheeft dat
dat een bepaalde waarde heeft als je
geen afspraak had gemaakt met de
"overkant".
Maw. het rekenwerk begint pas echt als
het Ram geheugen vol zit en er een soort
voorlooptijd met beeld ontstaat.
Het opgebouwde beeld moet dus altijd
binnen de refreshtijd berekend zijn.
Kennen jullie de programmeertaal FUP of
AWL nog uit de oudheid ? Zoek het eens
op en vraag je dan eens af waarom
Windows bestaat en waarom alles nog zo
traag is. Het antwoord om oneindig snel
en oneidig klein te gaan is er al (
lang)....maar in één keer geïntroduceerd
staat de hele economie die om IT is
opgebouwd op zijn kop en stort de
geldwereld in één keer in elkaar. De
taart is al lang gebakken en elke dag
wordt er een stukje van gegeten.
Helaas kan ik niet meer vertellen want
dan gooi ik mijn eigen glas in.
100495
[/quote]
And the saga ends... :-)
Hans Klok kan er een puntje aan
zuigen...Wat een hocus pocus allemaal
weer... "ONEINDIG klein en snel"...
Je zou jezelf eens moeten horen... en
dan gaan nadenken WAT je eigenlijk
zegt... :-)
Seti... dmv distributed computing
proberen orde in chaos te ontdekken...
quite a task...hahaha!
"The Illuminati"... I've read it. Leuk
als je een "conspiracy"-fan bent... veel
meer dan een glimlach bezorgde het me
niet. Verre van een mindfuck.
FUP en AWL wordt nog steeds gebruikt bij
het programmeren van PLC's... leuke
hobby... als je tijd teveel hebt...
Je wilt niet meer vertellen, maar wat
mij betreft heb ik al genoeg onzin
gehoord.
De enige enigszins "interessante" post
van je, was die over kleurpercentages.
i7083170 |
|
Drazic
24-2-2005 12:14:00 |
Zou het wel jammer vinden als het hier
eindigd...
Ben benieuwd naar die pyramide vorm en
andere claims |
|
Drazic
25-2-2005 19:52:00 |
Cugel where are u?? |
|
Cugel
25-2-2005 23:04:00 |
[quote]Cugel where are u??[/quote]
Waar ik ben spreken ze geen Nederlands,
dat maakt het wel makkelijker.
Die kleurendatabase is niet zo moeilijk.
Maak in een excelsheet 5 kolommen en per
kolom 50 rijen. De kolommen
heten R,G,B,W,Z per rij 2% kleur.
Aspraak is dat je de secondeteller na
100
sec weer bij nul laat beginnen. Elke set
t/m 100 is een "hapje" of frame.
Elke kleurwaarde per sec film leg je
vast op het percentage en zo stapelt het
her en
der op op die matrix. Stel je doet dit
met blokjes waar je aan de zijkant de
sec op schrijft.
Als je dan klaar bent heb je overal
torentjes. Zet alle getallen van de
blokjes per veld
naast elkaar en maak daar één getal van
en vergelijk dit met het meest nabij
gelegen priemgetal.
Elk hapje heeft een opvolgend nummer. De
laagste waarde van het aantal blokjes
vormt het kleinste
priemgetal in de database en de hoogste
waarde het hoogste priemgetal. Deze
priemgetallen geef je een
opvolgend nummer. De rest moeten jullie
met jullie kennis nu toch echt wel in
kunnen vullen.
Matrixview zal van nature al het
mogelijke bedenken om aan te tonen dat
het niet zal werken, terwijl het echt
veel minder moeite kost om het werkend
te maken...je moet het wel zelf zien en
werkend kunnen maken anders is de lol er
echt vanaf. |
|
MatrixView
26-2-2005 13:05:00 |
[quote] Matrixview zal van nature al het
mogelijke bedenken om aan te tonen dat
het niet zal werken, terwijl het echt
veel minder moeite kost om het werkend
te maken...je moet het wel zelf zien en
werkend kunnen maken anders is de lol er
echt vanaf.[/quote]
Met het bovenstaande, valt ook weer niks
te beginnen.
Hey...enne... ik ben niet degene die
maar "iets bedenkt"....! Dat doe jij! Ik
geef alleen feiten/bewijzen, voor dingen
die niet kunnen.
Gaf jij maar 's een keer een paar feiten
of een concreet algoritme (pseudocode is
ook goed) [Vergeet je niet de
DEcompressie!)
Nu jezelf niet gaan verschuilen achter:
"De lol is er echt af als je 't niet
zelf werkend kan maken". |
|
Cugel
26-2-2005 23:34:00 |
[quote][quote][quote]
Je/jullie zullen het echt zelf moeten
doen..en anders stopt het.
Eén tip; lees 1t/m4 noch eens terug maar
dan tussen de regels door.
100495 |
|
Cugel
26-2-2005 23:43:00 |
[quote][quote] Geen complot geen
esoterische bullshit.
Als je DNA opslaat en wacht op de juiste
parameters totdat het zichzelf uitpakt
zul je het op een bepaalde manier willen
coderen zoals nu het geval is met de
vorm van DNA zoals die in de natuur
voorkomt. Ergo moet er een trigger zijn
die overal in het heelal voorkomt en dat
is de low freq van... Het DNA klapt
zichzelf dan uit aan de hand van
parameters ( priemgetalgewijs ) en
groeit aan de hand van de combinaties
die de hoeveelheid van die trigger
uitzend.
"in leven" wordt de reeks aangepast maar
er wordt wel steeds gekoezen voor een
mogelijkheid die altijd al aanwezig is
geweest. Andersom werkt dit precies
hetzelfde.
In principe kun je dus ook een Hobbit
reconstrueren. Het is ook niet zo gek
dat iedereen anders denkt en doet maar
dit is wel gelimmiteerd aan het aantal
mogelijkheden per itteratie. Een reactie
als bovenstaand is dan ook niet
"vreemd".
[/quote]
Cugel, lieve jongen,
Laat ik nou toevallig dagelijks de
automatisering verzorgen in een lab vol
ontwikkellingsbiologen... I'm not
kidding!
En ik durf mezelf niet eens expert te
noemen op dat gebied... Maar jij weet
ècht niet waarover je praat, kolere zeg,
wat een ontzettende stierenpoep!
Whoahahaha!
Als ik jou was zou ik die jip-en-janneke
aflevering van Discovery, waarvan je 3
woorden hebt onthouden en vermengd met
je priemgetallen fetish, nog maar eens
goed bekijken. :-)
Dit forum heeft geen kloot meer met
Sloot's uitvinding te maken... Gelul in
de ruimte en gelul over Pieper. Jammer.
Logging Out.[/quote]
M; er zijn meer biologen die het
bovenstaande niet begrijpen en een
netwerkbeheerder die daar dan werkt
hoeft er dan ook niet vanuit te gaan dat
die biologen alles weten. Waar ik zit
weten we meer dan zij waarschijnlijk
ooit zullen
begrijpen. Vraag ze maar eens naar de
relatie tussen axiomen en files op
snelwegen en de relatie tussen cellen en
steden......
|
|
MatrixView
27-2-2005 11:07:00 |
[quote]
Je/jullie zullen het echt zelf moeten
doen..en anders stopt het.
Eén tip; lees 1t/m4 noch eens terug maar
dan tussen de regels door.
100495[/quote]
Wat er staat valt geen koek van te
bakken, laat staan dat we iets moeten
lezen/begrijpen wat er niet eens
instaat!
Je maakt hele stellige beweringen, maar
je verzand gewoon in je slechte/afwezige
uitleg, waardoor je ongeloofwaardig
wordt.
Ik denk dat je te lui bent om je (te)
vage theorie concreet uit te werken, dus
wil je ons het werk laten doen. Iets
concreets HEB je gewoon niet OF je bent
te angstig om het te geven, omdat je dan
voor lul staat als we het tegendeel
bewijzen.
Drazic kwam ook met een theorie over de
md5 methode, maar hij beweerde tenminste
niks stelligs. Dus was het ook geen
issue toen bleek dat 't niet werkte.
Dus Cugel: Brainstormen is ok, maar pas
op als je dingen gaat beweren, waarvan
je zelf niet eens weet OF het uberhaupt
werkt. Want dat is volgens mij het geval
hier.
Een tip voor jou: stop maar met
posten... |
|
MatrixView
27-2-2005 12:01:00 |
[quote]M; er zijn meer biologen die het
bovenstaande niet begrijpen en een
netwerkbeheerder die daar dan werkt
hoeft er dan ook niet vanuit te gaan dat
die biologen alles weten. Waar ik zit
weten we meer dan zij waarschijnlijk
ooit zullen
begrijpen. Vraag ze maar eens naar de
relatie tussen axiomen en files op
snelwegen en de relatie tussen cellen en
steden......[/quote]
Kun jij die aliens naast je even vragen
naar de relatie tussen een dakraam en
een olifant? Of tussen een tang en een
varken?
Cugel, even voor de duidelijkheid: ik
heb geen heilig geloof in kennis van
wetenschappers. Het zijn mensen en er
zijn nog genoeg dingen die we niet
weten. Punt.
Maar het verschil met een wetenschapper
en jou is, dat jij niks bewijst van wat
je verkondigd. Een wetenschapper
publiceert zijn THEORIE, UITWERKING en
de bijbehorende RESULTATEN -OF- WEERLEGT
een stelling en doet dat allemaal in
termen die in ieder geval duidelijk zijn
voor vakgenoten.
Jij beweert alleen veel te weten (zelfs
meer dan toppers op hun eigen
vakgebied), maar dat dat waar is, blijkt
nergens uit...
Probeer het nog eens op het
HigherLevel.nl forum, waar je je "brainfarts"
hebt opgedaan. Of waren ze je daar ook
zat?
Tja... :-) |
|
Cugel
1-3-2005 21:35:00 |
De relatie tussen een tang en een varken
en een dakraam en een olifant is dat ze
alle vier ontworpen zijn.
Net als jij! |
|
marinusprins
8-3-2005 0:51:00 |
euh ja
waarom heeft een fruitvlieg net zoveel
dna-stringen als een mens
|
|
marinusprins
8-3-2005 0:54:00 |
Dit is universitair niveau,volgens mij
Heeft sloot ook op de UT gezeten
|
|
MatrixView
8-3-2005 17:30:00 |
[quote]Dit is universitair
niveau,volgens mij
Heeft sloot ook op de UT gezeten[/quote]
Welnee, deze thread is helemaal geen
universitair niveau. Het is niet veel
meer dan oeverloos gelul in de ruimte en
wat simpele wiskunde om van sommige
theorieen aan te tonen dat het
onmogelijk is.
|
|
Cugel
8-3-2005 23:05:00 |
[quote]euh ja
waarom heeft een fruitvlieg net zoveel
dna-stringen als een mens[/quote]
( bijna ) alle dieren/mensen hebben
evenveel verschillende ei-gen-schappen.
De itteratie nadat de originele DNA naar
RNA is omgezet ( dus een copy van de
originele database )
maakt dat je bent wat je bent en dat
geld voor zowel die vlieg, varken als
mens.
Een universele sleutel die overal werkt.
De omgeving bepaald de rest en geldt als
input voor de parameters
die bepalen hoe het zich verder
ontwikkeld. Elke som een ander antwoord
( plaatje in Sloots geval ). |
|
MatrixView
9-3-2005 17:10:00 |
:-) ...sommige mensen willen altijd
laten zien dat ze overal verstand van
hebben... Ook al hebben ze dat duidelijk
niet.
|
|
Cugel
9-3-2005 22:48:00 |
[quote
Is wel erg diep voor de vroege
morgen...is dit een zelfbeschouwing?;-)
[/quote] |
|
MatrixView
10-3-2005 0:48:00 |
[quote]
Is wel erg diep voor de vroege
morgen...is dit een zelfbeschouwing?;-)
[/quote]
Nope... , maar dat had jij ook al in je
glazen bol kunnen zien.
Er bestaan speciale forums voor jouw
soort. Hurry up. |
|
Jeroen
10-3-2005 9:20:00 |
Zeg Matrix, waarom zit jij in elke post
negatief te doen? Ik weet dat je een
hobbyzipper ben maar wat is precies jouw
frustratie? Heb je nooit zelf iets nieuw
bedacht wat je dolgraag zou willen? Zit
je hier te loeren tot je iets van waarde
vindt om zelf iets mee te doen? Wil je
er echt verstand van krijgen? Kijk dan
eens verder dan je neus lang is! Op deze
site staan nu al zoveel tips dat als ik
tijd had ik er een compleet werkend
systeem mee zou kunnen maken! Jij hebt
nog helemaal niets getest of
uitgeprobeerd. Kun je eigenlijk wel een
beetje C programmeren of ben je gewoon
een brulaap? Van de beschreven
technieken op deze site kun je gewoon op
het web de dll's downloaden. Daarmee
bouw je in no time een programmaatje
waarmee je frames kun compressen. En dan
maar losexperimenteren. Nee, gewoon door
blijven zeueren zoals jij diet, dat
heeft zin! Er is een speciale plek voor
ventjes zoals jij. Hurry up (dat is
trouwens een nepTwix en dat was weer een
vernoemde Raider - weet jij veel,
snotaap)!
|
|
MatrixView
10-3-2005 18:21:00 |
[quote]Zeg Matrix, waarom zit jij in
elke post negatief te doen? Ik weet dat
je een hobbyzipper ben maar wat is
precies jouw frustratie? Heb je nooit
zelf iets nieuw bedacht wat je dolgraag
zou willen? Zit je hier te loeren tot je
iets van waarde vindt om zelf iets mee
te doen? Wil je er echt verstand van
krijgen? Kijk dan eens verder dan je
neus lang is! Op deze site staan nu al
zoveel tips dat als ik tijd had ik er
een compleet werkend systeem mee zou
kunnen maken! Jij hebt nog helemaal
niets getest of uitgeprobeerd. Kun je
eigenlijk wel een beetje C programmeren
of ben je gewoon een brulaap? Van de
beschreven technieken op deze site kun
je gewoon op het web de dll's
downloaden. Daarmee bouw je in no time
een programmaatje waarmee je frames kun
compressen. En dan maar
losexperimenteren. Nee, gewoon door
blijven zeueren zoals jij diet, dat
heeft zin! Er is een speciale plek voor
ventjes zoals jij. Hurry up (dat is
trouwens een nepTwix en dat was weer een
vernoemde Raider - weet jij veel,
snotaap)![/quote]
Ah... Jeroen, je bent er nog! ik vroeg
me al af waar je zat.
Tja... dit was te verwachten... een
prachtige kans om die oortjes van mij 's
te wassen met een alles-behalve
technische aanpak (jammer...). Mijn
kritiek op je -niet werkende- idee heeft
je pijn moeten doen. Want op je idee en
verhaal had je wellicht tijden zitten
broeden... En er dan ook nog Eric Smit
mee weten bij te slepen... en shit...
dan komt daar zo'n zeikerd die vertelt
dat 't toch echt allemaal niet zo nieuw
en bijzonder is... kut hey...
Dus jouw frustatie snap ik.
Ok, nou de mijne: Ik heb een hekel aan
mensen die van alles beweren zonder er
enig bewijs voor te geven. Zij doen hun
ideeen voor alsof het DE waarheid is
(waarschijnlijk geloven zij het zelf
ook) en verbloemen het met mooie
quasi-wetenschappelijke termen en
filosofisch gelul... Op simpele
technische vragen krijg je geen
antwoord. Je zult ernaar moeten raden.
Het is dus meer hun "geloof" dan
wetenschap... ...dat is behoorlijk
irritant en ik help ze er graag vanaf
met (waar mogelijk) een gedegen
bewijsvoering. Maar gelul in de ruimte
is niet te bewijzen.
Natuurlijk zullen genoeg mensen mij ook
-terecht- verdomd irritant vinden, want
in de onderbouwing denk ik als laatste
pas aan het gevoel van die persoon die
het idee naar voren bracht. Maar uit
ervaring weet ik dat sommige dingen niet
werken, en vertel waarom. Dat neemt
misschien wat gewenste hoop weg, maar ik
lieg in ieder geval niemand voor... Mijn
bek houden en mensen in hun -soms
narcistische- waan laten, zou ik ook
kunnen doen, maar als ze andere mensen
mee gaan slepen in diezelfde onwaarheid,
dan zeg ik er wat van ... zie het als
een soort bullshit-filter... ;-)
Als ik met kut-opmerkingen daarbij toch
iemand heb gekwetst dan spijt me dat.
Til er vooral niet TE zwaar aan.
Het is misschien moeilijk te geloven
maar toch kan ik over goede en originele
ideeen zeer enthousiast/positief zijn,
maar die zijn hier nog niet voorgekomen
tot nu toe. Die zijn ook niet zo simpel
uit de mouw te schudden. Dat is jammer.
Goede ideeen lees/bestudeer ik vooral in
allerlei patenten, waar ik het gros van
mijn vrije tijd aan besteed. Kan dat
iedereen aanraden!
Nog 1 ding: ...Om mij te provoceren,
spreek je je twijfel uit over m'n kennis
en ervaring op programmeer en
compressie-gebied. Dat mag. Het
tegendeel kan ik in anonieme toestand
ook moeilijk bewijzen, niet?
Maar goed, programmeren doe ik nog
regelmatig (C(++), assembly, pascal,
java, php, python), maar vooral tijdens
m'n studie informatica was ik hier
actief mee. Onder Windows doe ik niet
veel, dus dll's genereer/gebruik ik
niet. Wel grappig dat je daar over
begint, want heb al jaren mijn eigen
compressie-libraries met allerlei
compressie-algo's. Dat loopt van
Arithmetic tot Lempel-Ziv en van
Fractals tot Huffman en de vele
varianten daarop. Maar ook lossy
methoden voor video, audio en images.
Maar mijn allergrootste interesse ligt
bij "transforms" die meestal voorafgaan
aan de eigenlijke compressie-methoden.
(De data zo slim mogelijk rangschikken
dat ie redundanter wordt).
Nou, tot kijk maar weer. |
|
Cugel
10-3-2005 22:55:00 |
[quote]
(De data zo slim mogelijk rangschikken
dat ie redundanter wordt).
Slimme matrix. Volgens mij zit je
helemaal goed.
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!
|
|
Jeroen
11-3-2005 9:00:00 |
Raar meisje ben je, matrix! Je
concludeert maar aan maar je hebt geen
idee! Allereerst, hoe kom je erbij dat
ik de Jeroen ben die het stuk geschreven
heeft? Dat zou ik best wel willen! Zijn
verhaal heeft me reuze geinteresseerd.
En op ideeen gebracht...
Wel grappig dat je niet onder Windows
met dll's van anderen programmeert
(hoewel het gros natuurlijk Visual Basic
knutselwerk is zijn daar toch
belangrijke zaken bij) terwijl je toch
de hele dag eenzaam zit af te wachten
tot er iets te posten valt. Als je nu
eens verder keek dan je neus lang is en
gaat zoeken via Iterated Systems en
verder... Jeroen kon er niets van vinden
schreef hij maar ik ben er via Google
achter gekomen welke bedrijven de
technologie en patenten (he, had je ze
toch moeten vinden, patentenlezer dat je
er bent!) hebben overgenomen. En zowaar
kon ik daar gewoon de dll's downloaden
en de eerste resultaten zijn al bereikt.
Maar dat gaat jou niks aan,
negatieveling! Jij bent weer een van die
mensen waar Sloot over verzuchtte dat ze
helemaal verkeerd keken en er niets van
begrepen. Blijf het rustig zoeken in
standaard compressiemethoden en
inderdaad, je kunt eeuwig negatief
blijven want zo werkt het niet. En
blijven zeuren dat het lossless moet
zijn en dat dat niet kan heeft ook
weinig zin. De wiskunde heeft al eeuwen
geleden bewezen dat dergelijke
compressie lossless niet mogelijk is.
Luister maar eens wat meer naar Cugel.
Je hele wereld is lossles. Denk je dat
onze hersenen snel genoeg zijn om alle
beelden die we ontvangen real-time te
verweken? Sukkel! Natuurlijk niet. De
natuur heeft het prachtig opgelost, er
gaat informatie verloren maar je merkt
er niets van. Is dat mooi of wat?
Jouw frustratie is me trouwens nu
helemaal duidelijk! Als het al waar is
wat je scrhijft, je hebt niet eens een
naam: eerst informatica gestudeerd (jij
bent een nerd maar vertel me eens welk
jaar en waar je afgestudeerd bent dan
heb je wellicht nog bij mijn colleges
gezeten) en dan op een afdeling als
systeembeheerder aan de slag. Hier wijze
verhalen schrijven dat je zo'n beetje
alles weet van compressie (niet dus) en
dan geen enkel bedrijf die je daar een
goedbetaalde baan in aan wil bieden. Ik
wil niet raden naar je uiterlijk en
leefomstandigheden maar ik denk dat je
een zielig iemand bent. Om de paragraaf
maar eens in je eigen trant af te
sluiten: get a life!
En doe ons een lol en post hier pas weer
als je zelf een mooie vinding gedaan
hebt (jammer, geen fantasie) of als je
het BEWIJS wilt posten dat iets niet kan
(ook jammer want zelfs in het voorgaande
priemgetallen voorbeeld, dat zich in een
programmaatje van acht minuten laat
weerleggen heb je dat niet gekund). Ik
ben bang dat je helemaal niet gewenst
bent hier. Terug naar de spiegel maar
weer en hop met die nageltjes! |
|
MatrixView
11-3-2005 12:22:00 |
Hoi Jeroen,
Je boosheid zit wel HEEL erg diep merk
ik. Je grijpt echt alles aan om mij te
provoceren (of het nu op waarheid berust
of niet...) En lezen is ook niet echt je
sterke kant... tjonge jonge... :-)
Ga eens goed na wie er wat heeft
gezegd...
Calm down. Take a breath. Er is niks aan
de hand, anders dan dat je reputatie een
deukje opliep... en nu maak je 't zelfs
nog erger... dat wil je vast niet...
Ik zou een lange post kunnen maken, die
jouw domheid op door jezelf genoemde
vlakken aantoont, maar volgens mij is
dat niet meer nodig. De lezer is slim
genoeg. 't moet ook een beetje een
technisch forum blijven... geen
persoonlijke flame-war.
Moest zo lachen om je veronderstellingen
over mijn persoonlijk leven, thanx! :-)
Meer geduld heb ik niet voor je, dus ik
ga nu weer verder, sorry. |
|
Jeroen
11-3-2005 20:15:00 |
Nou jammer, kinderachtig hoor. |
|
marinusprins
23-3-2005 21:43:00 |
Idealist en de realist ,levert altijd
leuke confersaties op.
Matrixview geloof jij nog wel in de
behaalde compressie van Sloot
Wat ik denk: Hij heeft die 'zogenaamde'
compressie gebruikt om iets anders wat
hij uitgevonden heeft te versluieren.
Ik denk dat hij die 80% procent
inefficientie van de cpu heeft
weggewerkt.
|
|
Jeroen
27-3-2005 14:06:00 |
He Marinus, Matrix is geen realist hoor!
Bij ons thuis heet dat een pessimist!
|
|
marinusprins
27-3-2005 19:05:00 |
[quote]He Marinus, Matrix is geen
realist hoor! Bij ons thuis heet dat een
pessimist![/quote]
Daar ben ik het niet mee eens.
een ongecomprimeerde films kost
terrabytes aan opslag,dat willen jullie
reduceren tot een paar mb?
Komop maak je zelf niet wat wijs,
DONT DREAM YOUR LIFE , LIVE YOUR DREAM.
|
|
TheJungOne
15-9-2006 16:19:00 |
"[quote]He Marinus, Matrix is geen
realist hoor! Bij ons thuis heet dat
een pessimist![/quote]
Daar ben ik het niet mee eens.
een ongecomprimeerde films kost
terrabytes aan opslag,dat willen
jullie reduceren tot een paar mb?
Komop maak je zelf niet wat wijs,
DONT DREAM YOUR LIFE , LIVE YOUR
DREAM.
"
Jongens jongens, blijf toch niet zo
hangen in die compressie ellende !
Dat is waar het juist NIET om gaat.
Alle vorige discussies die discussieren
kan je het beste verwijderen, het is
slechts ruis !
Inmiddels ben ik erachter hoe die Jan
Sloot het heeft gefixt, en heb ik adh
van het boek 'de Broncode' Bijlage 1
begrepen hoe hij het heeft klaar
gespeeld !
Lees het maar eens goed, zet dan op
papier wat hij schrijft .....
Hij heeft het nog net niet compleet
neergezet .......
Ik ga verder met uitontwikkelen, nu
jullie nog ...... :) |
|
FredZ
15-9-2006 23:26:00 |
"Jongens jongens, blijf toch niet zo
hangen in die compressie ellende !
Dat is waar het juist NIET om gaat.
Alle vorige discussies die
discussieren kan je het beste
verwijderen, het is slechts ruis !
Inmiddels ben ik erachter hoe die
Jan Sloot het heeft gefixt, en heb
ik adh van het boek 'de Broncode'
Bijlage 1 begrepen hoe hij het heeft
klaar gespeeld !
Lees het maar eens goed, zet dan op
papier wat hij schrijft .....
Hij heeft het nog net niet compleet
neergezet .......
Ik ga verder met uitontwikkelen, nu
jullie nog ...... :)"
Wat wil je bereiken met je opmerking?
"Jongens jongens, blijf toch niet zo
hangen in die compressie ellende !
Dat is waar het juist NIET om gaat."
Daar is de hele wereld al achter nu jij
pas.
|
|
|
|
|
|