Gordon Sande <g.sande@worldnet.att.net> writes:> stevenj@alum.mit.edu wrote: > > The IBM 7095 had both 36-bit single precision and 72-bit double > > precision floating-point arithmetic. The C & T paper doesn't say which > > one they used, but I'm guessing that they used single precision on the > > principle that they would have bragged if they had used double. > > > > > > 36 bits in binary, and not 32 bits in hexadecimal, had just enough > precision that the need for double precision was much less common. > The folks on 48 bit machines had trouble understanding why one > used double precision and the folks on 60 bit machines considered > double precision an obscure form of showing off that was totally > unrelated to the real world. > > The 7090 was a 3 index version of the later 7094 which had 7 index > registers. (Is the 9095 for real of just a typo?) 360 model numbers > > often ended in 5 like 360/65 which was a popular model. 360/75 was > hardwired and faster and 360/85 was an early example of the use of > memory caches.I wonder if a 1965 7095 held a candle in speed to a 1988 286 (I believe it was 16 MHz). -- Randy Yates Sony Ericsson Mobile Communications Research Triangle Park, NC, USA randy.yates@sonyericsson.com, 919-472-1124
Fast 1-D DCT algorithms
Started by ●March 11, 2005
Reply by ●March 11, 20052005-03-11
Reply by ●March 11, 20052005-03-11
Reply by ●March 11, 20052005-03-11
Randy Yates wrote:> Gordon Sande <g.sande@worldnet.att.net> writes: > > >>stevenj@alum.mit.edu wrote: >> >>>The IBM 7095 had both 36-bit single precision and 72-bit double >>>precision floating-point arithmetic. The C & T paper doesn't say which >>>one they used, but I'm guessing that they used single precision on the >>>principle that they would have bragged if they had used double. >>> >> >> >> >>36 bits in binary, and not 32 bits in hexadecimal, had just enough >>precision that the need for double precision was much less common. >>The folks on 48 bit machines had trouble understanding why one >>used double precision and the folks on 60 bit machines considered >>double precision an obscure form of showing off that was totally >>unrelated to the real world. >> >>The 7090 was a 3 index version of the later 7094 which had 7 index >>registers. (Is the 9095 for real of just a typo?) 360 model numbers7095>> >>often ended in 5 like 360/65 which was a popular model. 360/75 was >>hardwired and faster and 360/85 was an early example of the use of >>memory caches. > > > I wonder if a 1965 7095 held a candle in speed to a 1988 286 (I > believe it was 16 MHz).IBM 7090/94 was 2 MHz IRC with some at 2.2MHz if they had memories that were engineered for Stretchs (a special machine for selected users). Memory had no extra latency, instructions completed on the same clock rate and no pipeline stalls. Both the instruction and data fetch came on the same clock. No extra cost for index registers so there was no need to fudge the apparent rate. They were not designed for MHz hype with long memory latencies and many clock long instructions. My recollection of comparison tables is that it took a bit faster x86 to do more work than the old mainframes like the 7090. By that time the unit of measure was VAX 780 and then processor outran memory by large amounts.
Reply by ●March 11, 20052005-03-11
Gordon Sande wrote: ...> 36 bits in binary, and not 32 bits in hexadecimal ...<raised eyebrow> Isn't a bit a bit, whichever? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●March 11, 20052005-03-11
Jerry Avins wrote:> Gordon Sande wrote: > > ... > >> 36 bits in binary, and not 32 bits in hexadecimal ... > > > <raised eyebrow> Isn't a bit a bit, whichever? >In floating point there is a secondary issue of the representation base. Heaxadecimal base shortens the exponent reqired but ups the rounding. So 7090 is binary floating point but 360 is hex floating point and a shorter word to boot. Thus more double precision on 360 compared to 7090.> Jerry
Reply by ●March 12, 20052005-03-12
Gordon Sande wrote:> > > Jerry Avins wrote: > >> Gordon Sande wrote: >> >> ... >> >>> 36 bits in binary, and not 32 bits in hexadecimal ... >> >> >> >> <raised eyebrow> Isn't a bit a bit, whichever? >> > > In floating point there is a secondary issue of the > representation base. Heaxadecimal base shortens the > exponent reqired but ups the rounding. > > So 7090 is binary floating point but 360 is hex floating > point and a shorter word to boot. Thus more double > precision on 360 compared to 7090.Got it. You weren't really pointing to representation, but to exponent granularity. I remember those issues. There were more choices tried than 2 and 16. jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●March 12, 20052005-03-12
Jon Harris wrote:> I don't know of any "working and tested" pseudo-code for _anything_! Sometimes > it sure would be nice to have a pseudo-code compiler! :-)The only psuedocode compiler I know of is Python. --Mark
Reply by ●March 15, 20052005-03-15
Koen <xxxno@ssppaamm.comxxx> wrote:> Hi, > > Does anyone know of working and tested code (C/C++/pseudo/...) for > doing a fast 1-D DCT ? > I know about the Numerical Recipes code, but that has a rather > restrictive license... > I also have DCT and IDCT working already using the straight > implementation from the formulas, but I'd be interested in fast > versions (like there exist for FFT for powers of 2). > Thanks in advance! > > KoenEuh... Thanks to everyone who replied, but I still didn't see any answer that fits my purposes... FFTW came closest but GPL is not an option (LGPL would) sadly enough... Anyone else? Or any reference to a web site, paper or book containing code for fast DCT (as said: I know about Numerical Recipes, but that's not a free license). Koen
Reply by ●March 15, 20052005-03-15
"Koen" <no@ssppaamm.com> writes:> Koen <xxxno@ssppaamm.comxxx> wrote: > > > Hi, > > > > Does anyone know of working and tested code (C/C++/pseudo/...) for > > doing a fast 1-D DCT ? > > I know about the Numerical Recipes code, but that has a rather > > restrictive license... > > I also have DCT and IDCT working already using the straight > > implementation from the formulas, but I'd be interested in fast > > versions (like there exist for FFT for powers of 2). > > Thanks in advance! > > > > Koen > > Euh... Thanks to everyone who replied, but I still didn't see any answer > that fits my purposes... FFTW came closest but GPL is not an option (LGPL > would) sadly enough... > Anyone else? > Or any reference to a web site, paper or book containing code for fast DCT > (as said: I know about Numerical Recipes, but that's not a free license). > KoenHi Koen, Poularikas describes a way to use the FFT to implement a fast DCT in the section "Sine and Cosine Transforms" of his book "The Transforms and Applications Handbook" (second edition). There is no code, just theory, but that could be good since there is also no corresponding licensing issue. -- Randy Yates Sony Ericsson Mobile Communications Research Triangle Park, NC, USA randy.yates@sonyericsson.com, 919-472-1124
Reply by ●March 15, 20052005-03-15
Koen wrote:> Euh... Thanks to everyone who replied, but I still didn't see anyanswer> that fits my purposes... FFTW came closest but GPL is not an option(LGPL> would) sadly enough... > Anyone else? > Or any reference to a web site, paper or book containing code forfast DCT> (as said: I know about Numerical Recipes, but that's not a freelicense). Google for FFTPACK and also Ooura FFT, which are the other two good free codes that I already mentioned which contain DCTs of various types.
