Re: Is this comprehensible?

From: Philippe Verdy (
Date: Fri Jan 28 2011 - 15:08:45 CST

  • Next message: Ed: "WAS: On the possibility of encoding some localizable sentences ... NOW: Linguistic Humor (WARNING: off-topic)"

    Complete non-sense. Too many ambiguities, and full of syntaxic problems.
    Even as a non-native English speaker, I can easily sea that this non-sense
    is produced by some automatic translator, trying to mimic your own
    non-English language, and that you absolutely don't understand English
    enough to correct it and give it some meaning, even if there are no visible
    typos in the words. All this looks like a concatenation of words in random

    Please ask help to someone that better knows English than you and can you to
    translate it. But for now, it would even be better to post directly in your
    own native language.

    All I can see from what you are writing is that you are trying to describe
    (in a very bad formulation) a very imprecise heuristic for some wellknown
    statistical compression algorithms, such as the Huffman compression, or
    the arithmetic compression (IBM patented, I don't know if it's expired now).
    Your description is so ambiguous that it seems you are trying a
    circumvolution around all similar algorithms, just to find a hole not
    covered by one of the many patents (including many that have expired), or
    algorithms that are in the public domain since long in many countries.

    Note that many of these algorithms will fall in the scope of the MPEG LA, so
    be prepared to the fact that you may in fact breach many existing and valid
    patents covered in this hot area, so you'll have to be much more precise to
    describe the effective claims that you are trying to protect, and to
    describe the related claims that you don't own and that you'll have to
    credit if they are essential to the effective implementation of your idea.
    For these reasons, all indicates in your text that your poor text will be
    rejected by any patent bureau.

    But once again, generic binary data compression (the subject of your
    messages) has nothing to do with the Unicode and ISO/IEC 10646 standards, or
    the character encoding process, or representation and processing of encoded
    texts (including character properties for such processing), which are the
    real purpose of this mailing list.

    If you intend to develop a new compression algorithm, there are much better
    suited discussion or publication areas. Try first to write an article, put
    it in some PDF form, and try finding an university in your country to review
    your paper and that will accept to publish it. If you can't write it
    correctly in English, at least you'll be able to publish it in your own
    language, and someone will help you make a correct translation of it for
    republishing on wellknown international IT research
    forums/groups/commitees/papers, such as the ACM or IEEE proceedings.

    And if you are still trying to create a patent from your algorithm, please
    consult a patent bureau in your country (you'll need money anyway to
    register this patent, and probably a specialized lawyer, which will cost you
    even much more than paying for a minimally qualified translator ; and if you
    want to register it internationally, you'll really need such a translator
    for ar least one language that each patent bureau will be able to process
    for your registration).

    But this mailing list is not the correct place for create a proof of
    first-authorship, notably because it is completely out of topic for your


    2011/1/28 <>

    > Concatenate enumerated half the combinations of binary digits, and other
    > halves.
    > Concatenations may comprise that of other halves and enumerations such
    > that some of it may be removed. Such some of it may be which does not have
    > combinations in the either of enumerations then, substitute either the
    > combination furthest away from these other enumerations, or the following
    > furthest combination, with opposite combination.
    > The coding roughly proportional to frequency may be including other codes
    > such that another code is made of combined concatenation and any other
    > suitable binary digit(s) such as a concatenation. Such a concatenation may
    > be removed from the coding, the following combinations include this removed
    > concatenation whenever it is possible and the fewer bit codes assigned
    > directly to the frequently used characters to prevent the assigning of the
    > characters to the bits unexploited or recurring.

    This archive was generated by hypermail 2.1.5 : Fri Jan 28 2011 - 15:11:43 CST