Post by thread:[PIC] 64 Bit Float

On Sat, Jan 10, 2009 at 9:29 PM, peter green <spam_OUTplugwashTakeThisOuTp10link.net> wrote: > Sadly I think the only way is to define a structure with sufficiant > storage and then write your own functions/macros to work on it. Thanks for your reply. Looks like it's time to switch to PIC32 as their C32 compiler supports 64 bit long double data types - just what I need. I ordered my PIC32 chip in December, still has not arrived... -- solarwind

It would probably be easiest to take someone's existing library and adapt it. For example, one could take floating point libraries written for other processors and port them to a PIC. Alternatively, one could take PIC floating point libraries and modify them to work with a 64bit float (often called a "double" in C). I think that one of these approaches is probably much easier than starting from scratch. Sean On Sat, Jan 10, 2009 at 9:29 PM, peter green <.....plugwashKILLspam@spam@p10link.net> wrote: > solarwind wrote: >> Does anyone have any idea how I can have a 64 bit floating point type >> in HI-TECH C or Microchip C18? >> > Sadly I think the only way is to define a structure with sufficiant > storage and then write your own functions/macros to work on it. > > > > -

On Sat, Jan 10, 2009 at 11:13 PM, Sean Breheny <shb7KILLspamcornell.edu> wrote: > It would probably be easiest to take someone's existing library and > adapt it. For example, one could take floating point libraries written > for other processors and port them to a PIC. Alternatively, one could > take PIC floating point libraries and modify them to work with a 64bit > float (often called a "double" in C). I think that one of these > approaches is probably much easier than starting from scratch. > > Sean When I started this calculator project, I was totally not expecting to be writing floating point libraries from scratch - in assembler. What a nightmare. This would also force me to program my entire application in assembler as well. I'd rather wait for my PIC32 to arrive, grab Microchip's PIC C 32 and use its 64 bit floating point math library. -- solarwind

Hi solarwind, The whole point of my reply was to suggest that you NOT write your library from scratch but rather modify someone else's library. I would think that you could find ones written in C. Even if you wrote one in assembler, that would not force you to write the rest of your code in asm. You can link together asm and C modules. That being said, if the C32 compiler supports this natively, then I agree that that's the best way to go. By the way, have you verified that the 64 bit double has enough precision for your calculator app? Note that there are several standards for floating point numbers and that "long double" doesn't mean the same thing for all systems. For example, I think on PCs a "long double" is usually 80 bits. Sean On Sat, Jan 10, 2009 at 11:24 PM, solarwind <.....x.solarwind.xKILLspam.....gmail.com> wrote: {Quote hidden}> On Sat, Jan 10, 2009 at 11:13 PM, Sean Breheny <EraseMEshb7spam_OUTTakeThisOuTcornell.edu> wrote: >> It would probably be easiest to take someone's existing library and >> adapt it. For example, one could take floating point libraries written >> for other processors and port them to a PIC. Alternatively, one could >> take PIC floating point libraries and modify them to work with a 64bit >> float (often called a "double" in C). I think that one of these >> approaches is probably much easier than starting from scratch. >> >> Sean > > When I started this calculator project, I was totally not expecting to > be writing floating point libraries from scratch - in assembler. What > a nightmare. This would also force me to program my entire application > in assembler as well. I'd rather wait for my PIC32 to arrive, grab > Microchip's PIC C 32 and use its 64 bit floating point math library. > -- > solarwind > -

On Sat, Jan 10, 2009 at 11:51 PM, Sean Breheny <shb7spam_OUTcornell.edu> wrote: > Hi solarwind, > > The whole point of my reply was to suggest that you NOT write your > library from scratch but rather modify someone else's library. I would > think that you could find ones written in C. > > Even if you wrote one in assembler, that would not force you to write > the rest of your code in asm. You can link together asm and C modules. > > That being said, if the C32 compiler supports this natively, then I > agree that that's the best way to go. > > By the way, have you verified that the 64 bit double has enough > precision for your calculator app? Note that there are several > standards for floating point numbers and that "long double" doesn't > mean the same thing for all systems. For example, I think on PCs a > "long double" is usually 80 bits. > > Sean Thanks! Searching now! Tell me if I'm right: Ok, according to wikipedia (http://en.wikipedia.org/wiki/Floating_point), the IEE 754 64-bit floating point has a 52 bit mantissa. Since the first bit is implied, we can say 54 bits mantissa, that is, 54 bits of precision. So: 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 11 in binary = 16777215 in decimal which is 8 decimal digits of precision (including implied 1 on most significant bit) and more than enough exponent range to keep me happy. I would easily go with a 128 bit floating point if I find any. -- solarwind

Update: my mistake, the calculation is wrong. With 54 bits, the maximum value I can have is 18014398509481983 which is 17 digits. Update: quote from wikipedia: * Single precision, called "float" in the C language family, and "real" or "real*4" in Fortran. This is a binary format that occupies 32 bits (4 bytes) and its significand has a precision of 24 bits (about 7 decimal digits). * Double precision, called "double" in the C language family, and "double precision" or "real*8" in Fortran. This is a binary format that occupies 64 bits (8 bytes) and its significand has a precision of 53 bits (about 16 decimal digits). They say around 16 digits for 64 bit float, but it was 17 in my calculation. They're saying 7 digits for 32 bit float but I got 8 in my calculation.

I'd suggest that you read the entire wikipedia article on floating point which you linked to earlier. It raises several issues with floating point accuracy which may be relevant here. It is possible that the sin(x) function in Hi-Tech is not written optimally. It is also possible that one of the other floating point precision issues is at work here. Sean On Sun, Jan 11, 2009 at 12:29 AM, solarwind <@spam@x.solarwind.xKILLspamgmail.com> wrote: > HI-TECH C is using 24 bit float (I'm having problems with their 32 bit > option) and in their manual it says they have a 15 bit mantissa and > the MSB is implied, therefore I should get at least 5 digits of > precision. When I compute sin 60 degrees, the answer should be > 0.866025404 but I'm only getting 0.8660xxx... where the x are > incorrect digits. Odd... > > > -- > solarwind > -

Take a look at: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=61605&start=0 especially the sites it links to: http://www.diycalculator.com/ http://www2.hursley.ibm.com/decimal/ On Sun, Jan 11, 2009 at 12:29 AM, solarwind <KILLspamx.solarwind.xKILLspamgmail.com> wrote: > HI-TECH C is using 24 bit float (I'm having problems with their 32 bit > option) and in their manual it says they have a 15 bit mantissa and > the MSB is implied, therefore I should get at least 5 digits of > precision. When I compute sin 60 degrees, the answer should be > 0.866025404 but I'm only getting 0.8660xxx... where the x are > incorrect digits. Odd... > > > -- > solarwind > -

On Sun, 11 Jan 2009, solarwind wrote: {Quote hidden}> Update: my mistake, the calculation is wrong. With 54 bits, the > maximum value I can have is 18014398509481983 which is 17 digits. > > Update: quote from wikipedia: > > * Single precision, called "float" in the C language family, and > "real" or "real*4" in Fortran. This is a binary format that occupies > 32 bits (4 bytes) and its significand has a precision of 24 bits > (about 7 decimal digits). > > * Double precision, called "double" in the C language family, and > "double precision" or "real*8" in Fortran. This is a binary format > that occupies 64 bits (8 bytes) and its significand has a precision of > 53 bits (about 16 decimal digits). > > They say around 16 digits for 64 bit float, but it was 17 in my > calculation. They're saying 7 digits for 32 bit float but I got 8 in > my calculation. when you look at the number 18014398509481983 you see 17 digits but this is the largest number that 54 bits can hold. You could not store 18014398509481984 in this 54 bit field, likewise you could not store 28014398509481983. So when counting digits, loot at all the positions where you can store ALL possible decimal digits i.e. 0..9 In other words, 54 bits can hold 0000000000000000 to 9999999999999999 and not 0xxxxxxxxxxxxxxxx to 9xxxxxxxxxxxxxxxx Regards Sergio

solarwind wrote: > HI-TECH C is using 24 bit float (I'm having problems with their 32 bit > option) and in their manual it says they have a 15 bit mantissa and > the MSB is implied, therefore I should get at least 5 digits of > precision. When I compute sin 60 degrees, the answer should be > 0.866025404 but I'm only getting 0.8660xxx... where the x are > incorrect digits. Odd... > Probaly "just enough" for the applications that the actual tools (PIC and the compiler) was ment for in the first place. That is, *not* a "calculator". I'd think that most calculators uses some fixed point BCD or decimal arithmetic to get a constant and predictable precision and known (or none?) rounding errors. Jan-Erik.

You wrote: > I'd think that most calculators uses some fixed point BCD or decimal > arithmetic to get a constant and predictable precision and known (or > none?) rounding errors. You always have rounding errors when expressing irrational and infinite rational numbers in a format with limited precision and finite rational numbers in a format with less precision than the number requires. How these rounding errors (which after the conversion into the used format usually are below the last significant digit) propagate depends on the algorithms used. With some calculations, these initially invisible errors can be quite quickly propagate up in significance. Think just of difference... a single difference in an algorithm can pull your rounding error from past the 17th decimal (if you're calculating with 17 decimals) into the 10th easily. Or further up. Gerhard

Gerhard Fiedler wrote: > You wrote: > >> I'd think that most calculators uses some fixed point BCD or decimal >> arithmetic to get a constant and predictable precision and known (or >> none?) rounding errors. > > You always have rounding errors when expressing irrational and infinite > rational numbers in a format with limited precision and finite rational > numbers in a format with less precision than the number requires. > > How these rounding errors (which after the conversion into the used > format usually are below the last significant digit) propagate depends > on the algorithms used. With some calculations, these initially > invisible errors can be quite quickly propagate up in significance. > Think just of difference... a single difference in an algorithm can pull > your rounding error from past the 17th decimal (if you're calculating > with 17 decimals) into the 10th easily. Or further up. > > Gerhard Anyway, these issues are usualy more thought over in the software for a "calculator" than it usualy is in the standard floating point library functions in compilers for microcontrollers. Which was my point.

solarwind wrote: > Does anyone have any idea how I can have a 64 bit floating point type > in HI-TECH C or Microchip C18? Consult the manual. All supported data types are listed. It's either supported or not, probably not. Microcontrollers generaly deal with real world measurements where even 32 bit floating point is overkill. I wouldn't be surprised if it's not implemented because they didn't want to waste time on something nobody would care about. Since you're making a calculator, you probably need your own wider representation anways. Calculators often work in a decimal representation. That minimizes rounding that looks strange in decimal, and avoids conversion for display. Decimal takes more cycles to manipulate, but just about anything will look instantaneous in human time. You probably want something like 10 to 12 digit numbers. Since you only need to store a few of them, you can use a whole byte for each 0-9 digit and one more byte for the exponent. Writing basic arithmetic routines for this number format will be a good learning experience. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

solarwind wrote: > When I started this calculator project, I was totally not expecting to > be writing floating point libraries from scratch - in assembler. I don't see why not. In fact, I think this was pointed out to you. > This would also force me to program my entire application > in assembler as well. Huh? Where did you get that from? You can write assembler routines that are C callable. Also, you could write your arithmetic library in C. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

solarwind wrote: > When I compute sin 60 degrees, the answer should be > 0.866025404 but I'm only getting 0.8660xxx... where the x are > incorrect digits. Odd... Not odd, roundoff error. It takes a bunch of calculations to do SIN, and the errors can accumulate. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

> Since you're making a calculator, you probably need your own wider > representation anways. Calculators often work in a decimal > representation. > That minimizes rounding that looks strange in decimal, and avoids > conversion > for display. Decimal takes more cycles to manipulate, but just about > anything will look instantaneous in human time. Amen to this. I strongly recommend a decimal format for a calculator. The experts seem to agree. For example the both TI-83/84 and TI-89 families use a decimal representation internally. > You probably want something like 10 to 12 digit numbers. Since you only > need to store a few of them, you can use a whole byte for each 0-9 digit > and > one more byte for the exponent. I would disagree here. You will need many coefficients for computing series for things like SIN(x) and a two-digit-per-byte representation would make sense. However, I would convert to one-digit-per-byte for the actual computations. >Writing basic arithmetic routines for this > number format will be a good learning experience. Again: amen -- Bob Ammerman RAm Systems

> sergio masci wrote: >> when you look at the number 18014398509481983 you see 17 digits but >> this is the largest number that 54 bits can hold. > > Log10(2**54) = 16.26, so "16 digits" is the correct answer. > Exactly. Where I think solarwind went wrong here is thinking that because *some* 17 digit numbers are representable he has 17 digits of precision. This is of course wrong. He had the same problem thinking that 15 bits should give him 5 digits precision, but, of course 15 bits is limited to a maximum value of 65536, which is only 4+ digits long. -- Bob Ammerman RAm Systems

Bob Ammerman wrote: > Olin (I think) wrote: > > Since you're making a calculator, you probably need your own wider > > representation anways. Calculators often work in a decimal > > representation. That minimizes rounding that looks strange in decimal, > > and avoids conversion for display. Decimal takes more cycles to > > manipulate, but just about anything will look instantaneous in human > > time. > > Amen to this. I strongly recommend a decimal format for a calculator. > The experts seem to agree. For example the both TI-83/84 and TI-89 > families use a decimal representation internally. Indeed, many of the earlier 8-bit microprocessor architectures had explicit support for "packed BCD" (two decimal digits per byte) arithmetic, either through a separate set of decimal add/subtract instructions, a decimal arithmetic "mode" for the ALU, or by the use of an extra "half-carry" status flag and an "adjustment" instruction that got used after any of the normal binary arithmetic instructions. There was even at least one architecture (I forget which one) that supported doing arithmetic directly on ASCII digit characters, but frankly, I never saw the point of that, and obviously, it never caught on elsewhere. It had both "DAA" (decimal adjust for arithmetic) and "AAA" (ASCII adjust for arithmetic) instructions. Anyway, I echo the recommendation to implement a packed-decimal arithmetic library for the calculator, and the 8-bit PICs do at least include a "digit carry" (DC) status bit to aid with that, although you need to write explicit code to take advantage of it (an exercise left for the reader). -- Dave Tweed

I think that the Intel 8086 and 8088 (as well as their progeny) have all of these instructions (BCD ones and DAA/AAA). I learned assembly language first on the 8088 and I distinctly remember wondering what the heck those instructions were for! Sean On Sun, Jan 11, 2009 at 2:52 PM, Dave Tweed <RemoveMEpicTakeThisOuTdtweed.com> wrote: {Quote hidden}> Indeed, many of the earlier 8-bit microprocessor architectures had explicit > support for "packed BCD" (two decimal digits per byte) arithmetic, either > through a separate set of decimal add/subtract instructions, a decimal > arithmetic "mode" for the ALU, or by the use of an extra "half-carry" > status flag and an "adjustment" instruction that got used after any of the > normal binary arithmetic instructions. > > There was even at least one architecture (I forget which one) that > supported doing arithmetic directly on ASCII digit characters, but frankly, > I never saw the point of that, and obviously, it never caught on elsewhere. > It had both "DAA" (decimal adjust for arithmetic) and "AAA" (ASCII adjust > for arithmetic) instructions. > > Anyway, I echo the recommendation to implement a packed-decimal arithmetic > library for the calculator, and the 8-bit PICs do at least include a > "digit carry" (DC) status bit to aid with that, although you need to write > explicit code to take advantage of it (an exercise left for the reader). > > -- Dave Tweed > -

On Sun, Jan 11, 2009 at 2:08 AM, Sean Breheny <spamBeGoneshb7spamBeGonecornell.edu> wrote: > I'd suggest that you read the entire wikipedia article on floating > point which you linked to earlier. It raises several issues with > floating point accuracy which may be relevant here. > > It is possible that the sin(x) function in Hi-Tech is not written > optimally. It is also possible that one of the other floating point > precision issues is at work here. > > Sean Probably not written optimally. Time to compare taylor series with cordic. If I run a 32 bit PIC at 80 MHz for one computation, shouldn't take long at all. -- solarwind

On Jan 11, 2009, at 3:58 PM, solarwind wrote: >> It is possible that the sin(x) function in Hi-Tech is not written >> optimally. It is also possible that one of the other floating point >> precision issues is at work here. This sort of issue is why the IEEE floating point standards specify that intermediate calculations should be performed with greater precision (typically 80 bits) than the size of the data type involved. It's not surprising that a 24bit FP number would end up with some significant error in a SIN calculation if all the intermediate calculations are also done with 24bit FP. You might want to find a book on "numerical methods"; a good one should cover some of the details on how errors accumulate, how to predict the maximum error, and so on. (It's been a long time. I don't recall that there was much discussion on how to minimize such errors, or if that's even possible...) BillW

