Can extra processing threads help in this case?
in [MFC]
|
From: Peter Olcott on 31 Mar 2010 22:40 "Liviu" <lab2k1(a)gmail.c0m> wrote in message news:esywI%23T0KHA.4832(a)TK2MSFTNGP04.phx.gbl... > "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >> "Bill Snyder" <bsnyder(a)airmail.net> wrote... >>>>"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >>>>> >>>>> Time will tell. I have 20,000 hours invested so far. >>>> >>> He didn't say it was 20,000 hours of his *own* time >> >> 20,000 hours of my own time. > > Back in 2006, by your own count elsewhere, you had 18K > hours "invested" > and said "must have the commercial project complete within > a maximum of > six months". Now you are up to 20K hours and downgraded to > "worst case > is at about a year from now". One arrow points in the > wrong direction. > >> I still don't envision much of a market for the first >> product since >> it only recognizes machine generated character glyphs > > Yet, that's what you patented. Wonder why you artificially > limited the > scope to OCR and screens, If you read much of the patent you would see that this is not the case. You aren't looking for truth though, you are only looking for amusement. > rather than call it, say, "foolproof matching > of arbitrary polygons in two-dimensional lattices". > >> The way that projects such as this typically works is the >> originator >> sells out to VC, VC takes 97% of the ownership and the >> product gets >> quickly to market. > > First, you need to have a product, then find VC to buy > into your "read > it on wikipedia, heard it on usenet" stories, and finally > get everybody > else to pay the 10-cent-per-pop, whatever "pop" is. Yes, > it's that easy. > > Many happy returns of the April 1st day! > > Sure just like the guy that invented the steamboat: Fulton's Folly Although I don't expect that my technology will have as much impact as the steamboat.
From: Liviu on 31 Mar 2010 23:56 "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... > "Liviu" <lab2k1(a)gmail.c0m> wrote... >> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >> >>> I still don't envision much of a market for the first product since >>> it only recognizes machine generated character glyphs >> >> Yet, that's what you patented. Wonder why you artificially limited >> the scope to OCR and screens, > > If you read much of the patent you would see that this is not the > case. Oh, right... There is also the "store a DFA as a sparse matrix" thing. Btw, and unrelated, but you have a typo somewhere in there... || According to a preferred embodiment, the forgoing ActionCodes || may be implemented within a "switch" statement such that a sequential || "jump table" is generated in the compiled executable code. >> rather than call it, say, "foolproof matching >> of arbitrary polygons in two-dimensional lattices". FYI a (connected) glyph on a raster display is technically a polygon in a 2D [point] lattice. And what you propose is, essentially, that given the precise font a priori, you can then locate matching glyphs in a bitmap later. In your own words... || The reason that OCR4Screen is so much faster and accurate || than OCR technology is that OCR4Screen only processes exact || matches of pixel patterns. Technically this is called a deterministic || process as contrasted with the stochastic process that OCR uses. || || This difference has the advantage that it can be much faster and || 100% accurate. The disadvantage is that OCR4Screen can only || process machine generated character glyphs (and other graphical || objects) that always have exactly the same set of pixels. > You aren't looking for truth though, you are only looking for > amusement. This is turning towards sad, rather than amusing. Liviu
From: Peter Olcott on 1 Apr 2010 09:37 "Liviu" <lab2k1(a)gmail.c0m> wrote in message news:OXUdX%23U0KHA.3652(a)TK2MSFTNGP04.phx.gbl... > "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >> "Liviu" <lab2k1(a)gmail.c0m> wrote... >>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >>> >>>> I still don't envision much of a market for the first >>>> product since >>>> it only recognizes machine generated character glyphs >>> >>> Yet, that's what you patented. Wonder why you >>> artificially limited >>> the scope to OCR and screens, >> >> If you read much of the patent you would see that this is >> not the >> case. > > Oh, right... There is also the "store a DFA as a sparse > matrix" thing. No that is not it, see: Appendix G > > Btw, and unrelated, but you have a typo somewhere in > there... > > || According to a preferred embodiment, the forgoing > ActionCodes > || may be implemented within a "switch" statement such > that a sequential > || "jump table" is generated in the compiled executable > code. > >>> rather than call it, say, "foolproof matching >>> of arbitrary polygons in two-dimensional lattices". > > FYI a (connected) glyph on a raster display is technically > a polygon > in a 2D [point] lattice. And what you propose is, > essentially, that > given the precise font a priori, you can then locate > matching glyphs > in a bitmap later. In your own words... > > || The reason that OCR4Screen is so much faster and > accurate > || than OCR technology is that OCR4Screen only processes > exact > || matches of pixel patterns. Technically this is called a > deterministic > || process as contrasted with the stochastic process that > OCR uses. > || > || This difference has the advantage that it can be much > faster and > || 100% accurate. The disadvantage is that OCR4Screen can > only > || process machine generated character glyphs (and other > graphical > || objects) that always have exactly the same set of > pixels. > >> You aren't looking for truth though, you are only looking >> for >> amusement. > > This is turning towards sad, rather than amusing. In any case you are not looking for truth. > > Liviu > >
From: Joseph M. Newcomer on 1 Apr 2010 12:30 See below... On Wed, 31 Mar 2010 10:58:24 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:04l6r5pbufl74s28tl65irc89upid2al4g(a)4ax.com... >> See below... >> On Tue, 30 Mar 2010 17:42:28 -0400, Hector Santos >> <sant9442(a)nospam.gmail.com> wrote: >> >>>Joseph M. Newcomer wrote: >>> >>>>> Sure I have you just haven't gotten to it yet, email. I >>>>> haven't got any more time for this discussion. I am >>>>> convinced that I will get it right. I will get back to >>>>> you >>>>> on this when I am pretty sure that I have it right and >>>>> you >>>>> can double check my final design. >>>> **** >>>> Oh, in your fantasy world, email is a reliable delivery >>>> mechanism? It isn't out here in >>>> the real world. And did you read Hector's comments on >>>> email acknowledgement (and he's far >>>> more an expert on email than I am; all I know is that >>>> there are serious reliability issues >>>> with email; the evidence is that people send me email >>>> which I never receive, and which >>>> never even arrive at my ISP, although there is a record >>>> that they were sent). >>> >>> >>>I am an active member and contributor of the SMTP working >>>group/mailing list. I'm acknowledged in the RFC 5321 SMTP >>>specification. >>> >>> http://tools.ietf.org/rfc/rfc5321.txt >>> >>>including acknowledged in the recently RFC 5598 endorsed >>>creation of >>>the "Internet Mail Architecture," document by one of the >>>fathers of >>>electronic mail, David Crocker: >>> >>> http://tools.ietf.org/rfc/rfc5598.txt >>> >>>I write and market a very highly integrated modern mail >>>system and >>>been doing mail systems since the 80s. I think I know >>>maybe *a >>>little* about this. :) >> **** >> Which is why I said your credentials were better than mine >> in this area! >> **** >>> >>>> Apparently, you once read an article on email, and now >>>> believe you understand it >>>> completely. Even your concept of a "veriiable email >>>> address" shows a degree of >>>> cluenessness that is, alas, unsurprising. >>> >>> >>>Abstract level thinking :) which is ok, if he had the >>>integration right. >>> >>>For example, for all this fault tolerant talk, if the >>>machine dies , >>>how can it even send email? That means he needs an >>>integrated >>>redundancy that deals email. His database has to be on a >>>remote >>>server as well which I'm sure he didn't take into account >> *** >> If he uses a transacted database, upon recovery, there can >> be a process that scans the >> database and detects a transaction that was "in flight" >> but "uncompleted" and send the >> email then. Of course, this can take the 500ms limit to >> hours or days, but what's a >> little flexibility with the realtime window, given the >> mooshiness of the rigid and >> non-negotiable requirements. >> >> Of course, this DOES presume that "recovery" is a >> possibility; if the hard drive fried, >> there IS no "recovery" >> >> Oh, wait a moment: he's using RAID 1. And we know that it >> has ZERO performance cost over >> a regular hard drive, because he wouldn't choose to use it >> had any performance penalty. >> Unless throwing buzzwords around has zero cost. And this >> presumes that someone decides >> that it not simply easier to replace the failed computer >> without trying to do any >> recovery. Of course, this would be part of his contract >> with the ISP, to guarantee that >> no matter how cost-ineffective it is for the ISP, the ISP >> will have to try to do recovery. >> And the commodity ISP will agree to this without charging >> extra. And all the little pink >> puppies will live happily ever after, the evil sorceror >> will be conquered, and the Ring >> will be returned to the volcanoes of Mordor. Sorry, I get >> carried away. I sometimes lose >> my grasp of what is fantasy and what is reality. >> >> (And in December, a component failure in the SCSI >> backplane of my server corrupted two of >> my three RAID-5 drives. So much for redundancy. >> Fortunately, my Business Continuity >> clause in my insurance policy meant that my business >> insurance covered the US$6,000 >> recovery cost). >> joe >> **** > >If the only thing that I must insure does not occur is that >the customer is not charged for a transaction that did not >complete, this simplifies the design. **** And a belieft that email is reliable (in spite of the overwhelming evidence that it is not) solves this how? Better to simply credit the account and drop the transaction. If they want it, they'll submit again, knowing the uncompleted transaction had been credited to their account. Never mind, I just answered how: a "belief" is good enough, facts don't actually matter. **** >For every complex set >of issues there is always a way to minimize the effective >complexity. **** "For any problem, there is a solution that is simple, obvious, and wrong". -- H.L. Mencken **** > >One thing that I need to know hopefully without the need to >read a 1,000 page book first, Is there any way that the >sender of an email message can automatically confirm that an >email was received. This is one of the questions that I know >needs to be answered and if no one else is helpful on this I >will eventually find it elsewhere. **** Did you read Hector's message explaining email acknowledgements? Turns out that an acknowledgement of receipt has value to spammers, which is why an ISP is now permitted to acknowledge receipt and discard the message, at any stage along the way. > >If email has precisely measurable reliability, then on the >fly backups of transaction details can be made. **** 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 have no idea what you mean by "precisely measurable reliability" and what this has to do with anything real. For example, suppose I told you "I have precisely measured the reliability, and the probability your message is actually received is 0.48�0.02. That is *precise* but it does not solve your problem, because it says that there is less than a 50% probability that your email will be received. You have apparently confused "precisely measurable" with "100% probability". And notice 100% probability is not the same as saying there can be no failure (if you don't believe this, a remedial course in statistics would be necessary). 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!) **** > >> Corollary: this system will be such a finacial success (at >> $0.10/transaction) that he will >> soon have unlimited funds to hire people to solve all the >> very real problems he has been >> ignoring. [He even said so!] > >It is not a matter of counting my chickens before they >hatch, it is a matter of simple arithmetic. The minimal >system will be able to handle at least 10 transactions per >second. (With the redesign it is looking more like 100 per >second now). I will have to have sufficient load on my >system before upgrading it is justified. There is no sense >upgrading a system for much better performance if peak load >it is only at 1% of capacity. This 1% of capacity produces a >dime a second. Even an huge degree of difference between >peak load and average load should not change this overall >evaluation much. Whenever I do need to upgrade beyond a >single core processor, I will be able to afford it, and it >looks like a long time before I will need to upgrade. **** I can handle X number of transactions per second, and therefore people will actually engage in enough of a percentage of X number of transactions per second to generate significant revenue. Capacity is not utilization. If I build a grocery store, put 22 checkout lanes in it, populate them with 22 cashiers, I will not survive if the average purchase is $2.00 each from 40 customers a day. I've had business plans I worked on (and I was not the principal of the company) turned down because the plan did not demonstrate that the expected income could be realized. As a sanity check, get a real financial expert to review the business plan for feasibility. They will ask some important questions, and handwaves will not suffice for answers. In fact, I believe that the banks and venture capitalists were justified in turning down our business proposals because those proposals were weak in how the technology would be turned into revenue. In later years, we got better at writing proposals. Then both of us decided we no longer had the energy to do a startup (by the time you hit 55, the ability to pull 80-hour weeks decreases, as does the motivation. If you look at your finances and say "I could retire, comfortably, now, or I could do a startup" the choice gets easy after age 55. It doesn't mean I haven't learned a lot in trying to do thos startups between age 35 and 55. We would come up with a new idea every 2-3 years. ***** > >> >> One thing I learned being self-employed: every expense >> turns out to be expressible >> precisely in hours of my time. So to hire me for 1 hour >> will require 1,000 transactions. >> And I'm cheap (I've been told I consistently underprice >> myself). A full-time person >> requires about 2,500 transactions for every hour they >> work, so to support a full-time >> person requires 1370 transactions every day, 57 >> transactions/hour EVERY HOUR OF EVERY DAY >> just to break even. That's a little under 1/minute > >Right and the cheap single core processor can do 100 per >second, so there is a much greater chance that I would hire >you or someone else than there is that I would need to >upgrade beyond a single core, thus all this talk about >multiple threads or multiple processes is not really >cost-effective for me right now. **** I'm glad that you know that. It is important to know cost-effectiveness of solutions. joe **** > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 1 Apr 2010 12:51
See bekiw,,, On Wed, 31 Mar 2010 22:56:59 -0500, "Liviu" <lab2k1(a)gmail.c0m> wrote: >"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >> "Liviu" <lab2k1(a)gmail.c0m> wrote... >>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >>> >>>> I still don't envision much of a market for the first product since >>>> it only recognizes machine generated character glyphs >>> >>> Yet, that's what you patented. Wonder why you artificially limited >>> the scope to OCR and screens, >> >> If you read much of the patent you would see that this is not the >> case. > >Oh, right... There is also the "store a DFA as a sparse matrix" thing. **** Back in 1982, I implemented a new kind of sparse matrix approach, "comb vectors", based on a research paper from the University of Karlsruhe, Karlsruhe, Germany, which outlined the algorithm. I'm not sure if Gerhod Goos was one of the authors or it was a set of his students; I no longer have the paper. But it "interlaces" the "holes" in a parse-table vector so that we got incredible density in the immense parse tables. I still have the code, but cannot release it. So recompaction of spare matrices was an idea that was well-understood in 1981 or so. 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 know someone who has a patent on a DFA recognizer for deep packet examination in a fiewwalll device; the patent is on the compaction algorithm and the fact that each state transition can be done in nanoseconds, so it works in real-time as the packet comes by and introduces no delays) joe > >Btw, and unrelated, but you have a typo somewhere in there... > >|| According to a preferred embodiment, the forgoing ActionCodes >|| may be implemented within a "switch" statement such that a sequential >|| "jump table" is generated in the compiled executable code. > >>> rather than call it, say, "foolproof matching >>> of arbitrary polygons in two-dimensional lattices". > >FYI a (connected) glyph on a raster display is technically a polygon >in a 2D [point] lattice. And what you propose is, essentially, that >given the precise font a priori, you can then locate matching glyphs >in a bitmap later. In your own words... > >|| The reason that OCR4Screen is so much faster and accurate >|| than OCR technology is that OCR4Screen only processes exact >|| matches of pixel patterns. Technically this is called a deterministic >|| process as contrasted with the stochastic process that OCR uses. >|| >|| This difference has the advantage that it can be much faster and >|| 100% accurate. The disadvantage is that OCR4Screen can only >|| process machine generated character glyphs (and other graphical >|| objects) that always have exactly the same set of pixels. > >> You aren't looking for truth though, you are only looking for >> amusement. > >This is turning towards sad, rather than amusing. > >Liviu > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |