"Jerry Avins" <jya@ieee.org> wrote in message
news:XbqdnZ4LndPPJUHZnZ2dnUVZ_o-dnZ2d@rcn.net...
> cr88192 wrote:
>
> ...
>
>> note that I am autistic (in particular, aspergers), but I am not entirely
>> sure if this is related to all this...
>
> The days when Asperger's was thought to be a form of autism are over. The
> current view is that they're related like chimps and humans. That is,
> neither is a form of the other, but they share common roots.
>
ok, well then...
in any case, I seem to arguably also have some schizo traits as well, but in
retrospect, I think I always have (albeit my interpretation of things has
changed somewhat).
> I raised an Asperger's (adopted) grandson, and I see a lot of my early
> self in him. I certainly understood his needs and limitations better than
> any other adult in his life. He's about to enter his sophomore year in St.
> Thomas University with a fantastic scholarship that he earned
> academically. That's more than I could have done, and I did all right.
>
academically, I have usually done poorly...
> Don't sell yourself short.
>
people say that sometimes, but I often seem inadequate, or people ask me to
do things I am unable to do, ...
it is like, I write things in C (or sometimes C++), but someone (ok, my dad)
wants me to write something in VB (as an access frontend), but I don't know
VB, and it otherwise seems rather hacky and arbitrary (and very
frustrating). then I don't get it done, and my skills are called useless
since I can't seem to pull it off. comments are made like: no one pays
anyone to write things in C, it is VB they will pay for, ...
it is like, anymore, I can't deal with trial and error that well.
I can deal with trial and tweaking (eg: optimizing, ...), but this is
different.
I think, I write, I test. yes, often a few things need to be fixed before it
will work, but that is minor (this is very different than trial and erroring
ones way through a larger project). most errors are misc stupid things that
are no big deal, and not a general sense of "ok, I have no idea what it is I
am doing...".
my approach to gaining new knowlege is typically, I read stuff, and I think,
and not so much by trial and erroring my way through things for which I
don't understand.
likewise, I was before going for a CS major, but he then decided to move me
to a different college and have me go for an english major, under the idea
that "people will actually pay for that".
then again, even if I remain as a hobbyist, that is ok I guess...
coding is not so much for credit or money in my case...
or such...
on a sidenote though, I recently hacked over a deflater of mine so that it
supports much larger match lengths and a much larger window (up to 65538
char matches and a 4GB window).
initial results look promising (compressing a 600kB text file to only a few
hundred bytes worse than bzip2, which should be nearly 'optimal' in this
case).
the big problem right now is that encoding is terribly slow (decoding shound
be about the same as before). this is because I had simply upscaled the
string matching algo as well, but what works ok at 32kB, does not work so
well at 16MB...
I may revert this part back to only managing the most recent 64kB or so (or
dropping it altogether should I implement a prefix tree).
was considering different options for making the speed less terrible
(simplest and easiest would be a big slightly-funky hash system, much more
involved would be to use a prefix tree).
the representation itself doesn't care much though, I can do whatever...
I chose to simply expand the existing deflate structure as that is most
elegant, and would probably work well enough in any case.
the headers were changed a little (making them distinguishable from normal
deflate headers, allowing a decoder to handle both cases). the headers are
still very similar though...
block type is 3, and another 4 bit type field is added;
HLIT and HDIST have each been expanded to 6 bits (the representation is
about the same as before, except that the pattern goes on a little further
and can thus code much larger values);
...
I spec'ed that the value of HDIST be used as a way to know the max window
size for that block (in the decoder). now, it is quite possible that this
number could be smaller, but I could probably also spec that the coder will
set this to a value representative of the window size (if less values are
used in coding, they are 0 filled to compensate). should be good enough...
then again, the window size should not be set at some unreasonably large
value, as a non-trivial decoder might actually care (or is useless to
allocate 16 or 64MB for a 600kB file). or, no matches might actually use the
full window size, so this makes it difficult.
otherwise, it could work as normal, and the rule could be that, if a block
is encountered with a distance table that is larger than the current window,
then the window is to be expanded. this resolves the above problem, but is a
potential hassle for the decoder (which would likely need to realloc the
window and copy the old contents to the new one...).
other problems could exist though (eg: a reference exists to a non-preserved
area, ...). so yeah...
or such...
> Jerry
> --
> Engineering is the art of making what you want from things you can get.
> �����������������������������������������������������������������������