Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!pyrdc!gmu90x!peraino From: peraino@gmu90x.gmu.edu (peraino) Newsgroups: comp.sys.handhelds Subject: RE: hp48 application problem: a challenge Message-ID: <2857@gmu90x.gmu.edu> Date: 16 Aug 90 19:17:42 GMT Organization: George Mason Univ., Fairfax Va. Lines: 40 >Date: Thu, 16 Aug 90 11:45:16 -0400 (EDT) >From: Eric Stuyvesant >To: periano@gmuvax.BITNET >Subject: Re: HP-48 application problem; a challenge. >The first thing that seems we have to do is crop the GROB so that we have a >sub-GROB that is just the region we have to work with. It seems that any >algorithm that we use for the later parts must do this. > >Now, for to see if the GROB is entirely on or off: Perhaps you could write >a hash function (BYTES?) that could hash the GROB, then somehow see if the >hash number indicated that the GROB were entirely black or entirely white. >Or, instead of a hash function, maybe do a sum of the GROB, and see if it >is consistent with an N by M blank or full GROB. Thanx for the reply, Eric; Working with the GROB may be the way to go, but unfortunately, I don't think it's all that easy. Remember, GROBs are always rounded up to whole bytes, in terms of the dimensions; so in most cases, there's extraneous data in the GROB. For example, if you have a 4 X 4 solid black GROB, you would think it would look like: GROB 4 4 FFFF but because the dimension is rounded to the nearest whole byte, the GROB looks like: GROB 4 4 F0F0F0F0 so we cannot simply checksum or hash the data as-is. >-Eric Stuyvesant >es2a+hp@andrew.cmu.edu ----------------------------------------------------------------------------- Bob Peraino UUCP : uunet!pyrdc!gmu90x!peraino George Mason University INTERNET: peraino@gmuvax.gmu.edu UCIS, Thompson Hall, rm 2 <- BITNET : peraino@gmuvax 4400 University Drive \ PHONE : (703)-323-2549 Fairfax, VA 22030 \- Yeah, they put us in the basement, too. -----------------------------------------------------------------------------