Arithmatic

  • Thread starter Thread starter Harry
  • Start date Start date
H

Harry

Hi,

I wonder whether anyone could help me to do a maths calculation?
I have three boxes which take numeric values

double PPrice = Convert.ToDouble(txtPurchasePrice.Text);
double BCost = Convert.ToDouble(txtBuildCost.Text);
double Morg = Convert.ToDouble(txtMortgage.Text);

As each box has lostfocus/validating, the amount to be placed in a textbox
adding to it the

previous amount, so giving a running total.
I have tried to add (PPrice + BCost-Morg); but keep getting errors.
I do, however, get it to work when I use " StreamWriter" and write to a text
file, but it

will not give me a total on the screen.

I would be most appreciative if you would be good enough to show me how this
can be

done.

Harry
 
Perhaps you could post the code that you use to display the total "on the
screen" as well as what the errors are. It would make it much easier to
help you.

DalePres
MCAD, MCDBA, MCSE
 
why are you converting the number to a double?

Double-precision numbers are used for scientific calculations, not for
monetary calculations. You are LIKELY to get errors.

Use Decimal numbers.

Also, to repeat a previous responder: post your code and describe the errors
you are getting.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
 
What errors are you getting? And where? In the conversion, or in the
addition? Is it really an error (as in, an exception) or is it just an
unexpected result without an actual exception being thrown? Please provide
code and indicate exactly where the "error" occurs.

I agree with another respondent -- use decimal rather than double. This
will take care of virtually all rounding errors you might encounter. In
fact I consider floating point formats to be, for the most part, evil.
Decimal is slower and takes up more memory but usually not enough to matter
with modern hardware and real world scenarios.

--Bob
 
Bob Grommes said:
What errors are you getting? And where? In the conversion, or in the
addition? Is it really an error (as in, an exception) or is it just an
unexpected result without an actual exception being thrown? Please provide
code and indicate exactly where the "error" occurs.

I agree with another respondent -- use decimal rather than double.
Agreed.

This will take care of virtually all rounding errors you might encounter.
Click to expand...

I think that may be overstating a bit. As soon as you do any division,
for instance, you're likely to get rounding errors. Whether or not
they're significant is a different matter - applications like this
should have well-defined error tolerances etc.
In fact I consider floating point formats to be, for the most part, evil.
Click to expand...

And yet Decimal itself is a floating point type :)
 
Just for the edification of those who put in time and effort considering
your question, you might want to provide some details of what was wrong and
how you solved it.

DalePres


Harry said:
Thank you one and all I have solved the problem :-)
Click to expand...
 
It was such a minor detail, that I am embarrassed to tell you how simple it
was to correct it.
It was a minor oversight and I very much appreciate the effort that was put
in.

DalePres said:
Just for the edification of those who put in time and effort considering
your question, you might want to provide some details of what was wrong
and how you solved it.

DalePres
Click to expand...
 
I think that may be overstating a bit. As soon as you do any division,
for instance, you're likely to get rounding errors. Whether or not
they're significant is a different matter - applications like this
should have well-defined error tolerances etc.
Click to expand...

I am talking about insiduous and counterintuitive rounding errors. In
real-world business applications I have yet to have division or
multiplication between two decimal numbers produce anything other than what
one would expect.
And yet Decimal itself is a floating point type :)
Click to expand...

Okay, ya got me there, Jon. But is System.Decimal not just at heart an
implementation of good old BCD? It is capable of precisely representing any
number that it can express, whereas an 8-byte float / real cannot always
pull that off (for a given value of "always" ;-)

--Bob
 
Bob Grommes said:
I am talking about insiduous and counterintuitive rounding errors. In
real-world business applications I have yet to have division or
multiplication between two decimal numbers produce anything other than what
one would expect.
Click to expand...

Multiplication should be fine until you start getting towards the edge
of the scale or precision. Division will entirely depend on the app.
Any time you take the average of some numbers, you leave yourself open
to rounding errors. Whether those are *significant* rounding errors or
not is a slightly different matter.

Also don't forget that not all apps are business apps - there are
plenty of scientific apps as well, and they're much more likely to rely
on division.
Okay, ya got me there, Jon. But is System.Decimal not just at heart an
implementation of good old BCD?
Click to expand...

I think it's closer to binary floating point than BCD, to be honest,
but both are fundamentally just an integer along with something that
says where the point goes.
It is capable of precisely representing any
number that it can express, whereas an 8-byte float / real cannot always
pull that off (for a given value of "always" ;-)
Click to expand...

No, binary floating point also precisely represents any number it can
express. It also "roughly" represents numbers near to those numbers -
just as decimal does.

The difference is really just a human bias towards thinking of decimal
representations as more "real" than binary representations. (There are
also differences in the sort of "density of precision" in the way that
the IEEE representations are designed to cope with much larger and
smaller numbers than decimal, by losing a lot of precision at the large
end. That's a slightly different matter though.)
 
Back
Top