>Indeed, many of the earlier 8-bit microprocessor architectures >had explicit support for "packed BCD" (two decimal digits per >byte) arithmetic, either through a separate set of decimal >add/subtract instructions, a decimal arithmetic "mode" for >the ALU, or by the use of an extra "half-carry" status flag >and an "adjustment" instruction that got used after any of >the normal binary arithmetic instructions. The 14 bit control word 16F range has a half carry flag, I don't know if it has been carried through into the PIC30 family and derivatives (I believe the 18F range has it, but haven't checked). >There was even at least one architecture (I forget which one) >that supported doing arithmetic directly on ASCII digit characters, >but frankly, I never saw the point of that, and obviously, it >never caught on elsewhere. It had both "DAA" (decimal adjust >for arithmetic) and "AAA" (ASCII adjust for arithmetic) instructions. I worked on a small business machine from a company called Qantel, that worked on ASCII digits. Because it was designed for business use it made sense to do it that way. The CPU architecture was built around bit slice chips, the early ones used 74 series ALU, the later ones used 2901 bit slice units. But the chip that Dave remembers I am fairly sure was the original 8086 family. I do remember seeing the instructions listed.

>> There was even at least one architecture (I forget which one) >> that supported doing arithmetic directly on ASCII digit characters, >> but frankly, I never saw the point of that, IIRC, COBOL supported data types along those lines, and the odder instructions ended up in architectures so that the architectures could better support COBOL. COBOL, of course, wanted exact BCD-like data types so that dollars and cents wouldn't accidentally get lost due to floating point roundoff errors. Or something like that. BillW

solarwind wrote: > Probably not written optimally. Time to compare taylor series with > cordic. If I run a 32 bit PIC at 80 MHz for one computation, shouldn't > take long at all. You can probably run a 8 bit PIC at 20MHz and still not have it take long at all in human terms. You've probably got around 300mS before anyone even begins to get annoyed that SIN or COS or any other complicated trancendental function returns a answer. Even for simple things like add, subtract, multiply, divide, etc, you've probably got 100mS. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

> On Sun, Jan 11, 2009 at 1:02 PM, Bob Ammerman <rammermanEraseME.....verizon.net> > wrote: >> Amen to this. I strongly recommend a decimal format for a calculator. The >> experts seem to agree. For example the both TI-83/84 and TI-89 families >> use >> a decimal representation internally. > > Got any links to what exactly this decimal representation is and how it > works? > > > -- > solarwind See: http://dragonfire.unitedti.org/asmin28/lesson/day18.html

solarwind wrote: > Got any links to what exactly this decimal representation is and how > it works? You can find links yourself, but basically you manipulate strings of numbers in the 0-9 range. Each of these numbers represents one decimal digit. For ease of manipulation, I'd probably use whole bytes for each digit as the common format of the math routines. As Bob suggested, you can store constants more compactly and expand them on the fly into these byte per digit numbers when you need them. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Jan-Erik Soderholm escreveu: {Quote hidden}> solarwind wrote: > >> HI-TECH C is using 24 bit float (I'm having problems with their 32 bit >> option) and in their manual it says they have a 15 bit mantissa and >> the MSB is implied, therefore I should get at least 5 digits of >> precision. When I compute sin 60 degrees, the answer should be >> 0.866025404 but I'm only getting 0.8660xxx... where the x are >> incorrect digits. Odd... >> >> > > Probaly "just enough" for the applications that > the actual tools (PIC and the compiler) was ment > for in the first place. That is, *not* a "calculator". > > I'd think that most calculators uses some fixed > point BCD or decimal arithmetic to get a constant > and predictable precision and known (or none?) > rounding errors. > > Jan-Erik. > The old 8-bit personal computers used packed BCD floating point math. It is a good option for a calculator because it will preserve the precision of the user input. For instance, a binary floating point type cannot represent 0.1 (one tenth) exactly. Try this: long i; float f; for( i = 1000000, f = 0.0; i; i-- ) f += 0.1; printf( "1000000 x 0.1 = %f", f ); With packed BCD floats you will get exactly two decimal digits per byte in the mantissa. Best regards, Isaac __________________________________________________ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/

On Mon, Jan 12, 2009 at 12:51 PM, alan smith <EraseMEmicro_eng2yahoo.com> wrote: > I havent been following this thread, basically due to who started it. But I wonder...has anyone asked....what is the OP trying to do? Sometimes the application calls for a different processor. He's building a calculator. The processor selection took place in many, many threads a month or three ago - I imagine if you did a search over the archive you can check out the discussions that resulted. -Adam -- Please rate and vote for my contest entry: mypic32.com/web/guest/profiles?profileID=50331

As many others here are indicating, and as you discovered when you did your SIN output test, math libraries leave much to be desired. Even though it looks good to say that with 64 bits you get such and such precision, you need to ask yourself whether the operations you will be perfroming actually handle that precision (SIN might downgrade your 64 bit into a 32 bit or worse). Even if you don't go this route, you really need to look into and understand Arbitrary Precision math: http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic If you want to implement this, here's a free C library that may give you some ideas: http://www.tc.umn.edu/~ringx004/mapm-main.html You probably don't need to worry about precision right now, though. Build the calculator so it can use any set of functions or libraries and switch it out later. I can almost gaurantee that you'll be wishing you had made it more modular as you get near the end. -Adam On Sat, Jan 10, 2009 at 5:35 PM, solarwind <RemoveMEx.solarwind.xEraseMEEraseMEgmail.com> wrote: > Does anyone have any idea how I can have a 64 bit floating point type > in HI-TECH C or Microchip C18? > > -- > solarwind > -

