Can extra processing threads help in this case?
in [MFC]
|
From: Peter Olcott on 2 Apr 2010 11:39 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:923cr5t67b0tv6mjc0lpi8mnoo6e89mv69(a)4ax.com... > See below... > On Thu, 1 Apr 2010 14:16:30 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: >>> || The term "Sparse Matrix" is taken to have the common >>> meaning >>> || of the term "Sparse" combined with the common >>> computer >>> science >>> || meaning of the term "Matrix", a two dimensional array >>> of elements. >> >> http://en.wikipedia.org/wiki/Sparse_matrix >>To be unambiguously distinguished from: >> >>In the subfield of numerical analysis, a sparse matrix is >>a >>matrix populated primarily with zeros (Stoer & Bulirsch >>2002, p. 619). The term itself was coined by Harry M. >>Markowitz. > **** > Actually, a sparse (2-D, to simplify the discussion) > matrix is a matrix of dimension [m*n] > whose values at some coordinates [i,j] is not defined. > 0.0 is a defined value, and > therefore a matrix with 0 values is not "sparse". > Essentially, a sparse matrix is a > matrix for which the mapping [i x j] -> value is not a > total mapping. > > A numerical analyst is free to redefine this in some other > terms, but the essence of a > sparse matrix is the failure to have a total mapping. The > trick on "comb vectors" is to > create an alternate representation that maintains the > partial mapping of the original > while implementing it as a vector such that the mapping > [i]->value is nearly total (the > difference represents the ability to do perfect > compaction). So in the abstract world, a > sparse 2-D matrix is characterized by a partial mapping > (forall)i (forall)j [i X j]. I > could try to write out the fully general characterization, > but without using Microsoft > Equation Editor it is clumsy. To interpret this any other > way is to misinterpret the > definition, or, as the numerical analysts have apparently > redefined it, to change the > definition to something else. > joe At the time that I wrote the above patent it seemed that the computer science definition of the term was comparable to the numerical analysis definition. This same definition seems to predominate the use of the term when the term [sparse matrix] is searched on google. I hung out in the misc.int.property group while I was prosecuting my patent. One of the things that I found there was that a patent has to be so clear that even a great effort to intentionally misconstrue its meaning will fail. I tried to let this standard be my guide. > >> >>> >>>> So it opens the issue about prior art on some of the >>>> compaction; >>>> I have not read the patent details soo I don't know if >>>> the compaction >>>> model differs from what I know to be past history, but >>>> I >>>> do know >>>> that DFA compaction is still patentable >>> >>> I never disputed that point. As for his patent, on >>> cursory >>> reading it's >>> a combination between a fast DFA "exact pixel matching" >>> recognition >>> (compare to: face tagging in photos, 100% accurate if >>> one >>> has a prior >>> database of the face at all sizes, angles, expressions, >>> lighting etc) >>> and an idea that it could be somehow used for "remote >>> control" of >>> another system (compare to: character-mode screen >>> scraping >>> and >>> keyboard control over a terminal session into a >>> mainframe). I did not >>> mean to, and not going to, argue the merits, or the >>> prior >>> art doubts. >>> The point I tried to make a few times (too many) was >>> that >>> without >>> a viable implementation and/or business plan, the best >>> of >>> patents will >>> forever remain just a piece of paper to frame and hang >>> on >>> the wall. >>> >>> Liviu >>> >>> >> >>I have the design of an implementation that has very >>substantial benefits over any other comparable technology. >>These substantial benefits are very easy to map to >>significant dollar cost savings. My closest competitors >>are >>reportedly making millions, this report might be >>erroneous. >> >>Here is one of these close competitors: >> http://www.testplant.com/ >> >>The design has such substantial benefits over the close >>competitors that it would be able to compete against other >>(not so close) technologies as well. >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Pete Delgado on 2 Apr 2010 12:34 "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message news:HtudnYrh1-GSbCnWnZ2dnUVZ_gKdnZ2d(a)giganews.com... > I have the design of an implementation ....or in other words, you have a vague idea of something that you believe might work better but you have not yet implemented it. ;-) > that has very substantial benefits over any other comparable technology. > These substantial benefits are very easy to map to significant dollar cost > savings. My closest competitors are reportedly making millions, this > report might be erroneous. > > Here is one of these close competitors: > http://www.testplant.com/ THEY actually have a product, evidenced by the user community that has grown around it. > > The design has such substantial benefits over the close competitors that > it would be able to compete against other (not so close) technologies as > well. That remains to be seen. -Pete
From: Joseph M. Newcomer on 2 Apr 2010 12:35 See below... On Thu, 01 Apr 2010 15:04:12 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: > >Peter Olcott wrote: > >>> And a belieft that email is reliable (in spite of the >>> overwhelming evidence that it is >>> not) solves this how? >> >> I asked if email at least had verifiable reliability and no >> one answered. > > >Thats because you were not listening again. **** Actually, nobody answered because the question was essentially silly. Anyone who receives email knows that it isn't very reliable. **** > >> I put Hector on the blocker sender list for a while. His >> rudeness went beyond a tolerable threshold. So your comment >> is vague. > > >Joe thinks you are STUPID too! If fact, I wouldn't be off base the >whole group knows you are stupid! > >> Are all emails acknowledged as received or not? > > >YES all of them. Email is always accepted. You can rest assured in >your patent, trade secrets and business plan, that you can guarantee a >fault tolerance email contact system with your customers so that you >don't have to give refunds in your fictitious wish list product line. **** Acceptance does not guarantee delivery, as I have found out. **** > >>> **** >>> Outlook has a feature to acknowledge to the sender when an >>> email is read, and the first >>> thing any intelligent person does is turn off the feature >>> that says "inform the sender >>> when I have read this message". We call it "invasion of >>> privacy" >> >> I am not talking about whether they read it or not. I am not >> concerned with that. If they pay me some money to ship a >> package and the package arrives, then my obligation is done, >> even if they never open the package. > > >Do you won't offer a federal required return policy? But you will >never have that problem **** Note that if I receive a package, which is left on my porch, and someone steals it, then I have not "received" it. And I'm not going to pay for it. And I WILL demand a refund on my credit card. The reasons FedEx and UPS don't REQUIRE "live signatures" any longer is that they have learned that the probability of theft is nearly zero, the insurance reimburses the sender, who then reimburses me, and paying for the occaasional loss is cheaper than the cost of getting live signatures for every delivery. And some shipments have MANDATORY "live signature" requirements [e.g., my new Dell computer that arrived last week], and if there is a history of packages being stolen from a particular address [e.g., the recipient is committing fraud, or the packages are really being stolen] or thefts to a particular neighborhood, the transporter will impose MANDATORY "live signature" requirements on the delivery. Bottom line: you can't use your excuse on real transactions. The excuses don't have any legal basis. Have fun! **** > >>> I have no idea what you mean by "precisely measurable >>> reliability" >> >> Is there any sort of hand-shaking protocol such that all >> emails are explicitly acknowledged as received by the >> receiving ISP? Even if email itself is very unreliable, as >> long as it always reports its own failure to deliver, then >> we have one aspect of precisely measurable reliability. > > >No such thing - PATENT IT! **** Sorry, My ISP acknowledges receipt, and their anti-spam throws the message away and they don't send it to me, I have not received it. End of story. You seem to have missed this point. In networking terms, "reliable" has a different meaning than the intuitive one. A mechanism that reports errors IS considered "100% reliable" (e.g., TCP/IP) whereas one that does not report errors is considered UNRELIABLE (e.g., UDP). So when my ISP accepts the message, they "reliably" acknowledge that they have received it. Or, if they determine it is spam, they fail to acknowledge that they have received it. But the antivirus algorithm runs AFTER receipt is acknowledged and may yet throw it away. You have failed to understand what is meant by "reliability" and you have made a naive assumption that ACK==DELIVERY. In Real Life, the systems do not work according to your fantasies, and therefore predicating a business plan on fantasies boils down to, in its essence, failure. Also, look into ORBIS (I think that's how the acronym is spelled); my ISP is an ORBIS member, and one of my correspondents goes through a non-ORBIS carrier, and I get about 1 out of 10 messages he sends me. If he sends from another of his email accounts, I get 10 of 10 from that account, because it routes through ORBIS members. ORBIS is an informal anti-spam consortium who simply drop any email that comes from known spam routers. Apparently the way this is handled to is "acknowledge" it and throw it away. But a belief that there is a "100% verifiable" mechanism relies on definitions of the word "verifiable" that are, at best, creative, and an interpretation of probability that goes beyond the formal definition of "Expected value" that every statistics book takes great care to explain. So I'm not sure what you are asking for, but I'm pretty sure your expectations are fantasy. **** > >>> To me, the only reliable mechanism is to drop the >>> transaction, but credit the account. The >>> belief that there is a reliable "callback" mechanism is >>> ill-founded and I would not use >>> anything that was not completely guaranteed to be correct. >>> Crediting the account can be >>> made completely reliable, as long as you are using a >>> transacted database to record the >>> transactions you are charging for (this is why transacted >>> databases were created!) >>> **** > > >> I don't know maybe. Since all users will also have the >> results of their transaction posted to their user account, >> and I won't know that the connection is dropped until the >> most expensive part of the processing is completed, > > >HA! No drop connection detection **** But TCP/IP ALWAYS has a dropped-connection detection! That's one of its design requirementments...of course, you actually have to LOOK for the event! joe **** > > I might >> not do it this way. The nest time that the user logs in, I >> would inform them of these results, and provide a link to >> get these results. If the connection is dropped, they would >> have to log in again to try to repeat the original >> transaction. > > >That will work! Your prices will include surcharge for Peter errors! Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Pete Delgado on 2 Apr 2010 12:45 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:fg5cr5durc5vv2mk649328v1qs9i0inuqu(a)4ax.com... Joe... the responses by Hector on April 1st appear to be jokes... :-) -Pete
From: Peter Olcott on 2 Apr 2010 13:08
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:fg5cr5durc5vv2mk649328v1qs9i0inuqu(a)4ax.com... > See below... > On Thu, 01 Apr 2010 15:04:12 -0400, Hector Santos > <sant9442(a)nospam.gmail.com> wrote: > >> >>Peter Olcott wrote: >> >>>> And a belieft that email is reliable (in spite of the >>>> overwhelming evidence that it is >>>> not) solves this how? >>> >>> I asked if email at least had verifiable reliability and >>> no >>> one answered. >> >> >>Thats because you were not listening again. > **** > Actually, nobody answered because the question was > essentially silly. Anyone who receives > email knows that it isn't very reliable. What about FTP? I could do my on-the-fly backup using FTP. >>Do you won't offer a federal required return policy? But >>you will >>never have that problem > **** > Note that if I receive a package, which is left on my > porch, and someone steals it, then I > have not "received" it. And I'm not going to pay for it. > And I WILL demand a refund on > my credit card. The reasons FedEx and UPS don't REQUIRE > "live signatures" any longer is > that they have learned that the probability of theft is > nearly zero, the insurance > reimburses the sender, who then reimburses me, and paying > for the occaasional loss is > cheaper than the cost of getting live signatures for every > delivery. And some shipments > have MANDATORY "live signature" requirements [e.g., my new > Dell computer that arrived last > week], and if there is a history of packages being stolen > from a particular address [e.g., > the recipient is committing fraud, or the packages are > really being stolen] or thefts to a > particular neighborhood, the transporter will impose > MANDATORY "live signature" > requirements on the delivery. I will sent the results waiting for an HTTP acknowledgement, and only deduct the dime from the account balance if I get an HTTP acknowledgement. These same results will be available for at least thirty days whenever a client logs in. The client request optional email delivery too. This seems sufficient to me, did I miss anything? > > Bottom line: you can't use your excuse on real > transactions. The excuses don't have any > legal basis. Have fun! > **** >> >>>> I have no idea what you mean by "precisely measurable >>>> reliability" >>> >>> Is there any sort of hand-shaking protocol such that all >>> emails are explicitly acknowledged as received by the >>> receiving ISP? Even if email itself is very unreliable, >>> as >>> long as it always reports its own failure to deliver, >>> then >>> we have one aspect of precisely measurable reliability. >> >> >>No such thing - PATENT IT! > **** > Sorry, My ISP acknowledges receipt, and their anti-spam > throws the message away and they > don't send it to me, I have not received it. End of > story. You seem to have missed this > point. In networking terms, "reliable" has a different > meaning than the intuitive one. A That always screws me up. > mechanism that reports errors IS considered "100% > reliable" (e.g., TCP/IP) whereas one > that does not report errors is considered UNRELIABLE > (e.g., UDP). So when my ISP accepts > the message, they "reliably" acknowledge that they have > received it. Or, if they > determine it is spam, they fail to acknowledge that they > have received it. But the > antivirus algorithm runs AFTER receipt is acknowledged and > may yet throw it away. > > You have failed to understand what is meant by > "reliability" and you have made a naive > assumption that ACK==DELIVERY. In Real Life, the systems > do not work according to your > fantasies, and therefore predicating a business plan on > fantasies boils down to, in its > essence, failure. So what about FTP? > > Also, look into ORBIS (I think that's how the acronym is > spelled); my ISP is an ORBIS > member, and one of my correspondents goes through a > non-ORBIS carrier, and I get about 1 > out of 10 messages he sends me. If he sends from another > of his email accounts, I get 10 > of 10 from that account, because it routes through ORBIS > members. ORBIS is an informal > anti-spam consortium who simply drop any email that comes > from known spam routers. > Apparently the way this is handled to is "acknowledge" it > and throw it away. > > But a belief that there is a "100% verifiable" mechanism > relies on definitions of the word > "verifiable" that are, at best, creative, and an > interpretation of probability that goes > beyond the formal definition of "Expected value" that > every statistics book takes great > care to explain. So I'm not sure what you are asking for, > but I'm pretty sure your > expectations are fantasy. > > **** >> >>>> To me, the only reliable mechanism is to drop the >>>> transaction, but credit the account. The >>>> belief that there is a reliable "callback" mechanism is >>>> ill-founded and I would not use >>>> anything that was not completely guaranteed to be >>>> correct. >>>> Crediting the account can be >>>> made completely reliable, as long as you are using a >>>> transacted database to record the >>>> transactions you are charging for (this is why >>>> transacted >>>> databases were created!) >>>> **** >> >> >>> I don't know maybe. Since all users will also have the >>> results of their transaction posted to their user >>> account, >>> and I won't know that the connection is dropped until >>> the >>> most expensive part of the processing is completed, >> >> >>HA! No drop connection detection > **** > But TCP/IP ALWAYS has a dropped-connection detection! > That's one of its design > requirementments...of course, you actually have to LOOK > for the event! > joe So great then this will be my primary basis. Some customers might prefer some sort of batch oriented automated delivery. Email seemed to be the obvious choice. I have never had the degree of difficulty that you have stated as possible. I even bought several software packages where the means of delivery was an emailed link. I guess that the potential unreliability of email must be considered as a caveat to myself and my customers in the case where the customer requests only email delivery. Since their data will be available to them for at least thirty days, (when they log in) this should not present an insurmountable problem. > > **** >> >> I might >>> not do it this way. The nest time that the user logs in, >>> I >>> would inform them of these results, and provide a link >>> to >>> get these results. If the connection is dropped, they >>> would >>> have to log in again to try to repeat the original >>> transaction. >> >> >>That will work! Your prices will include surcharge for >>Peter errors! > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |