home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / programm / 2466 < prev    next >
Encoding:
Text File  |  1992-08-25  |  1.7 KB  |  36 lines
  1. Newsgroups: comp.programming
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!linus!linus.mitre.org!el_padre.mitre.org!bdickens
  3. From: bdickens@el_padre.mitre.org (Brian Dickens)
  4. Subject: Morphology and Convolution 
  5. Message-ID: <1992Aug25.160119.28049@linus.mitre.org>
  6. Keywords: morphology,convolution,aaaaargh
  7. Sender: news@linus.mitre.org (News Service)
  8. Nntp-Posting-Host: el_padre.mitre.org
  9. Organization: The MITRE Corporation, Bedford, MA 01730
  10. Date: Tue, 25 Aug 1992 16:01:19 GMT
  11. Lines: 23
  12.  
  13. I am trying to perform convolution on a rectangular matrix of numbers.  I have a program
  14. which does basically what I want to do, but it does it 20 times faster than my program.  There
  15. is a rather straightforward brute force algorithm to do it, which I'm using, but I think there
  16. might be a better way.
  17.  
  18. I have two input matrices... one of bytes, and one of floating point numbers.  The floating
  19. point numbers are used as a sliding window over the data, and for each square on the data,
  20. the corresponding number on the floating point window is multiplied by the data value, and
  21. the results of all these multiplications are summed up and stored in the output matrix.
  22.  
  23. The concept is much like local averaging, but more flexible, because the priorities of each
  24. square can be adjusted.
  25.  
  26. Is there any way to perform the multiplication of a byte value (a la 15) by a floating point
  27. value (a la 0.2112) in a fast manner?  i.e. conversion of the floating point number into a fraction,
  28. and then merely perform integer multiplication and division?
  29.  
  30. -bdickens
  31.  
  32. Sorry if this doesn't make sense... but I've really hit a brick wall here.  The speed of the
  33. existing code is far too superior to mine... it's frustrating.
  34.  
  35.  
  36.