| View previous topic :: View next topic |
| Author |
Message |
server
Guest
|
 Posted: Sat Jun 28, 2008 6:49 pm Post subject: Worst case H.264 CABAC testing |
 |
|
| message unavailable |
|
| |
|
 Back to top |
Industrial One
Guest
|
| Posted: Sat Jun 28, 2008 6:49 pm Post subject: Re: Worst case H.264 CABAC testing |
|
|
On Jun 28, 12:16 am, Sharjeel <sharjeel.sa...@gmail.com> wrote:
[quote]Hi,
I want to test a H.264 CABAC decoding engine for the worst-case.
Is there any bitstream available that I can use for testing the worst
case scenerio? I know that it would be very difficult to get the worst
case bitstream, but still worth asking for. Also, is there any
bitstream which may not be for the worst case bitstream, but still
very computationally extensive to decode using CABAC?
Alternatively, is there any technqiue using which I can analyze if a
specific CABAC decoder can achieve required throughput in the worst
case.
I was thinking of using random totally bitstream to get maximum
uncorrelation, encode that bitstream, and try decoding it with CABAC
decoder. Any ideas if such scheme has already been employed and any
sound results for such schemes?
Any other tips related to CABAC testing, not necessarily related to
worst case testing, would be really helpful.
Thanks,
Sharjeel Saeed
[/quote]
Frames consisting of pseudorandom garbage would do it. As for
legitimate video that would have a high BPS, try a white/bright yellow
background with close-up flash animated object moving around.
Something like this: http://www.zshare.net/download/1436067360109890/
On the other hand, that one can decode on a pocket PC. I don>t keep
track of how CPU intensive clips are. |
|
| |
|
| Back to top |
Esa Öhman
Guest
|
| Posted: Sat Jun 28, 2008 10:48 pm Post subject: Re: goto YOUTUBE, see RUSH at Red Rocks on 6-2-08, best show |
|
|
*On suorastaan mielenkintoista huomata muuten miten juuri SUPO:n
poliisivaltuuksia, nettivakoilua, puhelinsalaisuuksia ja urkintalupia yhän
laajemmin erityisesti Holmlundin toimesta lisätään ydinhallinnollemma
merittäin.. .Mutta, mutta???
*Koskaan ei sen tarkemmin sanota MITEN tätä urkintaa ihan OIKEASTI
suoritetaan ja toimeenpannaan sitten näillä perustuslakirikomuksin
konkretisoiden. On tosiaan aika oleellista, että näin estetään kaikin
mahdollisin keinoin ihmisuhreja tajuamasta miten tämä vakoilemisen sähköinen
muoto toteutetaan "katutasolla". Vain kaltaiseni alan ammattilainen
toisaalta osaa hakea niitä systeemiin liittyviä "akilleen kantapäitä"! On
sanomatta selvää, että kannettaviensa akunpoisto ilman, että koneen
fyysiseen toimintaedellytykseen tulee minkäänlaista ongelmaa haittaa
SUPO/NSA porukkojen kaukolukujensa jne. toimia niinpaljon ettei sellaisia
faktoja saa julkituoda! On totta, ettei tällaisia faktoja sallittaisi sitten
suin surmin levittää kansan tietoisuuksiin, esim tänne nettiin.
*Ja koska kivaa vastaanottoa tuntuu piisaavan niin tässä lisää: Eli usein
ihmisillä on harhakäsitys siitä, että kopioimalla saa ID-koodit
häippäsemään. Kopioikaa kaksi perussivua, tai ajakaa printteriin. Siirtäkää
ne päällekkäin. Ja liu-uttakaa tuuman verran. Huomaatte miten molemmissa
kuvien reunoissa on kuin hyttysen paskapisteitä miltei samanlaisesti
sikinsokin. Nykyään ne voi olla myös esim. vain UV_valossa näkyviä
valkoisia!! Joka reunassa ja kuvan keskialueilla tämä sama CIA-koodeksi
loistaa mukanaolollaan. Siinä on siis päivämääriä, maatunuksia, koneen
omistajia ja kopiomääreitä ja vastaavia kokonaistietokirjoja. Näillä sitten
vielä vaikka kymmenkertaisísta kopioinneista kyetään täsmähakemaan koko
kirjamateriaalin reitti salaisista arkistoista flaierreihin asti.. .Eli
rakkaat lukijat muistakaa nyt myös tällaisten faktojen olemassaaolot.
Nykyinen teknikan maailma on täynään tämän tyyppisiä ydinalan
sudenkuoppameriä. Toki näihin on erinäisiä "kiertoreittejä" mutta ne osaavat
kiertää lähinnä aniharvat alan huippuosaajat.. ..! |
|
| |
|
| Back to top |
Industrial One
Guest
|
| Posted: Sun Jun 29, 2008 1:45 am Post subject: Re: Continuation of open DISCUSSION between jacko et al |
|
|
On Jun 27, 4:32 pm, jacko <jackokr...@gmail.com> wrote:
[quote]
Pocket pc < 10Watts
[/quote]
What, you can>t afford a 150-watt desktop? -.-
[quote]I don>t remember being able to process any input at all. Meh.
I>m sure I put a dialog box into it which opened up.
[/quote]
K, I don>t remember a dialog box, I must>ve failed to compile it
properly.
[quote]The carrier is not GENERATED by the input sequence. See the Jim
example later.
[/quote]
Oh, the input is generated by the carrier?
On Jun 27, 4:59 pm, jacko <jackokr...@gmail.com> wrote:
[quote]Assume the independently generated carrier wil provide a low entropy
sequence 0001 0010 1000 0000 1100 0000 0100 as a start
[/quote]
Generated from where? And why that sequence? Aren>t we focusing on
random input data?
[quote]then 000 takes the first 3 bits of the carrier left as 0, the carrier
[/quote]
I don>t get it. You>re saying the 000 is left as is (abandoned)...
[quote]1 is then followed by a modulated 1, and a left 0 to allow unique
[/quote]
....while the 1 becomes 10? This is the modulation process, moving
on...
[quote]decode, then the next carrier 1 is followed by a modulated 1 and so
[/quote]
Carrier 1? Isn>t 0001 0010 1000 0000 1100 0000 0100 the input
sequence?
[quote]for the next carrier 1, and then there are the 2 zeros to allow unique
[/quote]
Which 2 zeros?
[quote]decodeand the final 0 of the first nibble to be compressed leaves the
first zero of the fourth nibble of the carrier equal to 0.
[/quote]
???
[quote]So the modulated carrier would go through the sequence 0001 1011 1100
0 ...which has 4 bit of information modulated onto it.
[/quote]
Where did 1011 come from? Didnt the original sequence start like 0001
0010 1000...?
I guess there>s no point in reading the rest since I got off on a
vague start :/ |
|
| |
|
| Back to top |
Jim Leonard
Guest
|
| Posted: Sun Jun 29, 2008 7:35 am Post subject: Re: Continuation of open DISCUSSION between jacko et al |
|
|
On Jun 27, 6:59 pm, jacko <jackokr...@gmail.com> wrote:
[quote]So the answer to your question is what is your prefered compact
representation of some algorithmic carrier with a low enough entropy?
[/quote]
My preferred representation would be any example that shows
compression of the 64-bit sequence I provided. If that>s too
complicated or long to work out manually, then feel free to tackle
just the first 32 bits. |
|
| |
|
| Back to top |
Industrial One
Guest
|
| Posted: Sun Jun 29, 2008 1:47 pm Post subject: Re: Continuation of open DISCUSSION between jacko et al |
|
|
Btw, thanks Jacko for your suggestion on eliminating my sleeping
disorder. I got privileged access to some Valerian leaves and it has
helped to keep me snoozing throughout the morning and day (my night
shift starts at midnight.) The fact that I won>t have to worry about
physical dependance is also kickass. You, sir, are a fucking genius.
Respect. |
|
| |
|
| Back to top |
Esko
Guest
|
| Posted: Sun Jun 29, 2008 6:02 pm Post subject: Re: Le matin, je songe... |
|
|
S.K.22.05.2008."Pölyttäjien täyskato uhkaa viedä kesän marjat. Omenapuut ja
herukat kukkivat monin paikoin jo täysillä, mutta puutarhoissa on hiljaista.
Pölyttäjiä ei ole liikkeellä. Sään lämpeneminenkään ei lupaa helpotusta,
sillä luonnonvaraisten pölyttäjien kannat ovat romahtaneet lähes
OLEMATTOMIIN! vaarassa ovat myös metsämarjat, sielä esim. mustikan, puolukan
ja vadelman pölytys on lähes yksinomaan kimalaisten varassa.
Mehiläistenhoidonneuvoja Ari Seppälä on kartoittanut pölyttäjien tilannetta
koko Suomessa. Uutiset ovat olleet yksinomaan HUONOJA! -arvioisin, että
kimalaisia ja ampiaisia on nyt korkeintaan KYMMENESOSA normaalista tasosta.
Tutulla omenanviljelijällä on tarhassaan tuhat kukivaa puuta. Hän ei ole
nähnyt tänä keväänä ensimmäistäkään kimalaista. Kimalaiset ja ampiaiset
katosivat yllättäen Suomesta viime kesämä. Syytä katoon ei tiedetä. Seppälä
ei usko tilanteen korjaantuvan edes seuraavana kesänä!"
Niin TUSKIN tarvitsee jatkaa? Poriin on ylätuuleen matkaa TVO:lle jo yli
50km. Ja kuten todettiin 90% katoaluetta aina kukkakärpäsiä myöten on aivan
hurjaa. (Huvittavinta, että kyseiselle kaverille lähetin vain parisen viikoa
sitten tiedot ydinaavikoitumisfaktasta, ja KAS oivalteli! Ei sanan sanaa
siitä, ettei Suomella olisi mehiläisistä ongelmia. Kiitokset Ari näin netin
kautta, oikeesti! no toisaalta kaverin netit kuulema turpoavat kiukkuisen
kentän kommentteja aiemmasta virhetiedotuksista! Taisi ryhmäkuri olla
mukana. ))) .. Ydinvoimalan päästöt tappaa siis todetusti jo kautta Suomen!
Joten HÄVETKÄÄ muuta täällä aiemmin vedätelleet!
Vaikka täällä yritetään pajunköyttää ties mitä "varmaa"
virus,punkki,bakteri,mitälie tekaisua" toteennäytetyksi niin Seppälä kuittaa
tällaiset luulot jopa yllättäen ilmoittamalla, ettei syistä ole hajuja!
Porissa vain muutamasta talvipesästä on jokusia punkkeja löytynmyt ja
mehiläiskato on edelleen mysteeri. Niin.. .? Tai oikeammin tarkoittaa sitä,
että YKSIKÄÄN julkisuuden tautipelleilyharhautus ei vakuuta ketään! Eli jää
jäljelle jälleen keran VAIN ne joista kuiskitaan ovien takana.
Ydinionisaation aiheuttama suunnistuseksymiselle jälleen tutusti pojot!
Sanoi ydinklingonit mitä lystää! Outoa kapinointia kentältä, jopa musta,
ettei jotain ole tekaistu syyksi klassisista huijauksista, vaikka ydinala on
parisen vuotta puukottanut? Lieneekö vaan niin, ettei valheet
mehiläiskasvattajiin enää uoppoa, kun netissä puhelevat tietävämmät syyksi
ydinavikoitumisia, ja beetasoihtupäästöjä?) |
|
| |
|
| Back to top |
Fulcrum
Guest
|
| Posted: Mon Jun 30, 2008 12:14 am Post subject: Re: FREE SOFTWARE DOWNLOAD |
|
|
[quote]I only see adds and more ads :(
A poster with a gmail address posting via google
groups, and with a link to a googlepages page...
What on earth made you think there would be anything
of worth there?
If he>s paid by ad impressions, then you>re now
part of the problem. Well done.
[/quote]
It was more of a public service mentioning the content here.
Google Adwords work with pay per click not pay per view :-) |
|
| |
|
| Back to top |
Phil Carmody
Guest
|
| Posted: Mon Jun 30, 2008 2:38 am Post subject: Re: FREE SOFTWARE DOWNLOAD |
|
|
Fulcrum <werner.bergmans@gmail.com> writes:
[quote]On Jun 28, 7:26 am, nancygro...@gmail.com wrote:
DOWNLOAD SOFTWARE ONLINE
http://freespamonline.googlepages.com
I only see adds and more ads :(
[/quote]
A poster with a gmail address posting via google
groups, and with a link to a googlepages page...
What on earth made you think there would be anything
of worth there?
If he>s paid by ad impressions, then you>re now
part of the problem. Well done.
Phil
--
Dear aunt, let>s set so double the killer delete select all.
-- Microsoft voice recognition live demonstration |
|
| |
|
| Back to top |
jules Gilbert
Guest
|
| Posted: Tue Jul 01, 2008 12:32 am Post subject: Re: answers please... |
|
|
On Jun 19, 5:05 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
[quote]jules Gilbert schrieb:
Okay, as I have said I have a method that does produce a non-uniform
number of output states, given a uniform number of input states.
(Here, non-uniform means a bell curve.)
Oh, if that is your problem or claim, this is easily done. If you have two
independent random sources, A and B, then A+B will always be a random
source with a non-uniform distribution. Actually, if you perform this step
a couple of times, you will arrive at a random source with a Gaussian
distribution. This is not a miracle, this is just the central limit
theorem. Proving this requires a bit of Fourier analysis and knowledge about
stable distributions, but once that is understood, it>s about a page
(for the currently understood situation of having symmetric sources
with bounded variance, otherwise the proof is more technical.)
I have been testing a 1M 'file' of RAD, where my 'file' is a segment
of right-most bits from a well known/respected PSRNG and am producing
bell-curve output. (These runs have been made many millions of
times, and I have on occasion substituted other RNG>s -- I don>t think
I am 'seeing' an attribute of the RNG.) I offered to provide this
information to one of the mathematicians who post here, but the
private conversation was not helpful -- so once again, I am coming to
the group for assistance.
Well, here>s my assistance: Google for "central limit theorem".
Also, I have also done this with actual files, including MN>s 1M file
(well, 415k,) and produce non-uniform output. And, when I assume 1-
bit for the most frequent output state times the number of times that
symbol occurs, plus 2-bits for each of the next two most commonly
occurring symbols, again times the number of times each of those
symbols occur, etc... I get a size result that is smaller than the
input file. (Yes, that>s right.)
If you think about this closer, you>ll soon find that, for example for
the above simple system, A+B will have a range that is larger than
the input range, which will eat up your gain you gained by the non-uniform
distribution. Similar pitfalls will exist for related algorithms.
And I have a couple of dumb questions...
1) Why is Shannon-Fano a bad choice? (I understand that arithmetic
coding can be better,) but why is this not as good as Huffman?
It generates codes "top down" rather than "bottom up" - in some configurations,
it can be seen that the codes generated by it are non-optimal in the sense
that codes are possible that generate shorter average bit-length. For Huffman,
however, one can show that reaches the theoretically possible limit. Again,
a proof would be too long for this news group, but if you want to see an
example where Shannon-Fano does not create optimal codes, the Wikipedia carries
one: {0.35, 0.17, 0.17, 0.16, 0.15} - it should be sufficient to build the
corresponding Shannon-Fano code for this set, compare it with the code created
by the Huffman algorithm, and compute the average code-length for both. You>ll
then see that the size of the Huffman code is smaller.
2) Wrt to my data, I have a number of different implementation
models, (the system supports three parameters, not all of the
cartesian product of these models actually work wrt compression,) but
among those that do, many produce fewer than 256 symbols. Has anyone
written a standard emitter library that can be used for
experimentation? (I>ve only been looking for such a library for about
ten years.)
Encoding an alphabet with a number of symbols not exactly a power of two is a
nice candidate for arithmetic coding (even if the probabilities are all
equal).
I have decided that my emitter will be built around S-F, it>s simple
and is not protected by someone else>s patents.
And, if I may ask, what>s wrong with Huffman?
Besides, I think the relevant patents for arithmetic coding should be run
out by now.
So long,
Thomas
[/quote]
On Jun 19, 5:05 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
[quote]jules Gilbert schrieb:
Okay, as I have said I have a method that does produce a non-uniform
number of output states, given a uniform number of input states.
(Here, non-uniform means a bell curve.)
Oh, if that is your problem or claim, this is easily done. If you have two
independent random sources, A and B, then A+B will always be a random
source with a non-uniform distribution. Actually, if you perform this step
a couple of times, you will arrive at a random source with a Gaussian
distribution. This is not a miracle, this is just the central limit
theorem. Proving this requires a bit of Fourier analysis and knowledge about
stable distributions, but once that is understood, it>s about a page
(for the currently understood situation of having symmetric sources
with bounded variance, otherwise the proof is more technical.)
I have been testing a 1M 'file' of RAD, where my 'file' is a segment
of right-most bits from a well known/respected PSRNG and am producing
bell-curve output. (These runs have been made many millions of
times, and I have on occasion substituted other RNG>s -- I don>t think
I am 'seeing' an attribute of the RNG.) I offered to provide this
information to one of the mathematicians who post here, but the
private conversation was not helpful -- so once again, I am coming to
the group for assistance.
Well, here>s my assistance: Google for "central limit theorem".
Also, I have also done this with actual files, including MN>s 1M file
(well, 415k,) and produce non-uniform output. And, when I assume 1-
bit for the most frequent output state times the number of times that
symbol occurs, plus 2-bits for each of the next two most commonly
occurring symbols, again times the number of times each of those
symbols occur, etc... I get a size result that is smaller than the
input file. (Yes, that>s right.)
If you think about this closer, you>ll soon find that, for example for
the above simple system, A+B will have a range that is larger than
the input range, which will eat up your gain you gained by the non-uniform
distribution. Similar pitfalls will exist for related algorithms.
And I have a couple of dumb questions...
1) Why is Shannon-Fano a bad choice? (I understand that arithmetic
coding can be better,) but why is this not as good as Huffman?
It generates codes "top down" rather than "bottom up" - in some configurations,
it can be seen that the codes generated by it are non-optimal in the sense
that codes are possible that generate shorter average bit-length. For Huffman,
however, one can show that reaches the theoretically possible limit. Again,
a proof would be too long for this news group, but if you want to see an
example where Shannon-Fano does not create optimal codes, the Wikipedia carries
one: {0.35, 0.17, 0.17, 0.16, 0.15} - it should be sufficient to build the
corresponding Shannon-Fano code for this set, compare it with the code created
by the Huffman algorithm, and compute the average code-length for both. You>ll
then see that the size of the Huffman code is smaller.
2) Wrt to my data, I have a number of different implementation
models, (the system supports three parameters, not all of the
cartesian product of these models actually work wrt compression,) but
among those that do, many produce fewer than 256 symbols. Has anyone
written a standard emitter library that can be used for
experimentation? (I>ve only been looking for such a library for about
ten years.)
Encoding an alphabet with a number of symbols not exactly a power of two is a
nice candidate for arithmetic coding (even if the probabilities are all
equal).
I have decided that my emitter will be built around S-F, it>s simple
and is not protected by someone else>s patents.
And, if I may ask, what>s wrong with Huffman?
Besides, I think the relevant patents for arithmetic coding should be run
out by now.
So long,
Thomas
[/quote]
Hello Thomas and the group:
Nothing wrong with arithmetic compressors, and in fact, others I work
with keep pointing me the same way...
I have put together a 'simulator', a program that applies a certain
method using various parameters. I had been attempting to use
symbolic methods to derive an optimal (think DSP) filter -- in fact if
you (Thomas,) and I had been able to work something out this is what I
had intended to ask of you. But time is passing so I simply wrote a
program that applies the cartesian product of several parameters and
then sorts the results of each run for the best compressor.
Each input file was a 1MB 'file', a random list of tokens from a
pretty good PRNG. The output is another list of tokens ('symbols',)
and the program keeps track of the number of output symbols; the
frequency count for each output symbol 'translates' (can be
converted,) to an approximate metric of the output length.
(I did make some runs using MN>s 415k special file. The results were
not particularly interesting -- the method does not depend very much
on the type of data.)
Some settings produce approximate file sizes much less than 1MB, --
several show 40% compression. (Again, this is without regard for the
type of data used as input.)
Does this mean I>ve done it? I>m not sure -- I have two friends, when
they like it, I>ll claim it. But I am certain that the simulator
*generally* does iterate over some settings which, given *any* input,
shows compression. This is true whether the input 'file' is random or
not random -- it doesn>t matter -- this method doesn>t work by storing
output in the output file, thus Shannon doesn>t apply. (An output
file is produced, but it>s only an index file, not a data file in the
conventional sense.)
This method is incredibly cheap. I mean it. And it>s fast and uses
very little memory. In fact I implemented a version of it on a
programable calculator -- so much for the value of my blades...
I repeat: This is all very experimental -- I want to be careful not
to overstate what I have done. I>ve looked at perhaps a hundred core
methods; You folks can think what you want, but perpetual compression
is by no means impossible -- difficult, yes, but impossible, no.
Until recently I had a nicely circuitous way of getting to the 'net --
but it went away and now I am trying a taut wire and two tin cans. My
point: I won>t be around everyday. If you have something for me,
send me an email.
--jg |
|
| |
|
| Back to top |
Providence
Guest
|
| Posted: Tue Jul 01, 2008 5:17 am Post subject: Re: Continuation of open DISCUSSION between jacko et al |
|
|
On Jun 25, 12:10 pm, jacko <jackokr...@gmail.com> wrote:
[quote]A thing to think about
If at time t=0 the data content of a system is the input stream length
i, the carrier system state length c, then the total system bit length
m is defined as
m=i+c
so at general time t, and with sufficiently low entropy from carrir c
m=i-kt+c
after sufficient t
m=c
Now the problem with applying the counting argument to such a system
is that it would imply the total complexity of the system can at most
only be c, and so it implies k HAS to be negative.
So it implies that generating a carrier with fixed size c IS
impossible.
So it further implies that all fixed size reversable sequence
generators which HOLD bit state changes (at any point in time,
independent of sequencing clock), have HIGHER entropy than a carrier
NEEDS.
And as any number of siad fixed size carriers can be majority state
composed into one equivelent carrier, then the said HIGHER entropy
must ALWAYS be 1.
This is my first claim.
jacko
[/quote]
hey jacko i>m wondering if you could, instead of trying to figure out
how to code this concept in linear c/c++ style code blocks, if you
could produce a functional flow chart of the design schematic.
i>m sure your pocket pc has a 'ms paint' style program.. if you could
whip up some rectangles with descriptors and input/output definitions,
that would be super.
this would allow myself to actually understand what you>re saying in
regards to the generation of the carrier 'So it implies that
generating a carrier with fixed size c IS impossible.'
right now, i don>t get what you>re saying (the counting argument,
being very simple to rationalize, is overriding your argument.. i
literally cannot see what you>re saying).
being able to get four outputs from three inputs just doesn>t make any
sense, and while i can perceive that your system isn>t using that
logic style, it still is quantizing into that domain, which is blowing
up the implementation of the system.
if you>ve indeed found a paradox within the system that opens it up a
bit, map that puppy out so we can look at it. try to flow chart it.
chris. |
|
| |
|
| Back to top |
Jim Leonard
Guest
|
| Posted: Tue Jul 01, 2008 5:55 am Post subject: Re: answers please... |
|
|
On Jun 30, 7:32 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
[quote]Does this mean I>ve done it?
[/quote]
Not until you write a decompressor, no.
[quote]they like it, I>ll claim it. But I am certain that the simulator
*generally* does iterate over some settings which, given *any* input,
shows compression. This is true whether the input 'file' is random or
not random -- it doesn>t matter -- this method doesn>t work by storing
output in the output file, thus Shannon doesn>t apply. (An output
file is produced, but it>s only an index file, not a data file in the
conventional sense.)
[/quote]
Is the index file enough to reconstruct the original data? |
|
| |
|
| Back to top |
Phil Carmody
Guest
|
| Posted: Tue Jul 01, 2008 12:19 pm Post subject: Re: Continuation of open DISCUSSION between jacko et al |
|
|
Providence <psionic81@gmail.com> writes:
[quote]On Jun 25, 12:10 pm, jacko <jackokr...@gmail.com> wrote:
[SNIP - Wacko jacko wibbling]
hey jacko i>m wondering if you could, instead of trying to figure out
how to code this concept in linear c/c++ style code blocks, if you
could produce a functional flow chart of the design schematic.
i>m sure your pocket pc has a 'ms paint' style program.. if you could
whip up some rectangles with descriptors and input/output definitions,
that would be super.
[/quote]
Jacko>s a grade A loon. His diagrams will make as little sense
as his words. Just killfile him, and move on.
Phil
--
Dear aunt, let>s set so double the killer delete select all.
-- Microsoft voice recognition live demonstration |
|
| |
|
| Back to top |
jules Gilbert
Guest
|
| Posted: Tue Jul 01, 2008 1:43 pm Post subject: Re: answers please... |
|
|
On Jul 1, 1:55 am, Jim Leonard <MobyGa...@gmail.com> wrote:
[quote]On Jun 30, 7:32 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
Does this mean I>ve done it?
Not until you write a decompressor, no.
they like it, I>ll claim it. But I am certain that the simulator
*generally* does iterate over some settings which, given *any* input,
shows compression. This is true whether the input 'file' is random or
not random -- it doesn>t matter -- this method doesn>t work by storing
output in the output file, thus Shannon doesn>t apply. (An output
file is produced, but it>s only an index file, not a data file in the
conventional sense.)
Is the index file enough to reconstruct the original data?
[/quote]
First Jim, I have some very specific answers and in fact I started to
write out a message and then realized what I was saying -- that I was
supplying to much information; I need help but I can>t respond with
sufficient precision to enable anyone to provide the right answer. I
am further along than I have been in years I do build a vector of RAD
and process it, in fact to answer you -- I can reconstruct it.
But I do have some remaining issues and I need to go back to a couple
of people I use and see if we can>t muddle through a little more.
Now, to some serious business!! Everyone! whatever else you do
today, go to Youtube and look at:
Tim Dixon>s Rube Goldberg |
|
| |
|
| Back to top |
Industrial One
Guest
|
| Posted: Tue Jul 01, 2008 8:42 pm Post subject: Re: answers please... |
|
|
On Jul 1, 6:43 am, jules Gilbert <jules.sto...@gmail.com> wrote:
[quote]
First Jim, I have some very specific answers and in fact I started to
write out a message and then realized what I was saying -- that I was
supplying to much information; I need help but I can>t respond with
sufficient precision to enable anyone to provide the right answer. I
[/quote]
So, in a nutshell: you don>t know what the f ck you>re talkin' about? |
|
| |
|
| Back to top |
|