On Sun, 11 Jan 2009, solarwind wrote: > On Sun, Jan 11, 2009 at 1:02 PM, Bob Ammerman <RemoveMErammermanspam_OUTKILLspamverizon.net> wrote: > > Amen to this. I strongly recommend a decimal format for a calculator. The > > experts seem to agree. For example the both TI-83/84 and TI-89 families use > > a decimal representation internally. > > Got any links to what exactly this decimal representation is and how it works? Slow down there solarwind, you're just exchanging one set of problems for another. It is clear from your posts that all this computer maths stuff is a little beyond you at this time. I'm not saying that you're stupid just that you don't have the knowedge yet AND this isn't something you can pick up in five minutes. As others have already said, try to find and use existing libraries. You have said that you don't want to do a lot of work converting these but if this is true I can see that there is a stack of other work which you will not want to do if you choose NOT to use someone elses libraries. Go with simple IEEE 745 single precision (32 bit) for now. Get your calculator going with limited precision and show it off. Feel good about what you've accomplished and then decide if you really want to spend your time making your calculator more accurate or if you'd prefer to start another more interesting project. Regards Sergio Masci

On Mon, Jan 12, 2009 at 5:26 PM, sergio masci <RemoveMEsmplxTakeThisOuTspamallotrope.net> wrote: > Slow down there solarwind, you're just exchanging one set of problems for > another. > > It is clear from your posts that all this computer maths stuff is a little > beyond you at this time. I'm not saying that you're stupid just that > you don't have the knowedge yet AND this isn't something you can pick up > in five minutes. Who ever said I want to do it in five minutes? I don't care how long this project takes, but I'll do it. I'll learn whatever I need to as I go along. So far, I went from knowing next to nothing about pic microcontrollers and microcontroller asm to almost thoroughly understanding the assembler part, the instructions and I even managed to get UART, SPI, I2C, parallel and driving my LCD exactly the way I want it. In both C AND ASM. Now I just learned about floating point arithmetic and will be working with MAPM for a while. > As others have already said, try to find and use existing libraries. You > have said that you don't want to do a lot of work converting these but if > this is true I can see that there is a stack of other work which you will > not want to do if you choose NOT to use someone elses libraries. I totally understand what you're saying, but precision is important. I'll be porting over MAPM. > Go with simple IEEE 745 single precision (32 bit) for now. Get your > calculator going with limited precision and show it off. Feel good about > what you've accomplished and then decide if you really want to spend your > time making your calculator more accurate or if you'd prefer to start > another more interesting project. I wont be using anything less than a 64 bit floating point or MAPM. All that's left to do with the calculator is keypad scanning and these math operations. Everything else is working fine. I can even interact with the calculator via UART. I made the thing on a prototyping board and put UART headers and hooked up LCD. I can use it like a normal RPN calculator (with 24 bit float) from my PC keyboard. > Regards > Sergio Masci -- solarwind

>As many others here are indicating, and as you discovered >when you did your SIN output test, math libraries leave >much to be desired. > >Even though it looks good to say that with 64 bits you get >such and such precision, you need to ask yourself whether >the operations you will be perfroming actually handle that >precision (SIN might downgrade your 64 bit into a 32 bit >or worse). See the hpmuseum link below for accuracy of early computers. A very good example of this is the HP35 calculator, which originally had ROM chips that were too small for them to fit in a full length transcendental function set, so several least significant digits had errors in them when doing functions such as SIN(). Later when larger ROMs became available HP gave a free upgrade. See bottom of page http://members.chello.cz/eckstein/HP-35RD.html for some details. See also http://www.hpmuseum.org/hp35.htm for more information. Good grief, it came out in 1972. I still remember all the hype, with it being the first hand held scientific calculator. Still have a copy of the HP journal somewhere with the write up on it. This http://en.wikipedia.org/wiki/HP-35 link has a reference to an online copy, down the bottom. Also the last link on the Wikipedia page has some further info on Cordic algorithms and the ROM bug.

It's funny you mention that. A previous coworker loves his HP15c, but at one point needed to do calculations beyond what it was capable of doing in terms of significant digits. He wrote an emulator for it, and used MAPM to give himself 180 significant digits, among other changes: http://www.precisionstrobe.com/jc/hp15ce/hp15ce.html -Adam On Tue, Jan 13, 2009 at 4:12 AM, Alan B. Pearce <EraseMEAlan.B.PearcespamspamBeGonestfc.ac.uk> wrote: {Quote hidden}>>As many others here are indicating, and as you discovered >>when you did your SIN output test, math libraries leave >>much to be desired. >> >>Even though it looks good to say that with 64 bits you get >>such and such precision, you need to ask yourself whether >>the operations you will be perfroming actually handle that >>precision (SIN might downgrade your 64 bit into a 32 bit >>or worse). > > See the hpmuseum link below for accuracy of early computers. > > A very good example of this is the HP35 calculator, which originally had ROM > chips that were too small for them to fit in a full length transcendental > function set, so several least significant digits had errors in them when > doing functions such as SIN(). Later when larger ROMs became available HP > gave a free upgrade. > > See bottom of page http://members.chello.cz/eckstein/HP-35RD.html for some > details. See also http://www.hpmuseum.org/hp35.htm for more information. > > Good grief, it came out in 1972. I still remember all the hype, with it > being the first hand held scientific calculator. Still have a copy of the HP > journal somewhere with the write up on it. This > http://en.wikipedia.org/wiki/HP-35 link has a reference to an online copy, > down the bottom. > > Also the last link on the Wikipedia page has some further info on Cordic > algorithms and the ROM bug. > > -

On Mon, 12 Jan 2009, solarwind wrote: {Quote hidden}> On Mon, Jan 12, 2009 at 5:26 PM, sergio masci <RemoveMEsmplxKILLspamallotrope.net> wrote: > > Slow down there solarwind, you're just exchanging one set of problems for > > another. > > > > It is clear from your posts that all this computer maths stuff is a little > > beyond you at this time. I'm not saying that you're stupid just that > > you don't have the knowedge yet AND this isn't something you can pick up > > in five minutes. > > Who ever said I want to do it in five minutes? I don't care how long > this project takes, but I'll do it. I'll learn whatever I need to as I > go along. Ok then. Has anyone refered you to this yet? http://docs.sun.com/source/806-3568/ncg_goldberg.html It's pretty good and I would recommend you read it if you haven't aready. Regards Sergio Masci

On Mon, 2009-01-12 at 07:23 -0500, Olin Lathrop wrote: > solarwind wrote: > > Probably not written optimally. Time to compare taylor series with > > cordic. If I run a 32 bit PIC at 80 MHz for one computation, shouldn't > > take long at all. > > You can probably run a 8 bit PIC at 20MHz and still not have it take long at > all in human terms. You've probably got around 300mS before anyone even > begins to get annoyed that SIN or COS or any other complicated trancendental > function returns a answer. Even for simple things like add, subtract, > multiply, divide, etc, you've probably got 100mS. FWIW, even some modern calculators can take a while. A friend of mine had a calculator that took nearly a second when involving certain functions (sin/cos/tan come to mind, ln/log I believe as well). TTYL

Herbert Graf wrote: > FWIW, even some modern calculators can take a while. A friend of mine > had a calculator that took nearly a second when involving certain > functions (sin/cos/tan come to mind, ln/log I believe as well). The compute time in some of the calculator 30 years ago is legendary. Sinclair made a calculator that used a bit serial processor. One of the trig functions took 8 minutes and generally got the wrong answer. w..

On Mon, Jan 12, 2009 at 3:27 PM, solarwind <spamBeGonex.solarwind.xSTOPspamEraseMEgmail.com> wrote: > On Mon, Jan 12, 2009 at 5:26 PM, sergio masci <KILLspamsmplxspamBeGoneallotrope.net> wrote: > >> Go with simple IEEE 745 single precision (32 bit) for now. Get your >> calculator going with limited precision and show it off. Feel good about >> what you've accomplished and then decide if you really want to spend your >> time making your calculator more accurate or if you'd prefer to start >> another more interesting project. > > I wont be using anything less than a 64 bit floating point or MAPM. > All that's left to do with the calculator is keypad scanning and these > math operations. Everything else is working fine. I can even interact > with the calculator via UART. I made the thing on a prototyping board > and put UART headers and hooked up LCD. I can use it like a normal RPN > calculator (with 24 bit float) from my PC keyboard. > Hey, IEEE float was good enough for Microsoft: http://blogs.msdn.com/oldnewthing/archive/2004/05/25/141253.aspx -- Mark Rages, Engineer Midwest Telecine LLC EraseMEmarkragesEraseMEmidwesttelecine.com

On Tue, 13 Jan 2009, Mark Rages wrote: {Quote hidden}> On Mon, Jan 12, 2009 at 3:27 PM, solarwind <@spam@x.solarwind.x@spam@spam_OUTgmail.com> wrote: > > On Mon, Jan 12, 2009 at 5:26 PM, sergio masci <spamBeGonesmplxKILLspamallotrope.net> wrote: > > > >> Go with simple IEEE 745 single precision (32 bit) for now. Get your > >> calculator going with limited precision and show it off. Feel good about > >> what you've accomplished and then decide if you really want to spend your > >> time making your calculator more accurate or if you'd prefer to start > >> another more interesting project. > > > > I wont be using anything less than a 64 bit floating point or MAPM. > > All that's left to do with the calculator is keypad scanning and these > > math operations. Everything else is working fine. I can even interact > > with the calculator via UART. I made the thing on a prototyping board > > and put UART headers and hooked up LCD. I can use it like a normal RPN > > calculator (with 24 bit float) from my PC keyboard. > > > > Hey, IEEE float was good enough for Microsoft: > > http://blogs.msdn.com/oldnewthing/archive/2004/05/25/141253.aspx oops: should read IEEE 754 (I do know what floating point is - honest) Regards Sergio Masci

> Probaly "just enough" for the applications that > the actual tools (PIC and the compiler) was ment > for in the first place. That is, *not* a "calculator". > > I'd think that most calculators uses some fixed > point BCD or decimal arithmetic to get a constant > and predictable precision and known (or none?) > rounding errors. > > Jan-Erik. JE, I get this message added right after every single message you posted for the last few days. It seems stuck in your outbox? -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

On Wed, Jan 14, 2009 at 8:24 AM, Jan-Erik Soderholm <.....jan-erik.soderholmspam_OUTtelia.com> wrote: >> JE, I get this message added right after every single message you posted >> for the last few days. It seems stuck in your outbox? >> > > Nop, it's probably stuck in your inbox... :-) I think you are right. It must be stuck in Wouter's inbox. > Serously, has anyone else seen this ? I do not see them, > and I always get a copy of anything I send to the list. I do not see them either so I think you are right. > I would thought that I'd had quite a few "complaints" > by now if that would have been the case. > Xiaofan

Jan-Erik Soderholm wrote: > Serously, has anyone else seen this ? I do not see them, > and I always get a copy of anything I send to the list. > > I would thought that I'd had quite a few "complaints" > by now if that would have been the case. I just looked at the complete text of your email message, headers and all, and there is no other hidden message anywhere. It's not multi-part MIME. The problem is apparently at Wouter's end or possibly with the server, but it's hard to imagine a email bug that would cause the symptom he described. I'd really like to hear what it was if it's ever figured out. A long time ago I had a bug in some email software that was converted from single threaded to multi-threaded, but not quite correctly. Every once in a while one message would get snippets of another message interleaved with it. Oops. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Wouter van Ooijen wrote: >> Probaly "just enough" for the applications that >> the actual tools (PIC and the compiler) was ment >> for in the first place. That is, *not* a "calculator". >> >> I'd think that most calculators uses some fixed >> point BCD or decimal arithmetic to get a constant >> and predictable precision and known (or none?) >> rounding errors. >> >> Jan-Erik. >> > > JE, I get this message added right after every single message you posted > for the last few days. It seems stuck in your outbox? > > I received this message some days ago but the date was wrong: a message from the next week! Here part of the header: > Received: from [192.168.1.33] (81.232.163.33) by > pne-smtpout1-sn1.fre.skanova.net (7.3.129) (authenticated as > u12103129) > id 47A97950057FC2D2 for TakeThisOuTpiclist.....TakeThisOuTmit.edu; *Sun, 11 Jan 2009 12:57:09* +0100 > Message-ID: <TakeThisOuT49707613.6020604KILLspamspamtelia.com> > *Date: Fri, 16 Jan 2009 12:57:07* +0100 > From: Jan-Erik Soderholm <.....jan-erik.soderholmRemoveMEtelia.com> > User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) I noted that some times, maybe the clock of SO was wrong.

On Tue, 2009-01-13 at 18:05 -0500, Walter Banks wrote: > > Herbert Graf wrote: > > > FWIW, even some modern calculators can take a while. A friend of mine > > had a calculator that took nearly a second when involving certain > > functions (sin/cos/tan come to mind, ln/log I believe as well). > > The compute time in some of the calculator 30 years ago is legendary. > Sinclair made a calculator that used a bit serial processor. One of the > trig functions took 8 minutes and generally got the wrong answer. Hehe, well that's not very useful! Even today though, some calculators do certain operations very slowly, while others are lightning fast. It can get quite annoying when trying to solve long equations. IIRC my friend's "slow" calculator was a Casio, my "instant" calculator was a Sharp. TTYL

Herbert Graf wrote: {Quote hidden}> On Tue, 2009-01-13 at 18:05 -0500, Walter Banks wrote: > >> Herbert Graf wrote: >> >> >>> FWIW, even some modern calculators can take a while. A friend of mine >>> had a calculator that took nearly a second when involving certain >>> functions (sin/cos/tan come to mind, ln/log I believe as well). >>> >> The compute time in some of the calculator 30 years ago is legendary. >> Sinclair made a calculator that used a bit serial processor. One of the >> trig functions took 8 minutes and generally got the wrong answer. >> > > Hehe, well that's not very useful! Even today though, some calculators > do certain operations very slowly, while others are lightning fast. It > can get quite annoying when trying to solve long equations. > > IIRC my friend's "slow" calculator was a Casio, my "instant" calculator > was a Sharp. > > TTYL > > at school we used to have "calculator races" we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1))))))))) and it would take it several seconds to come up with the answer, the 2 line calculators were actually slower. There was even some difference between identical calculators.

Marcel Birthelmer wrote: >> at school we used to have "calculator races" >> we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1))))))))) >> and it would take it several seconds to come up with the answer, the 2 >> line calculators were actually slower. >> There was even some difference between identical calculators. >> >> > > Difference in speed, or difference in answers? Were the answers always the > same? > yeah answers were the same, it was probably a 10% variance in clock speed, I always wanted to overclock mine ;->

:: e used to have "calculator races" :: we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1))))))))) :: and it would take it several seconds to come up with the answer, :: the 2 Well just for fon I trie that on my Casio fx-5000f - it has regurgitated the answer of 0.42298298 Colin -- cdb, spamBeGonecolin@spam@spam_OUTbtech-online.co.uk on 15/01/2009 Web presence: http://www.btech-online.co.uk Hosted by: http://www.1and1.co.uk/?k_id=7988359

On Wed, Jan 14, 2009 at 11:39 PM, cdb <TakeThisOuTcolinspambtech-online.co.uk> wrote: > Well just for fon I trie that on my Casio fx-5000f - it has > regurgitated the answer of 0.42298298 > > Colin Note, http://www.google.com/search?hl=en&q=sin(cos(tan(sin(cos(tan(sin(cos(tan+1+degree)))))))))&btnG=Search is not the same as http://www.google.com/search?hl=en&q=sin(cos(tan(sin(cos(tan(sin(cos(tan+1)))))))))&btnG=Search -- solarwind

cdb wrote: {Quote hidden}> :: e used to have "calculator races" > :: we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1))))))))) > :: and it would take it several seconds to come up with the answer, > :: the 2 > > Well just for fon I trie that on my Casio fx-5000f - it has > regurgitated the answer of 0.42298298 > > Colin > -- > cdb, colinEraseMEbtech-online.co.uk on 15/01/2009 > > Web presence: http://www.btech-online.co.uk > > Hosted by: http://www.1and1.co.uk/?k_id=7988359 > > > > > > > > yeah but how fast?

On Wed, Jan 14, 2009 at 11:39 PM, cdb <@spam@colinRemoveMEEraseMEbtech-online.co.uk> wrote: > :: e used to have "calculator races" > :: we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1))))))))) > :: and it would take it several seconds to come up with the answer, > :: the 2 > > Well just for fon I trie that on my Casio fx-5000f - it has > regurgitated the answer of 0.42298298 My calculator just gave me an answer of 0.42298298052002545978980951342094 (calculator in Windows XP). Which made me think: Since the original question was about implementing a calculator on a fairly hefty chip, why not look at the source for the Linux equivalent to "calculator" and use those algorithms? They have already been vetted, and should give him all the accuracy he wants? And FYI: my scientific calculator from the local dollar store gave me an answer of 0.42298298 as fast as I could press the buttons. -- Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org

This looked familiar. Two of the tests from our fixed point sanity tests are similar The angles in this case are in degrees // This should return a 7.0 simple accuracy check r = asin(acos(atan(tan(cos(sin(7.0)))))); // Check loss or precision with small numbers should be 1.0 r = asin(acos(atan(tan(cos(sin(1.0)))))); > sin(cos(tan(sin(cos(tan(sin(cos(tan1))))))))) Largly tests the implementation of tan whose errors are generally larger than those created by sin or cos. Depending on input the result may be very large. Regards, -- Walter Banks Byte Craft Limited http://bytecraft.com cdb wrote: {Quote hidden}> :: e used to have "calculator races" > :: we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1))))))))) > :: and it would take it several seconds to come up with the answer, > :: the 2 > > Well just for fon I trie that on my Casio fx-5000f - it has > regurgitated the answer of 0.42298298 > > Colin > -- > cdb, EraseMEcolin@spam@btech-online.co.uk on 15/01/2009 > > Web presence: http://www.btech-online.co.uk > > Hosted by: http://www.1and1.co.uk/?k_id=7988359 > > > > > > > > -

> at school we used to have "calculator races" > we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1))))))))) > and it would take it several seconds to come up with the answer, the 2 > line calculators were actually slower. > There was even some difference between identical calculators. ( ([sqrt(N)] ^11 ) -1 ) x 889 eg without "aleegraic notation: 2 sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt -1 x 889 = N = 2, 3, 4, ...Then see how close the answer comes to the "right one", andhow long it takes. Starter for 10: points What does this calculate. Special credit: Why / how.? Russell

That's pretty interesting. Looks like log base 10 to me. Don't know how ((x^(1/2048))-1)*889 does it though. Explanation? -Adam On Thu, Jan 15, 2009 at 9:11 PM, apptech <@spam@apptechspam_OUT.....paradise.net.nz> wrote: {Quote hidden}>> at school we used to have "calculator races" >> we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1))))))))) >> and it would take it several seconds to come up with the answer, the 2 >> line calculators were actually slower. >> There was even some difference between identical calculators. > > ( ([sqrt(N)] ^11 ) -1 ) x 889 > > eg without "aleegraic notation: > > 2 sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt -1 x 889 = > > N = 2, 3, 4, ...Then see how close the answer comes to the "right one", > andhow long it takes. > > Starter for 10: points > > What does this calculate. > > Special credit: > > Why / how.? > > > > Russell > > > -

> That's pretty interesting. Looks like log base 10 to me. > > Don't know how ((x^(1/2048))-1)*889 does it though. Explanation? Step on the journey. Take N = any power of 2 and do the SQRTing N times and then divide by 2^N * :-). AFAIR it surprised Scott D when I raised it some years ago BUT he promptly dug into it and explained it. One can probably blithely say something like "power series" and walk away quickly before anyone notices. Or look for Scott's comments. Or have a play with what is does after you try the 2^N version above. Light bulbs start to shine a little. Note that the 889 and 11 sqrts [squirt 11 times?] was empirically derived to give best typical accuracy on a typical calculator for small numbers. You can do more or less sqrts and change the constant to get the correctish anwer again. If you had infinite precision it would help. A job for Solarwind's calculator. Russell * Clue - log base 2 results if you get divisions and sqrt count correct.

There was a discussion about a week ago about what floating point formats were used in hand calculators. I ran into a description of the HP 45 calculator on a website dedicated to HP calculators. http://www.hpmuseum.org/ The following quote is from that site The HP calculator CPUs were optimized for floating point numbers. Each main register consisted of 14 of 4 bits each (56 bits per register) This allowed each register to hold a 10 digit mantissa, a 2 digit exponent and signs for the mantissa and exponent. Each digit or sign occupied 4 bits. This is commonly referred to as Binary Coded Decimal (BCD) encoding. Regards, -- Walter Banks Byte Craft Limited http://bytecraft.com

This also cropped up recently on hackaday: http://www.calcwatch.com/ PIC24 based scientific calculator in watch-sized module. All open source. Available as a kit. 100 Hours of runtime on 2xcr2032 batteries. Runs at 250kHz. Uses Microchips C30, which apparently includes 64bit floats (makes sense; it probably uses a generic Gnu floating point library.) Personally, I hate it when I find someone has already done the pointless project I had in mind (and gone further than I had intended on going.) The whole point of doing something pointless was to be unique. Sigh. BillW

On Wed, Jan 21, 2009 at 10:38 AM, William Chops Westfield <spamBeGonewestfwEraseMEmac.com> wrote: > This also cropped up recently on hackaday: > http://www.calcwatch.com/ > > PIC24 based scientific calculator in watch-sized module. All open > source. Available as a kit. 100 Hours of runtime on 2xcr2032 > batteries. Runs at 250kHz. > > Uses Microchips C30, which apparently includes 64bit floats (makes > sense; it probably uses a generic Gnu floating point library.) > > Personally, I hate it when I find someone has already done the > pointless project I had in mind (and gone further than I had intended > on going.) The whole point of doing something pointless was to be > unique. Sigh. > > BillW > Haha! I know what you mean. And THANK YOU for letting me know that C30 has 64 bit float! Since 16 bit PICs are available in DIP packages, it makes it very easy for use in projects! This experiment is fun for me, I don't care if people think it's pointless. To me it has a point. -- solarwind

> The whole point of doing something pointless was to be unique. Sigh Google's a heartbreaker sometimes innit OTOH, I've had ideas and then found them on the web. Temporary collapse of spirits, but often it turns out that what somebody else has done isn't that good anyway and can be improved significantly It's in my nature to be inquisitive and inventive so I can take a few knockbacks because there's always something else needs working on. Things I know aren't on the web. Doesn't mean they don't exist but anything worth selling or sharing usually ends up in cyberspace