Searching \ for '64 Bit Float QUESTION' in subject line. () Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=bit+float+question
Search entire site for: '64 Bit Float QUESTION'.

Truncated match.
'64 Bit Float QUESTION'
2009\01\11@110247 by  As a learning exercise, I think he is trying to too much all at once. Do the project in small steps, and iterate to what is finally wanted.

There are several more-or-less independent parts to a calculator project

* the user interface
* the calculation steps (e.g. how to add two numbers, multiply,divide,etc) using, for example, 24 bit floating point or whatever is easily available.
* the math package to use (24 bit FP, 64 bit FP, decimal)

I would leave the 3rd step to the end - design the UI and get it working - the display and keyboard stuff. Fake out the calculation steps at this stage - 2 + 2 would ALWAYS be 13 - the ADD routine would just return a constant for testing purpose.

Then work on the calculation routines, using whatever math package is easiest. In ASM, the standard Mchip 32 bit FP routines work fine.

Then, when the calculator is working, then look into the 64 bit FP routines to get higher precision.

Jumping into the 32 bit PICs and the 32 bit compiler is probably a bit of overkill right now, for a learning experience.

Get your hands dirty with simple steps - don't try to solve all the world's problems with your first project.

Larry

Original Message:
>
Dear Harry,

Solarwind explained a while back that this is a learning exercise. I
think it's actually a good learning exercise, but it is going to take
a lot of effort to make it a real workable calculator.

Sean   Hi Larry,

I agree that it should be done in stages. However, I don't really
think that any particular series of PICs (16F, 18F, or the 32 bit
PICs) is any harder to learn than any other. He might as well do all
of the steps on the 32 bit PICs if the compiler is free and is capable
of later on doing the math that he wants to eventually do.

I do think, though, that a calculator would probably be better off
using decimal floating point numbers, as someone else pointed out, as
the rounding and imprecision effects would be more intuitive for the
user than if they were happening in binary and then being converted to
decimal. This has the downside that it would side-skirt learning about
the more standard binary floating point numbers.

Also, it is very important (for a calculator) that the math library
use algorithms which are optimized for accuracy instead of speed or
size. As has been pointed out several times so far, not all sin(x)
algorithms, for example, are equal. Some of them are written so that
steps occur in such a way that the least amount of precision is lost
in the intermediate calculations.

Sean

On Sun, Jan 11, 2009 at 11:02 AM, Larry Bradley <larry.bradley ncf.ca> wrote:
{Quote hidden}

> -  On Sun, Jan 11, 2009 at 11:02 AM, Larry Bradley <larry.bradley ncf.ca> wrote:
> As a learning exercise, I think he is trying to too much all at once. Do the project in small steps, and iterate to what is finally wanted.

> There are several more-or-less independent parts to a calculator project
>
> * the user interface

Complete.

> * the calculation steps (e.g. how to add two numbers, multiply,divide,etc) using, for example, 24 bit floating point or whatever is easily available.

Complete.

> * the math package to use (24 bit FP, 64 bit FP, decimal)

Working on it now.

> I would leave the 3rd step to the end - design the UI and get it working - the display and keyboard stuff. Fake out the calculation steps at this stage - 2 + 2 would ALWAYS be 13 - the ADD routine would just return a constant for testing purpose.

Done. RPN logic is all done, UI works perfectly, LCD is up and
running. Just need to set up keypad. Currently using UART to interact,
but keypad will directly replace UART input.

> Then work on the calculation routines, using whatever math package is easiest. In ASM, the standard Mchip 32 bit FP routines work fine.
>
> Then, when the calculator is working, then look into the 64 bit FP routines to get higher precision.

Alas, PIC32 to the rescue?

> Jumping into the 32 bit PICs and the 32 bit compiler is probably a bit of overkill right now, for a learning experience.

Strongly disagree, PIC32 is probably easier to learn than the other ones.

> Get your hands dirty with simple steps - don't try to solve all the world's problems with your first project.

You wouldn't believe how much dirt is on my hands now xD

--
solarwind  On Sun, Jan 11, 2009 at 11:02 AM, Larry Bradley <larry.bradley ncf.ca> wrote:

> Then, when the calculator is working, then look into the 64 bit FP routines to get higher precision.
>
> Jumping into the 32 bit PICs and the 32 bit compiler is probably a bit of overkill right now, for a learning experience.
>
> Get your hands dirty with simple steps - don't try to solve all the world's problems with your first project.
>
> Larry
>

I think he should use an 8 bit processor. Seeing what a TI or HP
calculator can do with math on a very limited system is amazing. If
you use a 32 bit machine I expect a portable version of MATLAB or
Maple :)

-
ML

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...