Author Topic: BKM  (Read 9720 times)

0 Members and 1 Guest are viewing this topic.

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
BKM
« on: August 31, 2016, 05:35:53 pm »
deleted
« Last Edit: May 11, 2019, 11:09:33 am by legacy »
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1668
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #1 on: September 02, 2016, 04:27:52 pm »
I tend to use lookup tables on microcontrollers to avoid having to to calculate sin/cos, etc., during run time.
Complexity is the number-one enemy of high-quality code.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #2 on: September 02, 2016, 06:18:55 pm »
Maybe I am missing something, it happens with old age, but how is this 'new'?  It was first published in 1994.  It's old enough to buy liquor!

Yes, it's about 40 years newer than Cordic but hardly 'new'.

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #3 on: September 06, 2016, 07:28:57 am »
OK.  It's been a long time since my numerical methods class, but:

Quote
But Intel doesn’t use a 128-bit approximation to pi. Their approximation has just 66 bits.Therein lies the problem. When doing range reduction from double-precision (53-bit mantissa) pi the results will have about 13 bits of precision (66 minus 53)...
How does subtracting a number with 66bit precision from a number with 53bit precision end up giving you a result with only 13bits of precision?

 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #4 on: September 09, 2016, 01:36:32 pm »
It sounds like you are having a great time with this and making excellent progress.  It will be interesting to see the 'cost' difference between CORDIC and BKM.  Logic is cheap, speed and accuracy are better metrics.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #5 on: September 10, 2016, 02:19:25 am »
One time, not long ago, I was looking through the floating point library, specifically FEXP (standard precision EXP) for the IBM 1130 and I think I noticed where they were doing range reduction to some oddball limits.  I wonder if they were using the CORDIC algorithms?  This code  would have been written earlier than '65.  The date seems reasonable for CORDIC and too early for BKM.

I see the CORDIC algorithms were first developed at the aeronautics division of Convair which just so happens to be a place where my entire family worked at one time or another between '51 and '69.  We had nothing to do with them...
 

Offline chickenHeadKnob

  • Super Contributor
  • ***
  • Posts: 1055
  • Country: ca
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #6 on: September 10, 2016, 10:06:17 am »
One time, not long ago, I was looking through the floating point library, specifically FEXP (standard precision EXP) for the IBM 1130 and I think I noticed where they were doing range reduction to some oddball limits.  I wonder if they were using the CORDIC algorithms?  This code  would have been written earlier than '65.  The date seems reasonable for CORDIC and too early for BKM.

I see the CORDIC algorithms were first developed at the aeronautics division of Convair which just so happens to be a place where my entire family worked at one time or another between '51 and '69.  We had nothing to do with them...

Not impossible but I would say doubtful. Your mention of range reduction struck a memory.

Volder's CORDIC IEEE paper which generalizes cordic  to other elementary functions dates to around 1967 if I recall correctly. In the seventies I was a teenager and had my first TI scientific calculator given to me. It was the thing that prompted me to teach my self how to code and find out how these things worked. So off to my local university 26 miles away and I scavenged the libraries and computer rooms for answers. The uni had at that time 360 and 370 mainframes which were eventually replaced some years with Amdahl improvements. In the general access computer  labs were the manuals of most use to students, held in those bolt thru trays so you couldn't steal them! But none contained any documentation on how the scientific library routines were implemented. For that I had to sneak into the special book room in the building that housed the university systems programmers. It was like finding that mega stash of playboys your dirty uncle hid in his tool shed.  >:D 

Knowing I had limited time for this mission impossible before being discovered I flipped through all the manuals as fast as I could. By some luck I found the Fortran code very quickly. It was nothing like what I expected. Convoluted and arcane with many if branches on input range. The trig functions had some obvious reductions to quarter angle or finer but then the code lost me. In all cases the final calculation was a unique (to that branch) rational polynomial. I had the sense that some masterful math PHD (of which IBM had many) had handcrafted and tuned the whole thing. I was evicted from the building before I could spend quality time studying the code so my memory is limited and fading.

Now you can say the 360 family does not equal 1130, fair enough. The general design choice at the time and still today was if you had four banger floating point hardware you used either rational polynomials or chebyshev polynomial approximations not Taylor series!. I don't know how many times over the years I have had to educate engineers  you don't use Taylor series for anything. And if you only had an integer CPU then CORDIC.  I was under the impression  the 1130 did have some form of floating point assist and it certainly had a fortran  implementation which makes the 360 style fortran library more likely in my mind.  Besides CORDIC is not how those egg heads at IBM would roll.



 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #7 on: September 10, 2016, 02:45:35 pm »

Now you can say the 360 family does not equal 1130, fair enough. The general design choice at the time and still today was if you had four banger floating point hardware you used either rational polynomials or chebyshev polynomial approximations not Taylor series!. I don't know how many times over the years I have had to educate engineers  you don't use Taylor series for anything. And if you only had an integer CPU then CORDIC.  I was under the impression  the 1130 did have some form of floating point assist and it certainly had a fortran  implementation which makes the 360 style fortran library more likely in my mind.  Besides CORDIC is not how those egg heads at IBM would roll.

I don't know anything about the 360s but I am intimately familiar with the 1130 having built an FPGA version that runs all of the IBM software without change.  The 1130 was the first computer I ever used ('70..) and it has been a 46 year love affair.  I still use FORTRAN IV and the attached plotter (really an HP Laserjet) to demonstrate programming and math to my grandson.

The 1130 does not have floating point assist.  In fact, it doesn't even have a decent adder in that carries are saved and additional add cycles are used until none remain.  Even something as simple as adding is implemented with the absolute minimum possible hardware.  No, my version doesn't do that...  I don't do multiply one bit at a time either and, for whatever gain there might be, I implemented non-restoring division.

I didn't spend enough time looking at the FEXP() function but it could have been a polynomial implementation.  I just glanced over the comments and moved on.
« Last Edit: September 10, 2016, 03:07:50 pm by rstofer »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #8 on: September 10, 2016, 07:55:25 pm »
googling it seems that those IBM machines were big irons :D

And, for scientific applications, the Control Data machines were bigger and faster.  For the times...

The CDC 6xxx machines had a 60 bit integer which eliminated the need for floating point in many applications but the same 60 bits was used for floating point.

Interestingly, integer multiply and divide was performed in floating point and included conversions.

At the time, FORTRAN could reach 0.5 MFLOPS and assembly language could reach 3 MFLOPS.  Today we can get 500 GFLOPS with a XEON chip!

https://en.wikipedia.org/wiki/CDC_6600#Wordlengths.2C_characters

It is amazing how far we have come since the early '70s!

https://www.microway.com/knowledge-center-articles/detailed-specifications-intel-xeon-e5-2600v3-haswell-ep-processors/
 

Offline Tom45

  • Frequent Contributor
  • **
  • Posts: 556
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #9 on: September 11, 2016, 04:25:57 pm »
a good book:
Elementary Functions, Algorithms and Implementation
by Jean-Michel Muller

Thanks for mentioning this book. I hadn't been aware of it until now and have ordered a copy.

A much earlier book is Approximations for Digital Computers by Cecil Hastings.

Looking at the Muller book's contents on Amazon, a lot has happened since Hastings wrote his little book in 1955.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #10 on: September 11, 2016, 08:19:24 pm »
a good book:
Elementary Functions, Algorithms and Implementation
by Jean-Michel Muller

Thanks for mentioning this book. I hadn't been aware of it until now and have ordered a copy.

A much earlier book is Approximations for Digital Computers by Cecil Hastings.

Looking at the Muller book's contents on Amazon, a lot has happened since Hastings wrote his little book in 1955.

I ordered a copy from Alibris, it should be an interesting read.  I have many books on computer math but they tend to deal with hardware integer and floating point arithmetic and don't really address complex elementary functions.

BTW, 'complex elementary' seems like an oxymoron!
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #11 on: September 23, 2016, 06:27:37 pm »
That's really great work!
 

Offline brokenshakles

  • Newbie
  • Posts: 3
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #12 on: September 30, 2016, 07:25:02 am »
I concur! I'm really hoping a code sample to study, as I am interested in a fast solver for the basic trig functions for fixed point numbers.
 

Offline brokenshakles

  • Newbie
  • Posts: 3
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #13 on: October 01, 2016, 06:00:31 pm »
I considered that, but I'm not sure which of the funcs beyond the basics ones I will need ultimately, and I like more generalized solutions.  Is your git coded in C?

Edit: Also, does it accept fixed point numbers as inputs and give fixed point numbers as output?  Is the position of the fixed point adjustable on init?

Edit2: I also need tan and arctan, I'm not sure if CORDIC covers that.
« Last Edit: October 01, 2016, 06:09:56 pm by brokenshakles »
 

Offline brokenshakles

  • Newbie
  • Posts: 3
  • Country: us
Re: BKM, New Hardware Algorithm for Complex Elementary Functions
« Reply #14 on: October 01, 2016, 07:46:20 pm »
hmm, what about rescaling the output?  I heard that cordic messes with the unit scale. I am aware of the range reduction, but unsure how to implement such a thing, I'm mostly busy with all the other bits of code I need OTHER than a func to provide basic trig operations for fixed point numbers, which is why I'm asking around. Also, I'm using 64 bit ints to represent a fixed point number with 48 bits of integers, so wouldnt it be 80/64 ticks?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf