Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #740 > unrolled thread

my response to some recent posts

Back to article view | Back to comp.compression

Contents

  my response to some recent posts jules Gilbert <jules.stocks@gmail.com> - 2012-01-09 06:50 -0800
    Re: my response to some recent posts Jim Leonard <mobygamer@gmail.com> - 2012-01-09 08:25 -0800
    Re: my response to some recent posts stan <smoore@exis.net> - 2012-01-09 14:03 -0500
    Re: my response to some recent posts Alex Mizrahi <alex.mizrahi@gmail.com> - 2012-01-09 21:54 +0200
    Re: my response to some recent posts glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-09 21:41 +0000
      Re: my response to some recent posts jules Gilbert <jules.stocks@gmail.com> - 2012-01-09 16:20 -0800
        Re: my response to some recent posts Jim Leonard <mobygamer@gmail.com> - 2012-01-09 20:24 -0800
    Re: my response to some recent posts Thomas Richter <thor@math.tu-berlin.de> - 2012-01-10 09:56 +0100
    Re: my response to some recent posts Sebastian <s.gesemann@gmail.com> - 2012-01-10 04:42 -0800
      Re: my response to some recent posts Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-01-10 21:08 -0800
        Re: my response to some recent posts jules Gilbert <jules.stocks@gmail.com> - 2012-01-11 17:48 -0800
          Re: my response to some recent posts Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-01-12 05:04 -0800

#740 — my response to some recent posts

Their was a company, a Boston company, actually I think they were in
Dedham, in the late '80s.  They took $80M in venture money and never
brought out a product.  Nothing.

At the end they thanked their investors and shut the doors.  Thank you
very much.  (I wasn't involved, I just read the story in the
newspaper, that's all.)

Well, right now I'm wondering if I'm going to be that company, just
minus the $80M.

Oh, one additional difference... I have a program.  It works too.
Last week I showed it to a friend.  In C, on my laptop, he edited the
source code, re-compiled it, and he ran it.  He made changes, he was
driving.   About my friend, he's a better C programmer than I am.  I
suppose I'm fair, but he's an expert, one of the best programmers I
have ever worked with.  When I have something difficult to code I give
it to him.  For when I want it done right.

So what was the program?, well it wasn't a compressor.  Something like
that I suppose...

Many times compressors are rated in terms of their ability to predict
the next bit in a series of bits.  Prediction is useful because it's
not necessary to send what can be predicted at the RCVE station.  (Why
send it when you can predict it?)  And this model, this paragraph of
discussion isn't about subsequent re-compression of RAD, this is all
true for conventional compression.

So that's what the program was, it predicted the contents of a block
of data.  Not perfectly, sorry.  But without any information being
transferred between the SEND station and the RCVE station my program
is able to predict the approximate contents of a compressed block of
client data, a buffer.  Again, with nothing being exchanged.  And it
does, roughly, 70%.  (Actually I can prove 75%, but it does 70%
without exception, even a million times consecutively, whereas when I
ask for 75% it does have the occasional hiccup, producing a result
less than 75%.  But *never*, as in no, not ever, does it get near the
50% mark.

Remember, these are not compression figures of merit, these numbers
are computed by matching each predicted bit with each actual bit.  The
formula I use is:  (OK*100.) / (OK+NG).

And I am not talking about experimental blocks of data that are
derived using random number generators, in each case the client data
is derived by reading files produced using gzip, bzip2, arj, and the
usual compressors we're all familiar with.  And these are not small
files (a few are small,) but most are at least 10k bytes, going up to
about 256k bytes.

I've run my test program with millions of blocks of data produced by
opening the compressed file, getting the file size, doing fread's to
get a block of client data, then XOR'ing the data to a pseudo-random
stream.  Works every time.  Again I have performed this test on
thousands of compressed files.

About these figures of merit, the numbers 70%, 75%, and higher.  When
I read a file I block it and read and process every block.  (The
fragment is ignored.)  And my program reports only the worst case.  My
point:  I've believe I've used good engineering techniques to do this
work.  I don't know that I can go much higher but what I say here is
accurate.

I don't run these tests manually.  I have renamed the files in my test
file area to the ordinals, keeping them in one directory and using the
result of a random number function to pick the file to be processed.
As you might expect the process is heavily automated.  Everything is
in C.

I credit Jean-Loup and Adler, the authors of zlib for allowing me, via
their public license to use their most wonderful program.  Thank you.

Also, I credit Stewart Heitmann, the author of argtable.  How much
nicer it is to use your tools than to fiddle with all the things I
would have to do otherwise.  Thank you.

Oh yeah, about bringing out a compressor...  I was hoping to use the
method's I've developed to predict, 95%, maybe 98%, of the bits in a
block of bytes. (Using maxima I can prove that should be possible.)
And while I have been able to obtain that level of performance, using
the best means I know today, it's just not practical.  I need to know
more, I think, or to involve others.

I do have one engineering change under way that I think will bring my
consistent block performance to above 78% using my current system, the
program I have now.  But I'm not claiming that 78% now.  Now I claim
75%, the 78% number is still being tested.

As each of you think about my claim to predict so many bits
successfully -- I recognize what a gulp that must be;  Remember this.
I'm not predicting randomness, obviously my method works because my
program understands things about the nature of compressed files.  The
program doesn't "read" them, ie., it doesn't attempt to decompress
them or interpret them, it simply treats each file as a block of
data.  I hope this makes your understanding easier.

Now though...  Well, this is probably the time to look around for a
large company partner.  A firm with demonstrated ethics first, next,
with a history in successfully fighting off would-be infringers.
Also, I am especially willing to consider companies in China.

Why?  I look at the business ethics I see demonstrated in several of
the US companies, in Canadian firms, in companies in western Europe,
and well, I am reminded of a long passage in Ezekiel, -- look it up.
(And these companies couldn't do business this way without corrupt
lawyers and without a judiciary that -- for example, allowed Bill
Gates to feign selective memory loss when he was asked to answer
questions for which honest answers would have been detrimental to his
interests.)  And if we're going to permit this in our courts, okay,
but then allow this standard of conduct for everyone, not just those
who have enriched themselves unjustly.  About Mr. Gates, yes I am
using him as an example, but the awful thing is that, so far as I
know, he's only about average.  He was no different from thousands of
other CEO's.  (Yes, he led MS when they decided to bring out "Double-
Space", for which they had not negotiated a license.)

You folks think I've been lying to you about what I have.  Nope.  But
I will let it die with me rather than bring it out only to have it
stolen.

About who I sell it to;  I don't want to sell it to Russia, night has
fallen there, I think we all know that.  Nor in the US, Canada, or
countries in western Europe.  Really the only place I see that might
be able to afford my program and also qualify is China.  (I will sell
it to a company that can demonstrate a history of good behavior wrt
the intellectual property of others.)

About China, I will need to see them change.  To treat Christians
well, to apply pressure on North Korea to release the people they have
imprisoned for praying to the God of the Bible.  And China also needs
to change their ways.  They need to allow Christians to meet, to read
the Bible, to pray, to evangelize.  They need to allow Bibles into the
country and to stop imprisoning those who read them.  They need to
release their own people, who they have imprisoned for being
Christians.

Please use this email address:  repeatable underscore compression
ngista oohay tod moc

[toc] | [next] | [standalone]

#741

On Jan 9, 8:50 am, jules Gilbert <jules.sto...@gmail.com> wrote:
> Oh, one additional difference... I have a program.  It works too.

You have a program that attempts to compress.  Until you write a
program that also decompresses, you have nothing.  Based on what you
wrote, it sounds like you've spent 16 years writing a compression
system without bothering to verify if your decompression system even
works.

Please actually write your system before making claims.  Write it in
any language you feel comfortable with.  Demonstrate *to yourself*
that you have one program that can take a file and make it smaller,
and another program that can take the smaller file and reconstruct the
original input from it.  Until you do so, you're not actually capable
of claiming anything.

[toc] | [prev] | [next] | [standalone]

#744

jules Gilbert wrote:
< prophecy snipped>

> Oh, one additional difference... I have a program.

So you've often claimed.

> So what was the program?, well it wasn't a compressor.  Something like
> that I suppose...
<snip>
> So that's what the program was, 
<more claims of mythical program snipped>

This is like the worlds worst magic show. Everyone in the audience
sees everything the magician does and no trick works nor is even
mildly interesting. You might consider getting some nearly naked
and pretty assistants.

> And I am not talking about experimental blocks of data that are
> derived using random number generators, 

Do you believe the input data to be random, regardless of the source?

<snip>
> Works every time.  Again I have performed this test on
> thousands of compressed files.

But have you reversed the process once?

> I've believe I've used good engineering techniques to do this work.

You would be very wrong. Not only is there no visible evidence of any
science or math, but to the contrary you have claimed that such
knowledge can blind one to seeing possibilities.

> I don't know that I can go much higher but what I say here is
> accurate.

You seem to have missed the point that your credibility here is zero.

> Oh yeah, about bringing out a compressor... <snip> , using
> the best means I know today, it's just not practical.  I need to know
> more, I think, or to involve others.

Are you now claiming your method can't be implemented?

> As each of you think about my claim to predict so many bits
> successfully -- I recognize what a gulp that must be;

Think credibility. 

> A firm with demonstrated ethics first, next, with a history in
> successfully fighting off would-be infringers.  Also, I am
> especially willing to consider companies in China.

Given China's record with IP, this seems strange.

> You folks think I've been lying to you about what I have.

To be clear, you've made claims you can't back up.

> About China, I will need to see them change.

Good luck with that. Is this the next problem you intend to attack?

[toc] | [prev] | [next] | [standalone]

#745

> Last week I showed it to a friend.

I remember you said same thing a year ago. It gets old.

> So that's what the program was, it predicted the contents of a block
> of data.  Not perfectly, sorry.  But without any information being
> transferred between the SEND station and the RCVE station my program
> is able to predict the approximate contents of a compressed block of
> client data, a buffer.  Again, with nothing being exchanged.

Wow. Apparently, random compression isn't enough anymore and we're 
talking about _telepathic compression_? Like, you don't need to store a 
compressed version of file at all, when you need a copy you just think 
about it and it appears.

> And it
> does, roughly, 70%.  (Actually I can prove 75%, but it does 70%
> without exception, even a million times consecutively, whereas when I
> ask for 75% it does have the occasional hiccup, producing a result
> less than 75%.  But *never*, as in no, not ever, does it get near the
> 50% mark.

It is certainly possible if your input was transformed in a way which 
alters probabilities of symbols. E.g. after substitution

0 -> 00
1 -> 01

for a data source with equiprobable 0 and 1 you get one with 75% zeroes.

So you can do a simple prediction here: symbol is zero. It is right in 
75% cases.

But, obviously, this 'gain' gives you nothing because transformed input 
is larger than raw input.

Did I crack your compression scheme?

Of course, you do some elaborate transform, only requirement here is 
that after-transform distribution isn't uniform on uniform input.

> About these figures of merit, the numbers 70%, 75%, and higher.  When
> I read a file I block it and read and process every block.  (The
> fragment is ignored.)  And my program reports only the worst case.  My
> point:  I've believe I've used good engineering techniques to do this
> work.  I don't know that I can go much higher but what I say here is
> accurate.

I can show you how to achieve 99% and higher.

[toc] | [prev] | [next] | [standalone]

#746

jules Gilbert <jules.stocks@gmail.com> wrote:

(snip)
> Oh, one additional difference... I have a program.  It works too.
> Last week I showed it to a friend.  In C, on my laptop, he edited the
> source code, re-compiled it, and he ran it.  He made changes, he was
> driving.   About my friend, he's a better C programmer than I am.  I
> suppose I'm fair, but he's an expert, one of the best programmers I
> have ever worked with.  When I have something difficult to code I give
> it to him.  For when I want it done right.

Coding ability doesn't have much to do with the ability to write
good compressors. It does have to do with making one run fast enough
to be useful, though.

> So what was the program?, well it wasn't a compressor.  Something like
> that I suppose...

> Many times compressors are rated in terms of their ability to predict
> the next bit in a series of bits.  Prediction is useful because it's
> not necessary to send what can be predicted at the RCVE station.  (Why
> send it when you can predict it?)  And this model, this paragraph of
> discussion isn't about subsequent re-compression of RAD, this is all
> true for conventional compression.

Some time ago, I wrote a JBIG2 generic compressor from the JBIG2 spec.
(The decompressor is built into Adobe reader, so I didn't have to
write one of those. Also, I had a good way to test my implementation.)
JBIG2 is for compressing bilevel (black and white but no gray) images.

The prediction is based on neighboring, previously encoded pixels,
up to 16 of them. That is then used for an arithmetic coder, which
codes each bit based on its probability. It is significantly slower
than LZW, mostly because it goes bit by bit instead of byte by byte.

In any case, yes, if you can predict a bit and use that as the input
to an arithmetic coder, and if the prediction only depends on previously
seen bits (so the decoder can make the same prediction) then, yes,
you can build a compressor.

The problem, then, is improving your predictions. To do that, you need
to know some statistics of the data source. 

For lossless compression of scanned text images, JBIG2 does pretty well.
The context, values of the 16 predictor bits, predict reasonably well
to greatly reduce that file size.

-- glen

[toc] | [prev] | [next] | [standalone]

#748

On Jan 9, 4:41 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> jules Gilbert <jules.sto...@gmail.com> wrote:
>
> (snip)
>
> > Oh, one additional difference... I have a program.  It works too.
> > Last week I showed it to a friend.  In C, on my laptop, he edited the
> > source code, re-compiled it, and he ran it.  He made changes, he was
> > driving.   About my friend, he's a better C programmer than I am.  I
> > suppose I'm fair, but he's an expert, one of the best programmers I
> > have ever worked with.  When I have something difficult to code I give
> > it to him.  For when I want it done right.
>
> Coding ability doesn't have much to do with the ability to write
> good compressors. It does have to do with making one run fast enough
> to be useful, though.
>
> > So what was the program?, well it wasn't a compressor.  Something like
> > that I suppose...
> > Many times compressors are rated in terms of their ability to predict
> > the next bit in a series of bits.  Prediction is useful because it's
> > not necessary to send what can be predicted at the RCVE station.  (Why
> > send it when you can predict it?)  And this model, this paragraph of
> > discussion isn't about subsequent re-compression of RAD, this is all
> > true for conventional compression.
>
> Some time ago, I wrote a JBIG2 generic compressor from the JBIG2 spec.
> (The decompressor is built into Adobe reader, so I didn't have to
> write one of those. Also, I had a good way to test my implementation.)
> JBIG2 is for compressing bilevel (black and white but no gray) images.
>
> The prediction is based on neighboring, previously encoded pixels,
> up to 16 of them. That is then used for an arithmetic coder, which
> codes each bit based on its probability. It is significantly slower
> than LZW, mostly because it goes bit by bit instead of byte by byte.
>
> In any case, yes, if you can predict a bit and use that as the input
> to an arithmetic coder, and if the prediction only depends on previously
> seen bits (so the decoder can make the same prediction) then, yes,
> you can build a compressor.
>
> The problem, then, is improving your predictions. To do that, you need
> to know some statistics of the data source.
>
> For lossless compression of scanned text images, JBIG2 does pretty well.
> The context, values of the 16 predictor bits, predict reasonably well
> to greatly reduce that file size.
>
> -- glen

Hi Glen:

First, I realize I over claimed in this post.  Not by much and not
intentionally.   But the program does need some access to the client
data in order to produce a small amount of information which is indeed
sent from SEND to RCVE.

A very small amount of info.  Really   The blocks are 256 bytes.  I
have two configurations I'm trying to make work.  A 4-byte chunk looks
to be the winner.

Second, I am discovering that data independence from a PRNG is a very
difficult thing to achieve.  I got 78% today but doubt if I will ever
be able to use this method to go any higher.  Not unless I use an
actual RAD source and am able to restore it.  Ugh!

And most important, oh...    Here, this application isn't about
compressing and decompressing.  I built this to do something else,
another application.  Something we all read about growing up.  Every
children's book with a science-fiction orientation has one of these.

[toc] | [prev] | [next] | [standalone]

#749

On Jan 9, 6:20 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
> And most important, oh...    Here, this application isn't about
> compressing and decompressing.  I built this to do something else,
> another application.  Something we all read about growing up.  Every
> children's book with a science-fiction orientation has one of these.

Are you writing a compression/decompression system, or aren't you?  If
you're not, stop posting here.  If you are, start posting once you've
successfully transformed data all the way through your system.

[toc] | [prev] | [next] | [standalone]

#750

Am 09.01.2012 15:50, schrieb jules Gilbert:
> Their was a company, a Boston company, actually I think they were in
> Dedham, in the late '80s.  They took $80M in venture money and never
> brought out a product.  Nothing.

Sounds like you're in good company, then. /-:

> Remember, these are not compression figures of merit, these numbers
> are computed by matching each predicted bit with each actual bit.  The
> formula I use is:  (OK*100.) / (OK+NG).

So its still not a compressor. right? Ok, so let me see how this goes? 
You "predict", plus get a "small" error you need to correct by appending 
this to the stream.

Let me make a prediction for you: As you haven't really implemented 
this, you will astonishingly discover that representing the prediction 
error will make things larger than the original stream, even though you 
thought (or had reasons to believe) that this error is actually small.

Believe me, you cannot trick logic like this. That you cannot compress 
random data is not only a theorem, it is probably even the definition of 
random. That you cannot compress all data is based on elementary logic - 
there is nothing to defeat.

> About these figures of merit, the numbers 70%, 75%, and higher.

Plus, additional modeling, plus overhead for the error, which will kill 
any benefit. Of course you won't believe this, but I've seen this 
happening many times, so all I can say that you should sit down and just 
*do* it instead of talking about it, and write a working decompressor - 
which you have failed to deliver over years.

> Oh yeah, about bringing out a compressor...  I was hoping to use the
> method's I've developed to predict, 95%, maybe 98%, of the bits in a
> block of bytes. (Using maxima I can prove that should be possible.)
> And while I have been able to obtain that level of performance, using
> the best means I know today, it's just not practical.  I need to know
> more, I think, or to involve others.

Everyone already pointed you to the literature. Everyone here pointed 
you to the counting argument.

If you want to write a working compressor that is based on prediction, 
there are many that are self-adapting to such statistics. Take the 
predicted bit, XOR with the orignal bit. Provided the prediction only 
depends on the history, but no future bits, such prediction is 
reversible. Then encode the difference between the prediction and the 
actual bit with a off-the-shelve arithmetic encoder. The MQ coder works 
fine. I actually posted such programs a while ago. It will the compress 
the data stream down to its (zero order) entropy, which will be close to 
the ratio you mention.

Anyhow, errors typically made are: Making the prediction depend on the 
future (thus, it is not reversible since the decoder doesn't have that 
available) or requiring a side channel to encode additional information 
to steer the prediction - on random data this scheme will fail because 
the side channel will then require as least as much information to 
compensate for the reduction in the main channel, and you loose any 
benefit this way.

Again: You cannot defeat logic, and that random data is not compressible 
is elementary logic. Or even beyond, it is the definition of randomness. 
For every compressor there is a stream it cannot compress. Or rather: It 
cannot compress the majority of streams, with majority really meaning a 
lot more (actually very close to) 100% of all *possible* streams. That 
compressors work in practise is just because humans don't care about 
random streams, and our data we care about is not at all random.

> As each of you think about my claim to predict so many bits
> successfully -- I recognize what a gulp that must be;  Remember this.
> I'm not predicting randomness, obviously my method works because my
> program understands things about the nature of compressed files.  The
> program doesn't "read" them, ie., it doesn't attempt to decompress
> them or interpret them, it simply treats each file as a block of
> data.  I hope this makes your understanding easier.
>
> Now though...  Well, this is probably the time to look around for a
> large company partner.  A firm with demonstrated ethics first, next,
> with a history in successfully fighting off would-be infringers.
> Also, I am especially willing to consider companies in China.

Any large company parter having at least some serious R&D department 
will outright laugh into your face. You can steal the money by claiming 
that your idea will work, and probably you find even investors that are 
stupid enough to put money into that, but that wouldn't make your method 
working either. Simply because there is a theorem that you cannot 
compress all data.

> You folks think I've been lying to you about what I have.  Nope.  But
> I will let it die with me rather than bring it out only to have it
> stolen.

So then nobody will have to read about such claims here in this group? 
Now, that would be an improvement, too. /-:

[toc] | [prev] | [next] | [standalone]

#751

On 9 Jan., 15:50, jules Gilbert wrote:
> [...]
> Oh, one additional difference... I have a program.  It works too.

Does it print "Hello World!" ?

> So what was the program?, well it wasn't a compressor.

Of course not.

> Something like that I suppose...
> [... prediction ... residual compression via zlib ...]

*Yawn*

> [...]
> And I am not talking about experimental blocks of data that are
> derived using random number generators, in each case the client data
> is derived by reading files produced using gzip, bzip2, arj, and the
> usual compressors we're all familiar with.
> [...]
> I've run my test program with millions of blocks of data produced by
> opening the compressed file, getting the file size, doing fread's to
> get a block of client data, then XOR'ing the data to a pseudo-random
> stream.  Works every time.  Again I have performed this test on
> thousands of compressed files.

gzip, bzip2, arj ... I see ... because they are "random appearing
data", right? And the result of XORing random appearing data with
other random appearing data gets more compressible, right? It's like
fighting fire with fire. Genius!

Take a fair coin. Consider that I flipped it 6 times already: T H T T
T T  (where T=tails, H=heads). What's the probability of the next coin
flip being heads? Keep in mind that a fair coin flip is totally random
and we would expect to roughly get as many tails as heads in such an
experiment.

Also, can you explain the meaning of "works everytime"? What exactly
works? That your program doesn't crash your computer but does
something that you think is cool?

> [...]
> Oh yeah, about bringing out a compressor...  I was hoping to use the
> method's I've developed to predict, 95%, maybe 98%, of the bits in a
> block of bytes. (Using maxima I can prove that should be possible.)

Total bullshit. What does it even mean to "PROVE that something SHOULD
be possible"? Either you "THINK that something SHOULD be possible" or
you "PROVE that something IS possible". Or you "THINK you are able to
PROVE that something IS possible." Your language reveals what's really
going on. You're constantly talking out of your a$$ and not able to
back up anything you're saying, yet and ever.

Hey, it's okay NOT to have developed something incredible. You can
still play here and talk to people. Just stop this nonsense. This
isn't going anywhere.

> And while I have been able to obtain that level of performance, using
> the best means I know today, it's just not practical.  I need to know
> more, I think, or to involve others.

You need to wake up and see things for what they really are. Stop
fooling yourself.

> I do have one engineering change under way that I think will bring my
> consistent block performance to above 78% using my current system, the
> program I have now.  But I'm not claiming that 78% now.  Now I claim
> 75%, the 78% number is still being tested.

Sounds like you're talking out of your a$$ again.

> As each of you think about my claim to predict so many bits
> successfully -- I recognize what a gulp that must be;

But it is.

> Remember this. I'm not predicting randomness, obviously my method
> works because my program understands things about the nature of
> compressed files.  The program doesn't "read" them, ie., it doesn't
> attempt to decompress them or interpret them, it simply treats each
> file as a block of data.

Ok, so, let me get this straight: Are you saying that compressed files
are easier to compress than sequences of fair coin flip results? Yes
or no?

Cheers!
SG

[toc] | [prev] | [next] | [standalone]

#753

What is funny is talking about running this idea in China.

In China if the courts decide you are committing fraud far worse than
going to jail can happen.

[toc] | [prev] | [next] | [standalone]

#756

On Jan 11, 12:08 am, Earl_Colby_Pottinger
<earlcolby.pottin...@sympatico.ca> wrote:
> What is funny is talking about running this idea in China.
>
> In China if the courts decide you are committing fraud far worse than
> going to jail can happen.

Yes, that's true Earl,

However my work is real, my program works, so I wouldn't have a
problem.  And more to the point, you would have some very serious
problems,   For just as you say, the Chinese would have shown you
justice.

In fact I have considered where you and others live and notice that
each of you live in post-Christian countries.

[toc] | [prev] | [next] | [standalone]

#757

On Jan 11, 8:48 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
> On Jan 11, 12:08 am, Earl_Colby_Pottinger
>
> <earlcolby.pottin...@sympatico.ca> wrote:
> > What is funny is talking about running this idea in China.
>
> > In China if the courts decide you are committing fraud far worse than
> > going to jail can happen.
>
> Yes, that's true Earl,
>
> However my work is real, my program works, so I wouldn't have a
> problem.  And more to the point, you would have some very serious
> problems,   For just as you say, the Chinese would have shown you
> justice.
>
> In fact I have considered where you and others live and notice that
> each of you live in post-Christian countries.

Good, then go to China. We are not stopping you.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compression

csiph-web