Recently in our code, I ran into a situation where were stuffing a
float inside a double. The precision was extended automatically
because of that. To make a long story short, this caused problems
elsewhere in another part of the system where that figure was used for
some calculation and some eventual truncation led to the system going
haywire. So my question is, given this code:
int main()
{
float f = 59.89F;
/* the following line caused problems */
double d = f;
/* they ended up solving it like this */
f *= 1000.0;
double dd = (double)f / 1000.0;
return 0;
}
I see what is being done but why does the latter make the situation
better?
(consider 'f' in real life to hold stock prices)
Dec 19 '06
116  35620 
In article <11**********************@73g2000cwn.googlegroups. com"William Hughes" <wp*******@hotmail.comwrites:
....
A 64 bit integer will correctly model currency to 18 digits (with
hundredths units that gives 16 digits for the integer part).
In a mythical currency with 1,000,000 units per dollar,
Nothing mythical here.
1 US dollar = 1374865.7 Turkish Lira
You are out of date. 1 US dollar = 1.4283 Turkish Lira.
that would
leave 10 billion dollar transactions accurate to the penny.
So don't use 64 bit integers to calculate the world GDP in
Turkish Lira unless your system is tolerant of small errors.
You still fail to see how the financial world is looking at it.
They require exactness to some predefined unit. And if some
system requires precision to the cent, do the calculations to
the cent.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Ernie Wright wrote:
CBFalconer wrote:
>Ben Pfaff wrote:
>>For what it's worth, the round function is new in C99.
and unnecessary.
price_cents = 100 * floating_price + 0.5;
which is only one of several widely used rounding rules, and not
necessarily the one preferred for financial transactions.
which won't matter in the case posted by the OP. He started with a
constant of the form 89.13, i.e. with exactly 2 decimal places.
The above will capture the original value.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Dik T. Winter wrote:
In article <11**********************@73g2000cwn.googlegroups. com"William Hughes" <wp*******@hotmail.comwrites:
...
A 64 bit integer will correctly model currency to 18 digits (with
hundredths units that gives 16 digits for the integer part).
In a mythical currency with 1,000,000 units per dollar,
>
Nothing mythical here.
>
1 US dollar = 1374865.7 Turkish Lira
You are out of date. 1 US dollar = 1.4283 Turkish Lira.
No 1 US dollar = 1.4283 New Turkish Lira.
Yes, the convesion contant came from a table that was
a few years old. That hardly makes the Turkish Lira
mythical.
- William Hughes
William Hughes wrote:
Dik T. Winter wrote:
.... snip ...
>>
To avoid all this is done by internally working with integers,
longs, long longs, or whatever integer size you need.
Just remember you may be dealing with the world GDP expressed in
Turkish lira. Or design your system to use floating point and be
tolerant of small errors In the end you need to find out what
the correct answer is (this is an accounting, not a mathematical
or computer question) and design your system to give the correct
answer. What internal data type or structure you use to do this
is of lesser importance.
Mumble years ago I was rewriting a payroll program (in Cobol) for a
municipality. The original had done all sorts of multiple rounding
operations, giving minor erroneous results, and I corrected this as
a matter of course. The net result was a penny or two difference
in actual paychecks, but summaries were correct and the books
balanced.
You wouldn't believe the screams from the payees. Obviously they
were in the habit of checking things themselves, rounding at every
opportunity. Also they obviously didn't trust "the computer" worth
a damn. To quiet the insurrection I had to put back the faulty
calculations.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
CBFalconer wrote:
Ernie Wright wrote:
>CBFalconer wrote:
>>Ben Pfaff wrote:
For what it's worth, the round function is new in C99.
and unnecessary.
price_cents = 100 * floating_price + 0.5;
which is only one of several widely used rounding rules, and not
necessarily the one preferred for financial transactions.
which won't matter in the case posted by the OP. He started with a
constant of the form 89.13, i.e. with exactly 2 decimal places.
I infer that he started with a 32-bit IEEE float, which can only have
exactly two decimal places if they happen to be ".25", ".50" or ".75".
If he were really starting with a constant in the code, he wouldn't
need a rounding formula. He could just erase the decimal point.
The above will capture the original value.
Which will only help if the OP is planning to rewrite his entire
application to use integers instead of doubles, an option he appears not
to be entertaining.
The problem described by the OP is a truncation happening at a point in
his code that he hasn't shown us. It's very possible that replacing the
truncation with some form of rounding at that point would solve his
problem, but not knowing the exact nature of the problem, we don't know
what kind of rounding he might need.
- Ernie http://home.comcast.net/~erniew
William Hughes wrote:
Dik T. Winter wrote:
>"William Hughes" <wp*******@hotmail.comwrites:
.... snip ...
>>>
Nothing mythical here.
1 US dollar = 1374865.7 Turkish Lira
You are out of date. 1 US dollar = 1.4283 Turkish Lira.
No 1 US dollar = 1.4283 New Turkish Lira.
Yes, the convesion contant came from a table that was a few years
old. That hardly makes the Turkish Lira mythical.
Reminds me of the time I was in Paris shortly after they converted
to the New Franc. I was playing bridge for stakes in a local
bridge club, and carefully checked that the stake was in old
Francs. Otherwise it would have been beyond my means to risk.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Ernie Wright wrote:
CBFalconer wrote:
Ernie Wright wrote:
CBFalconer wrote:
Ben Pfaff wrote:
For what it's worth, the round function is new in C99.
and unnecessary.
price_cents = 100 * floating_price + 0.5;
which is only one of several widely used rounding rules, and not
necessarily the one preferred for financial transactions.
which won't matter in the case posted by the OP. He started with a
constant of the form 89.13, i.e. with exactly 2 decimal places.
I infer that he started with a 32-bit IEEE float, which can only have
exactly two decimal places if they happen to be ".25", ".50" or ".75".
No, the "two decimal places" refers to the desired value,
a value known by the supplier of the stock prices.
What he has is a float that approximates the desired value.
As you note, this will rarely be exact.
>
If he were really starting with a constant in the code, he wouldn't
need a rounding formula. He could just erase the decimal point.
No, he is starting with a float provided by a vendor which
approximates a two decimal place value.
The above will capture the original value.
Which will only help if the OP is planning to rewrite his entire
application to use integers instead of doubles, an option he appears not
to be entertaining.
No. Rounding, then converting to double, does not produce the
same double value as a direct conversion to double. It is conjectured
(partially based on knowing another kludge succeeded) that this
will be more successful with the broken application.
>
The problem described by the OP is a truncation happening at a point in
his code that he hasn't shown us. It's very possible that replacing the
truncation with some form of rounding at that point would solve his
problem, but not knowing the exact nature of the problem, we don't know
what kind of rounding he might need.
Fixing the root of the problem appears to be off the table. Hence
the suggested kludge. The rounding used in the kludge is not
financial rounding.
- William Hughes
On 20 Dec 2006 17:33:35 -0800, in comp.lang.c , dc*****@connx.com
wrote:
>A 64 bit integer will correctly model currency to 18 digits (with
hundredths units that gives 16 digits for the integer part).
Thats only 50Bn Euros, converted into Vietnamese Dong. Peanuts...
>In a mythical currency with 1,000,000 units per dollar, that would
leave 10 billion dollar transactions accurate to the penny.
10Bn dollars is not a large amount. Some LCH Repoclear members will be
settling transactions with LCH.Clearnet for around a trillion GBP each
day.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
On Thu, 21 Dec 2006 02:53:22 GMT, in comp.lang.c , "Dik T. Winter"
<Di********@cwi.nlwrote:
>In article <11**********************@73g2000cwn.googlegroups. com"William Hughes" <wp*******@hotmail.comwrites:
...
A 64 bit integer will correctly model currency to 18 digits (with
hundredths units that gives 16 digits for the integer part).
In a mythical currency with 1,000,000 units per dollar,
Nothing mythical here.
1 US dollar = 1374865.7 Turkish Lira
You are out of date. 1 US dollar = 1.4283 Turkish Lira.
Old vs new Lira, both still in use.
Anyway, vietnamese dong are a better example...
So don't use 64 bit integers to calculate the world GDP in
Turkish Lira unless your system is tolerant of small errors.
You still fail to see how the financial world is looking at it.
They require exactness to some predefined unit. And if some
system requires precision to the cent, do the calculations to
the cent.
What makes it interesting is that the "predefined unit" is variable
by currency, market and calculation.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
In article <1s********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>10Bn dollars is not a large amount. Some LCH Repoclear members will be
settling transactions with LCH.Clearnet for around a trillion GBP each
day.
10 billion dollars *is* a large amount. The existence of larger
amounts is not relevant, assuming that's what your last sentence
implies (it contains too many names I've never heard before to be
sure).
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
On 21 Dec 2006 12:45:04 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:
>In article <1s********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>>10Bn dollars is not a large amount. Some LCH Repoclear members will be
settling transactions with LCH.Clearnet for around a trillion GBP each
day.
10 billion dollars *is* a large amount.
Not as far as financial markets are concerned.
Bear in mind that to someone from say Ethiopia, a hundred bucks is a
large amount.
>The existence of larger amounts is not relevant,
assuming that's what your last sentence
implies
What my last sentence indicated was that banks *routinely* perform
significantly larger transactions, and in that context, 10Bn is small.
>(it contains too many names I've never heard before to be
sure).
If you can be *rsed, look at http://www.lchclearnet.com/
A press release indicates a transaction volume of 408Tn in 2005.
LCH.Clearnet is merely one of many such exchanges. Its fairly easy to
see that a year's global business would overflow 64-bits, and to
retain enough accounts for GAAP rules would be way beyond it...
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Dik T. Winter wrote:
In article <11**********************@n67g2000cwd.googlegroups .com"William Hughes" <wp*******@hotmail.comwrites:
Dik T. Winter wrote:
...
But after subtraction you can be subtly wrong the wrong way.
>
Indeed. This is not a fix. This is a kludge that might work with
a broken system.
What of the system is broken?
To avoid
all this is done by internally working with integers, longs, long longs,
or whatever integer size you need.
>
Just remember you may be dealing with the world GDP expressed
in Turkish lira. Or design your system to use floating point and be
tolerant of small errors.
The current Turkish Lira would do pretty well. The previous one would
be bad, especially if you want to keep up to figures until the nearest
Kuru. But when somebody complains that there is a difference of one
cent in the result, that only means that the calculations are done
using the wrong data type. If you expect that anybody in Turkey before
the introduction of the new Lira bothered about anything less than
25000 Lira, you are wrong. (I still remember the 10,000,000 Lira tip
for the waiter after a small lunch for four.)
No financial program can cope with hyperinflation when it does not
regularly adjust to the inputs. You should know the smallest amount
that legally can be distinguished and base your calculations on that;
using integers. Picking the Turkish Lira is a red herring. You
could equally well have picked the Hungarian Pengo from just after
the war. If I have it right, at some moment they had notes of
1,000,000,000,000,000,000,000,000 Pengo. Or the Zimbabwian dollar
notes that have printed on them an ultimate date of validity (which
is not more than six months after introduction).
The whole point is that in most financial transactions it is precisely
defined how fractions of something should be rounded. Any attempt to
be slightly imprecise (using floating point) will fail at some point
or another.
No. The question is not whether the imprecise answer is the
correct answer (this is highly unlikely), but whether
the correct answer can be determined from the
imprecise answer.
You have to find out what the correct answer is and calculate
that. It is unlikely to be the native answer, whether calculated
using integer or floating point. The fundamental questions are:
i: can you determine the correct answer from
the calculations done using your chosen data type
ii how difficult is it to determine the correct answer.
For i there is no clear advantage to integer calculations (though it
is clear that there are native floating point type and native integer
types that do not satisfy i).
For ii, there may be small advantage to integer calculations, but
given that calculations with non-integer results (e.g. compound
interest) are needed, this advantage is, at best, quite small.
I would advocate making any system flexible and fault tolerant.
In this case it means taking input in many forms and doing
the same thing if the input is
1 cent
1.000001 cents
0.999999 cents
(yes this means that calculations with Turkish Lira are not
exact to the lira) and failing gracefully when the numbers
become large.
On the balance, I would expect a floating point approach
to be preferable, but double, while carrying any needed
practical precision, may not have the precision needed to
obtain the correct accounting answer. [Note the question
is not, "do native calculations give the accounting answer",
they do not. The question is "Can the accounting answer
be determined from the native calculations?"]
- William Hughes
In article <11*********************@42g2000cwt.googlegroups.c om"William Hughes" <wp*******@hotmail.comwrites:
Dik T. Winter wrote:
....
The whole point is that in most financial transactions it is precisely
defined how fractions of something should be rounded. Any attempt to
be slightly imprecise (using floating point) will fail at some point
or another.
No. The question is not whether the imprecise answer is the
correct answer (this is highly unlikely), but whether
the correct answer can be determined from the
imprecise answer.
And the answer is: if the calculations are more than trivial certainly
not.
You have to find out what the correct answer is and calculate
that. It is unlikely to be the native answer, whether calculated
using integer or floating point. The fundamental questions are:
Using integer arithmetic you are sure you get the correct answer
(supposing, of course, that you properly scale everything).
i: can you determine the correct answer from
the calculations done using your chosen data type
ii how difficult is it to determine the correct answer.
For i there is no clear advantage to integer calculations (though it
is clear that there are native floating point type and native integer
types that do not satisfy i).
If a native integer type is not sufficient, use something larger.
For ii, there may be small advantage to integer calculations, but
given that calculations with non-integer results (e.g. compound
interest) are needed, this advantage is, at best, quite small.
Compound interest is best calculated using yearly interest calculation
with proper rounding after each year, otherwise you will almost
certainly *not* get the correct answer.
(yes this means that calculations with Turkish Lira are not
exact to the lira) and failing gracefully when the numbers
become large.
And this means that if the Turkish law requires something to be
calculated to the Lira that your system is not good enough.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter wrote:
In article <11*********************@42g2000cwt.googlegroups.c om"William Hughes" <wp*******@hotmail.comwrites:
Dik T. Winter wrote:
...
The whole point is that in most financial transactions it is precisely
defined how fractions of something should be rounded. Any attempt to
be slightly imprecise (using floating point) will fail at some point
or another.
>
No. The question is not whether the imprecise answer is the
correct answer (this is highly unlikely), but whether
the correct answer can be determined from the
imprecise answer.
And the answer is: if the calculations are more than trivial certainly
not.
??. You cannot do non-trivial calculations to a precision
greater that 1/2 of your smallest currency unit?
You have to find out what the correct answer is and calculate
that. It is unlikely to be the native answer, whether calculated
using integer or floating point. The fundamental questions are:
Using integer arithmetic you are sure you get the correct answer
(supposing, of course, that you properly scale everything).
No, you need a large enough integer type as well (scaling
will not help if you are using char). Also, how do you
do compound intererst calculations "using integer arithmetic"
and how does the fact that you are using integer arithmetic
help you to determine a "correct' answer based on a non-mathematical
standard of correctness.
>
i: can you determine the correct answer from
the calculations done using your chosen data type
ii how difficult is it to determine the correct answer.
>
For i there is no clear advantage to integer calculations (though it
is clear that there are native floating point type and native integer
types that do not satisfy i).
If a native integer type is not sufficient, use something larger.
Indeed. But why can't this "something larger" be a floating
point type with sufficient precision? If there is sufficient
precision you can still determine the correct answer.
>
For ii, there may be small advantage to integer calculations, but
given that calculations with non-integer results (e.g. compound
interest) are needed, this advantage is, at best, quite small.
Compound interest is best calculated using yearly interest calculation
with proper rounding after each year, otherwise you will almost
certainly *not* get the correct answer.
This can be done as conveniently using floating point arithmetic
as using fixed point arithmetic. In either case you have to
do rounding.
>
(yes this means that calculations with Turkish Lira are not
exact to the lira) and failing gracefully when the numbers
become large.
And this means that if the Turkish law requires something to be
calculated to the Lira that your system is not good enough.
If this is a requirement, such a system can be written
as easily using high precision floating point as large
integer. However, note that such a law would
regularly require inputs to be specified with an error
of less than 10^-9. It is unlikely to be honoured or
enforced.
- William Hughes
2006-12-21 <JA********@cwi.nl>,
Dik T. Winter wrote:
In article <11*********************@42g2000cwt.googlegroups.c om"William Hughes" <wp*******@hotmail.comwrites:
Dik T. Winter wrote:
...
The whole point is that in most financial transactions it is precisely
defined how fractions of something should be rounded. Any attempt to
be slightly imprecise (using floating point) will fail at some point
or another.
>
No. The question is not whether the imprecise answer is the
correct answer (this is highly unlikely), but whether
the correct answer can be determined from the
imprecise answer.
And the answer is: if the calculations are more than trivial certainly
not.
Converting a floating point input to an integer _once_ IS trivial.
William Hughes wrote:
Ernie Wright wrote:
>The problem described by the OP is a truncation happening at a point
in his code that he hasn't shown us.
Fixing the root of the problem appears to be off the table.
We are therefore wasting time by solving some other problem we invented.
- Ernie http://home.comcast.net/~erniew
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
Dilip wrote:
Dik T. Winter wrote:
"Dilip" <rd*****@lycos.comwrites:
(consider 'f' in real life to hold stock prices)
Consider not to use floating point for stock prices. Floating
point inherently carries imprecision (especially if you want to
do decimal calculations), which you do not want with stock prices.
THis isn't always possible. The market data vendor I connect to
insists that I read the stock prices as float. So when I reach
into the byte-stream I will have to memcpy sizeof(float) number of
bytes. Since everywhere else the system uses double to hold these
prices, I had no choice but to stuff that retreived float value
into a double causing all these problems.
This is inherently impossible. While some systems use IEEE float
format, many do not, so you don't even know the bit pattern coming
in. Are you sure you aren't reading and converting a text stream?
If so all you have to do is write a suitable parser for a
particular text format, say dddd.dd, where d is a digit.
It's inherently possible to do this portably.
My guess (and it's only a guess) is that his vendor is providing raw
data of type "float", probably in 32-bit IEEE format in some
particular byte order. If Dilip has already been successful in
storing this incoming data in objects of type "float", then that part
of the problem is solved.
The remaining problem is what to do with the information once he has
it.
This is absolutely **spot-on**! I shudder to think what would happen
if you are armed with hard facts (as opposed to guessing) :-)
But thanks to the many wise men who contributed to this thread now I
have a far better understanding of my problem.
William Hughes wrote:
Ernie Wright wrote:
CBFalconer wrote:
Ernie Wright wrote:
>CBFalconer wrote:
>>Ben Pfaff wrote:
>>>
>>>For what it's worth, the round function is new in C99.
>>>
>>and unnecessary.
>>>
>> price_cents = 100 * floating_price + 0.5;
>>
>which is only one of several widely used rounding rules, and not
>necessarily the one preferred for financial transactions.
>
which won't matter in the case posted by the OP. He started with a
constant of the form 89.13, i.e. with exactly 2 decimal places.
I infer that he started with a 32-bit IEEE float, which can only have
exactly two decimal places if they happen to be ".25", ".50" or ".75".
No, the "two decimal places" refers to the desired value,
a value known by the supplier of the stock prices.
What he has is a float that approximates the desired value.
As you note, this will rarely be exact.
This is **exactly** true.
Once again I cannot convince my boss to remove that nasty
mutiply/divide by 1000.0 kludge since he seems to believe that solves
whatever problem they have been having. Please read my very first post
to understand why I say this -- this kludge rounded off the number to
the nearest cent higher than the floating point representation and he
seems to be happy with that. (i.e what started off with
59.889999389648437 caused problems and what made him happy after the
kludge was the fact the same number got approximated as
59.890000000000001).
Everyone posted here seems incredibly astute -- I am almost cowering in
comparison. But the good thing I found the right way to solve this
problem. Here is what I have come up with: (i am not suggesting to the
management as yet though).
int main()
{
float f = 59.89F;
double d = ff;
double d_fractional, d_integral, d_floorvalue;
d_fractional = d_integral = d_floorvalue = 0;
d_fractional = modf(d, &d_integral);
d_floorvalue = floor(d_fractional*100.0 + 0.5) / 100.0;
double result = d_integral + d_floorvalue;
return 0;
}
Am I in the right direction?
2006-12-21 <11**********************@79g2000cws.googlegroups. com>,
Dilip wrote:
William Hughes wrote:
>Ernie Wright wrote:
CBFalconer wrote:
Ernie Wright wrote:
CBFalconer wrote:
Ben Pfaff wrote:
For what it's worth, the round function is new in C99.
and unnecessary.
price_cents = 100 * floating_price + 0.5;
which is only one of several widely used rounding rules, and not
necessarily the one preferred for financial transactions.
which won't matter in the case posted by the OP. He started with a
constant of the form 89.13, i.e. with exactly 2 decimal places.
I infer that he started with a 32-bit IEEE float, which can only have
exactly two decimal places if they happen to be ".25", ".50" or ".75".
No, the "two decimal places" refers to the desired value,
a value known by the supplier of the stock prices.
What he has is a float that approximates the desired value.
As you note, this will rarely be exact.
This is **exactly** true.
Once again I cannot convince my boss to remove that nasty
mutiply/divide by 1000.0 kludge since he seems to believe that solves
whatever problem they have been having. Please read my very first post
to understand why I say this -- this kludge rounded off the number to
the nearest cent higher than the floating point representation and he
seems to be happy with that. (i.e what started off with
59.889999389648437 caused problems and what made him happy after the
kludge was the fact the same number got approximated as
59.890000000000001).
Everyone posted here seems incredibly astute -- I am almost cowering in
comparison. But the good thing I found the right way to solve this
problem. Here is what I have come up with: (i am not suggesting to the
management as yet though).
int main()
{
float f = 59.89F;
double d = ff;
double d_fractional, d_integral, d_floorvalue;
d_fractional = d_integral = d_floorvalue = 0;
d_fractional = modf(d, &d_integral);
d_floorvalue = floor(d_fractional*100.0 + 0.5) / 100.0;
double result = d_integral + d_floorvalue;
return 0;
}
Am I in the right direction?
Actually, I'd say eschew floating point except where necessary
#include <math.h>
int main() {
float f=59.89f;
long cents;
#if __STDC_VERSION__ >= 199901L
cents = lrint(f*100.0)
#else
/* This code does not handle negative numbers correctly, but it's
not needed for your case. */
cents = (f*100.0+0.5)
#endif
printf("%d.%02d",cents/100,cents%100);
/*Use integral cents [or thousandths, or whatever precision you're
supposed to be using, I don't think you've told us] for all further
calculations.*/
}
This is financial data, you can't afford to be screwing around with
floating point more than is _strictly_ necessary.
Get it into your boss's head that the problem is caused by the use of
floating point, and multiplying/dividing by 0x1.f4p+9 is not going to
solve anything in the long run.
Dilip wrote:
William Hughes wrote:
Ernie Wright wrote:
CBFalconer wrote:
>
Ernie Wright wrote:
CBFalconer wrote:
>Ben Pfaff wrote:
>>
>>For what it's worth, the round function is new in C99.
>>
>and unnecessary.
>>
> price_cents = 100 * floating_price + 0.5;
>
which is only one of several widely used rounding rules, and not
necessarily the one preferred for financial transactions.
which won't matter in the case posted by the OP. He started with a
constant of the form 89.13, i.e. with exactly 2 decimal places.
>
I infer that he started with a 32-bit IEEE float, which can only have
exactly two decimal places if they happen to be ".25", ".50" or ".75".
No, the "two decimal places" refers to the desired value,
a value known by the supplier of the stock prices.
What he has is a float that approximates the desired value.
As you note, this will rarely be exact.
This is **exactly** true.
Once again I cannot convince my boss to remove that nasty
mutiply/divide by 1000.0 kludge since he seems to believe that solves
whatever problem they have been having. Please read my very first post
to understand why I say this -- this kludge rounded off the number to
the nearest cent higher than the floating point representation and he
seems to be happy with that. (i.e what started off with
59.889999389648437 caused problems and what made him happy after the
kludge was the fact the same number got approximated as
59.890000000000001).
Everyone posted here seems incredibly astute -- I am almost cowering in
comparison. But the good thing I found the right way to solve this
problem. Here is what I have come up with: (i am not suggesting to the
management as yet though).
int main()
{
float f = 59.89F;
double d = ff;
double d_fractional, d_integral, d_floorvalue;
d_fractional = d_integral = d_floorvalue = 0;
d_fractional = modf(d, &d_integral);
d_floorvalue = floor(d_fractional*100.0 + 0.5) / 100.0;
double result = d_integral + d_floorvalue;
return 0;
}
Am I in the right direction?
Yes, modulo the fact that you can achieve almost exactly the
same thing by
double result = (floor(100.0*f + 0.5))/100.0
However, the more complicated method may impress your boss
who seems to have a bad case of PHB syndrome.
- William Hughes
Dilip wrote:
But the good thing I found the right way to solve this problem.
No you haven't.
If the floats you're getting are precise to one cent, you can recover
their exact values with
dollars = ( int ) f;
cents = ( int )( f * 100 + 0.5 ) % 100;
You can then assign this to a double with
d = dollars + cents / 100.0;
Or you can use your more complicated procedure, or any of the others
that have been posted.
NONE of them solve your problem. They have exactly the same voodoo
property as the original kludge. They will all work on some values and
fail on others. Instead of 58.89, try them all with 59.11. Your "right
way," my way above, and the original
f *= 1000.0;
d = (double)f / 1000.0;
kludge all produce a double with EXACTLY the same value:
59.10999999999999943156581139...
You convinced yourself before your first post that the problem was this
float-into-double business, you entitled your post with that mindset,
and after all that's been said, you still think this.
Your problem is the truncation that happens later. THAT's where you
need to do some sort of rounding. NOT HERE.
- Ernie http://home.comcast.net/~erniew
I wrote:
In most implementations, both float and double represent numbers as
(1 + m / 2^b) * 2^e
where m is (part of) the mantissa, b is the number of bits in m, e is
the exponent, and '^' denotes exponentiation. b is 23 for floats and 53
for doubles. Given the m, b, e of a float, you get the double with
m <<= 30
b += 30
e = e
Oops. b is 52 for doubles, not 53. So
m <<= 29
b += 29
and so on.
- Ernie http://home.comcast.net/~erniew
Ernie Wright wrote:
Dilip wrote:
But the good thing I found the right way to solve this problem.
No you haven't.
If the floats you're getting are precise to one cent, you can recover
their exact values with
dollars = ( int ) f;
cents = ( int )( f * 100 + 0.5 ) % 100;
You can then assign this to a double with
d = dollars + cents / 100.0;
Or you can use your more complicated procedure, or any of the others
that have been posted.
NONE of them solve your problem. They have exactly the same voodoo
property as the original kludge. They will all work on some values and
fail on others. Instead of 58.89, try them all with 59.11. Your "right
way," my way above, and the original
f *= 1000.0;
d = (double)f / 1000.0;
kludge all produce a double with EXACTLY the same value:
59.10999999999999943156581139...
You convinced yourself before your first post that the problem was this
float-into-double business, you entitled your post with that mindset,
and after all that's been said, you still think this.
Your problem is the truncation that happens later. THAT's where you
need to do some sort of rounding. NOT HERE.
I totally understand. I probably miscommunicated something. Its true
that the problem happens in another part of the system but since
changing that part of the system is simply impossible (I have no idea
why.. I am just a new guy around here), the way they solve it is by
making that double look like what they want on **my** end before that
value gets shipped off and truncated or rounded off or whatever.
See the difference?
Of course in order to make it "look like what they want" they used that
stupid kludge which as you pointed out is not going to help me in all
cases.
Oh well.. at least I have a "I told you so" moment coming up.
2006-12-21 <11**********************@n67g2000cwd.googlegroups .com>,
Dilip wrote:
Ernie Wright wrote:
>Dilip wrote:
But the good thing I found the right way to solve this problem.
No you haven't.
If the floats you're getting are precise to one cent, you can recover
their exact values with
dollars = ( int ) f;
cents = ( int )( f * 100 + 0.5 ) % 100;
You can then assign this to a double with
d = dollars + cents / 100.0;
Or you can use your more complicated procedure, or any of the others
that have been posted.
NONE of them solve your problem. They have exactly the same voodoo
property as the original kludge. They will all work on some values and
fail on others. Instead of 58.89, try them all with 59.11. Your "right
way," my way above, and the original
f *= 1000.0;
d = (double)f / 1000.0;
kludge all produce a double with EXACTLY the same value:
59.10999999999999943156581139...
You convinced yourself before your first post that the problem was this
float-into-double business, you entitled your post with that mindset,
and after all that's been said, you still think this.
Your problem is the truncation that happens later. THAT's where you
need to do some sort of rounding. NOT HERE.
I totally understand. I probably miscommunicated something. Its true
that the problem happens in another part of the system but since
changing that part of the system is simply impossible (I have no idea
why.. I am just a new guy around here), the way they solve it is by
making that double look like what they want on **my** end before that
value gets shipped off and truncated or rounded off or whatever.
Well, if that's the case, just add 0.000001 - it's better if it _looks_
like a kludge, because then more knowledgeable people can fix it later.
Make sure to comment it something like "code elsewhere rounds down
improperly, so make sure we're on the right side of the real value by
adding this."
It'll also (probably) always work to do what you want.
Or just go with their way, and when it blows up, say "you should have
let me change it"
Of course in order to make it "look like what they want" they used that
stupid kludge which as you pointed out is not going to help me in all
cases.
Oh well.. at least I have a "I told you so" moment coming up.
Dilip wrote:
Ernie Wright wrote:
>Your problem is the truncation that happens later. THAT's where you
need to do some sort of rounding. NOT HERE.
I totally understand. I probably miscommunicated something. Its true
that the problem happens in another part of the system but since
changing that part of the system is simply impossible (I have no idea
why.. I am just a new guy around here), the way they solve it is by
making that double look like what they want on **my** end before that
value gets shipped off and truncated or rounded off or whatever.
OK. In that case, I'd go with Random832's second option: leave it
alone for now.
The kludge does have an effect on the value. Using 59.11,
d = f: 59.1100006103515625
kludge: 59.10999999999999943156581139192
The kludge produces a value that differs from 59.11 by a much smaller
amount. In fact, it's the best possible double-precision representation
of 59.11. Furthermore, I'm pretty sure that'll be true for all stock
prices you're likely to encounter.
So maybe the problem isn't truncation. It's just the need for best
possible accuracy. Your safest option is to leave this alone until you
know more about the problem this is supposed to fix.
- Ernie http://home.comcast.net/~erniew
"Dilip" <rd*****@lycos.comwrites:
[...]
Once again I cannot convince my boss to remove that nasty
mutiply/divide by 1000.0 kludge since he seems to believe that solves
whatever problem they have been having. Please read my very first post
to understand why I say this -- this kludge rounded off the number to
the nearest cent higher than the floating point representation and he
seems to be happy with that. (i.e what started off with
59.889999389648437 caused problems and what made him happy after the
kludge was the fact the same number got approximated as
59.890000000000001).
So multiplying and dividing by 1000.0 gives you a seemingly better
result if the input happens to be 59.889999389648437 (or whatever).
Can you find a case where multiplying and dividing by 1000.0 gives you
a *worse* result, and show it to your boss?
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Dilip wrote:
I am showing exactly what is being done in our codebase. Why do you
say there is a compiler bug? If you try the example, as soon as the
1st line is executed the variable f contains 59.889999. After its
stuffed into double d, it becomes 59.889999389648437 (I know these
values vary after a certain decimal position). The
multiplication/division to 1000.0 however produces 59.890000000000001
in dd. The management somehow feels thats a more "accurate"
representation. I guess after rounding off to 2 decimal places they
expected 59.89 but a bug somewhere in the code ensured that the former
case got rounded off to 59.88. It was off by a penny and that
triggered major problems in other calculations.
Could you please post which compiler you are using so that we can avoid
it?
If the situation is as described, then I would be rather sure that your
compiler is broken, and I wouldn't go anywhere near it. If you rely on
that strange behavior of the compiler, you are skating on very thin
ice. 59.889999389648437 looks like a bona fide 32 bit floating point
number. The C Standard requires one hundred percent that f is rounded
to single precision, the multiplication by 1000.0 and division by
1000.0 are one hundred percent required to be done in double precision,
which means that getting a result of 59.890000000000001 is absolutely
impossible unless the compiler is broken.
While this particular bug worked in your favor, you cannot possibly
rely on this compiler. If it has a bug like this, you don't know what
other bugs it has. Switch compilers. Maybe switch to Java, using a Sun
certified implementation, and turn "strict floating point arithmetic"
on; that way you can rely on your results (that means if anything is
wrong, it is your code that is wrong and not the compiler).
If getting the correct results is important to you, then I recommend
hiring someone who knows how arithmetic in C works. This is not
something that you will learn on Usenet.
Dilip wrote:
Once again I cannot convince my boss to remove that nasty
mutiply/divide by 1000.0 kludge since he seems to believe that solves
whatever problem they have been having. Please read my very first post
to understand why I say this -- this kludge rounded off the number to
the nearest cent higher than the floating point representation and he
seems to be happy with that. (i.e what started off with
59.889999389648437 caused problems and what made him happy after the
kludge was the fact the same number got approximated as
59.890000000000001).
I think your compiler problem is not the biggest problem that you have.
If your boss was a programmer where I work, he would be fired.
int main()
{
float f = 59.89F;
double d = ff;
double d_fractional, d_integral, d_floorvalue;
d_fractional = d_integral = d_floorvalue = 0;
d_fractional = modf(d, &d_integral);
d_floorvalue = floor(d_fractional*100.0 + 0.5) / 100.0;
double result = d_integral + d_floorvalue;
return 0;
}
It will give the right result for positive values, but is overly
complicated. On the other hand, according to the information that you
have given us, your compiler cannot be trusted, so both your code and
my code below cannot be guaranteed to work.
double round_to_hundredths (double x)
{
if (x >= 0) return floor (100,0 * x + 0.5) / 100.0;
else return ceil (100.0 * x - 0.5) / 100.0;
}
Ernie Wright wrote:
If the floats you're getting are precise to one cent, you can recover
their exact values with
dollars = ( int ) f;
cents = ( int )( f * 100 + 0.5 ) % 100;
Before you do this in real life, try what happens when f = 19.999.
christian.bau wrote:
Ernie Wright wrote:
>If the floats you're getting are precise to one cent, you can recover
their exact values with
dollars = ( int ) f;
cents = ( int )( f * 100 + 0.5 ) % 100;
Before you do this in real life, try what happens when f = 19.999.
Please note the necessary condition: IF the floats are precise to one
cent, meaning they are the float representation of a number with two
decimal places. The above works with both 19.99 and 20.00.
- Ernie http://home.comcast.net/~erniew
christian.bau wrote:
double round_to_hundredths (double x)
{
if (x >= 0) return floor (100,0 * x + 0.5) / 100.0;
else return ceil (100.0 * x - 0.5) / 100.0;
}
Before you do this in real life, try what happens when x = 19.999.
- Ernie http://home.comcast.net/~erniew
christian.bau wrote:
If the situation is as described, then I would be rather sure that your
compiler is broken, and I wouldn't go anywhere near it. If you rely on
that strange behavior of the compiler, you are skating on very thin
ice. 59.889999389648437 looks like a bona fide 32 bit floating point
number. The C Standard requires one hundred percent that f is rounded
to single precision, the multiplication by 1000.0 and division by
1000.0 are one hundred percent required to be done in double precision,
which means that getting a result of 59.890000000000001 is absolutely
impossible unless the compiler is broken.
Are you sure about that?
We start with
double d;
float f = 59.89f;
after which f is represented internally as
(1 + 7311196 / 8388608) * 32 = 59.8899993896484375
This is as close as a float can get to 59.89. Next we do
f *= 1000.0;
after which f is represented internally as
(1 + 6943232 / 8388608) * 32768 = 59890.0 exactly
You don't have to take my word for it, but I won't show how the multiply
is done in binary. Finally,
d = f / 1000.0;
after which d is represented as
(1 + 3925168550230098 / 4503599627370496) * 32
= 59.89000000000000056843418860808
And this is as close as a *double* can be to 59.89. Not only is this
not broken, it's exactly what's required by the IEEE 754 standard. Nor
do you have to go through all of the above steps.
f = 59.89f;
d = 59.89;
produces the same bit patterns and the same slight difference in value.
- Ernie http://home.comcast.net/~erniew
Ernie Wright wrote:
christian.bau wrote:
>double round_to_hundredths (double x)
{
if (x >= 0) return floor (100,0 * x + 0.5) / 100.0;
else return ceil (100.0 * x - 0.5) / 100.0;
}
Before you do this in real life, try what happens when x = 19.999.
Sorry, ignore that. Operator error: copy-paste-send.
- Ernie http://home.comcast.net/~erniew
In article <11**********************@a3g2000cwd.googlegroups. com"William Hughes" <wp*******@hotmail.comwrites:
Dik T. Winter wrote:
....
The whole point is that in most financial transactions it is precisely
defined how fractions of something should be rounded. Any attempt to
be slightly imprecise (using floating point) will fail at some point
or another.
>
No. The question is not whether the imprecise answer is the
correct answer (this is highly unlikely), but whether
the correct answer can be determined from the
imprecise answer.
And the answer is: if the calculations are more than trivial certainly
not.
??. You cannot do non-trivial calculations to a precision
greater that 1/2 of your smallest currency unit?
Eh? I can not follow this.
Using integer arithmetic you are sure you get the correct answer
(supposing, of course, that you properly scale everything).
No, you need a large enough integer type as well (scaling
will not help if you are using char). Also, how do you
do compound intererst calculations "using integer arithmetic"
and how does the fact that you are using integer arithmetic
help you to determine a "correct' answer based on a non-mathematical
standard of correctness.
See below.
For i there is no clear advantage to integer calculations (though it
is clear that there are native floating point type and native integer
types that do not satisfy i).
If a native integer type is not sufficient, use something larger.
Indeed. But why can't this "something larger" be a floating
point type with sufficient precision? If there is sufficient
precision you can still determine the correct answer.
As long as you use only integer representations in your floating point
type there is no problem. However, be aware that each time you should
be sure that your floating point variable represents an integer.
For ii, there may be small advantage to integer calculations, but
given that calculations with non-integer results (e.g. compound
interest) are needed, this advantage is, at best, quite small.
Compound interest is best calculated using yearly interest calculation
with proper rounding after each year, otherwise you will almost
certainly *not* get the correct answer.
This can be done as conveniently using floating point arithmetic
as using fixed point arithmetic. In either case you have to
do rounding.
If you need rounding at each step of your floating point calculations, I
do not see any advantage using that type over an integral type. On the
other hand, when you are using floating-point it is likely that you will
use the exp function to calculate compound interest. That will, almost
certainly, give the wrong result.
(yes this means that calculations with Turkish Lira are not
exact to the lira) and failing gracefully when the numbers
become large.
And this means that if the Turkish law requires something to be
calculated to the Lira that your system is not good enough.
If this is a requirement, such a system can be written
as easily using high precision floating point as large
integer. However, note that such a law would
regularly require inputs to be specified with an error
of less than 10^-9. It is unlikely to be honoured or
enforced.
Why? When the euro was introduced, the associated countries decided on
precise values that must be used when converting old currency to the
new currence. They were stated (in decimal) to a particular figure
after the decimal point. It required quite some effort to show that
doing it in floating-point would not be wrong *if* properly rounded
at the appropriate stages. But even there, there was still some
uncertainty. The one cent difference is quite important in financial
institutions. Now, Dutch tax laws are quite lax with respect to
rounding. Any figure you state on your tax return form you can round
to one of the two nearest plain euro values anyway you see appropriate.
I know that there are countries that are more strict.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Mark McIntyre wrote:
<Di********@cwi.nlwrote:
>"William Hughes" <wp*******@hotmail.comwrites:
...
>>>A 64 bit integer will correctly model currency to 18 digits
(with hundredths units that gives 16 digits for the integer
part). In a mythical currency with 1,000,000 units per dollar,
Nothing mythical here.
1 US dollar = 1374865.7 Turkish Lira
You are out of date. 1 US dollar = 1.4283 Turkish Lira.
Old vs new Lira, both still in use.
Anyway, vietnamese dong are a better example...
>>So don't use 64 bit integers to calculate the world GDP in
Turkish Lira unless your system is tolerant of small errors.
You still fail to see how the financial world is looking at it.
They require exactness to some predefined unit. And if some
system requires precision to the cent, do the calculations to
the cent.
What makes it interesting is that the "predefined unit" is
variable by currency, market and calculation.
Listen to Mark. He is one of those well beloved creatures, a
banker. Usually considered infinitely superior to a lawyer, or a
politician. :_)
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
In article <11*********************@42g2000cwt.googlegroups.c om"christian.bau" <ch***********@cbau.wanadoo.co.ukwrites:
....
If the situation is as described, then I would be rather sure that your
compiler is broken, and I wouldn't go anywhere near it. If you rely on
that strange behavior of the compiler, you are skating on very thin
ice. 59.889999389648437 looks like a bona fide 32 bit floating point
number. The C Standard requires one hundred percent that f is rounded
to single precision, the multiplication by 1000.0 and division by
1000.0 are one hundred percent required to be done in double precision,
which means that getting a result of 59.890000000000001 is absolutely
impossible unless the compiler is broken.
Christian. I thought you knew better than this. With the multiplication
by 1000 we get another rounding. (The multiplication is done in single
precision.) But apparently you should avoid gcc on both Linux and
Solaris. Try the following program with your favourite compiler:
#include <stdio.h>
int main()
{
float f = 59.89F;
double d = f;
double dd;
f *= 1000.0;
dd = (double)f / 1000.0;
printf("%30.17g %30.17g\n", d, dd);
return 0;
}
and look at the result. On the systems I use it looks like:
59.889999389648438 59.890000000000001
Switch compilers. Maybe switch to Java, using a Sun
certified implementation, and turn "strict floating point arithmetic"
on; that way you can rely on your results (that means if anything is
wrong, it is your code that is wrong and not the compiler).
Right. The results are exactly conforming to IEEE arithmetic.
And you would have found that also if you had considered the actual
program and analyzed it.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In article <11**********************@42g2000cwt.googlegroups. com"christian.bau" <ch***********@cbau.wanadoo.co.ukwrites:
....
It will give the right result for positive values, but is overly
complicated. On the other hand, according to the information that you
have given us, your compiler cannot be trusted, so both your code and
my code below cannot be guaranteed to work.
Can you tell me a compiler that can be trusted? Gcc is not in that class
as it shows the "bug".
You are ridiculously harsh here on people that do not understand the
working of floating point. I think you did not even try the initial
program. The behaviour quoted is exactly according to the IEEE standard
of floating point arithmetic. Pray, calm down a bit.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In article <11**********************@80g2000cwy.googlegroups. com"christian.bau" <ch***********@cbau.wanadoo.co.ukwrites:
Ernie Wright wrote:
If the floats you're getting are precise to one cent, you can recover
their exact values with
dollars = ( int ) f;
cents = ( int )( f * 100 + 0.5 ) % 100;
Before you do this in real life, try what happens when f = 19.999.
Is that a float precise to one cent?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter wrote:
In article <11**********************@a3g2000cwd.googlegroups. com"William Hughes" <wp*******@hotmail.comwrites:
Dik T. Winter wrote:
...
The whole point is that in most financial transactions it is precisely
defined how fractions of something should be rounded. Any attempt to
be slightly imprecise (using floating point) will fail at some point
or another.
>
No. The question is not whether the imprecise answer is the
correct answer (this is highly unlikely), but whether
the correct answer can be determined from the
imprecise answer.
And the answer is: if the calculations are more than trivial certainly
not.
>
??. You cannot do non-trivial calculations to a precision
greater that 1/2 of your smallest currency unit?
Eh? I can not follow this.
The question is. Can we determine the correct answer from
the floating point value.
Assume possible precise answers are spaced at intervals of the smallest
currency unit.
We convert the floating point value to a precise answer by
finding the closest precise answer.
We now see that as long as the error is less that 1/2 of the smallest
currency spacing, the closest precise answer will also be the
correct answer.
>
Using integer arithmetic you are sure you get the correct answer
(supposing, of course, that you properly scale everything).
>
No, you need a large enough integer type as well (scaling
will not help if you are using char). Also, how do you
do compound intererst calculations "using integer arithmetic"
and how does the fact that you are using integer arithmetic
help you to determine a "correct' answer based on a non-mathematical
standard of correctness.
See below.
For i there is no clear advantage to integer calculations (though it
is clear that there are native floating point type and native integer
types that do not satisfy i).
If a native integer type is not sufficient, use something larger.
>
Indeed. But why can't this "something larger" be a floating
point type with sufficient precision? If there is sufficient
precision you can still determine the correct answer.
As long as you use only integer representations in your floating point
type there is no problem.
No, as long as the floating point representation remains within
half of your smallest currency unit there is not problem.
However, be aware that each time you should
be sure that your floating point variable represents an integer.
Why? All I need is to be sure that I can recover the correct value.
>
For ii, there may be small advantage to integer calculations, but
given that calculations with non-integer results (e.g. compound
interest) are needed, this advantage is, at best, quite small.
Compound interest is best calculated using yearly interest calculation
with proper rounding after each year, otherwise you will almost
certainly *not* get the correct answer.
>
This can be done as conveniently using floating point arithmetic
as using fixed point arithmetic. In either case you have to
do rounding.
If you need rounding at each step of your floating point calculations, I
do not see any advantage using that type over an integral type.
No, you round where required by accountancy rules or when
needed for precision. This may be
much less than every step. And there is a big advantage
in being able to use the existing floating point system rather
than having to obtain or roll you own fixed point system.
On the
other hand, when you are using floating-point it is likely that you will
use the exp function to calculate compound interest. That will, almost
certainly, give the wrong result.
Why? There is no reason to turn you brain off when you use floating
point. If the exp function does not give the accounting answer, and
you
want the accounting answer, then don't use the exp function (Duh!).
- William Hughes
On Thu, 21 Dec 2006 02:53:22 GMT, Dik T. Winter wrote:
>In article
"William Hughes" <wp*******@hotmail.comwrites:
...
A 64 bit integer will correctly model currency to 18 digits (with
hundredths units that gives 16 digits for the integer part).
In a mythical currency with 1,000,000 units per dollar,
Nothing mythical here.
1 US dollar = 1374865.7 Turkish Lira
You are out of date. 1 US dollar = 1.4283 Turkish Lira.
that would
leave 10 billion dollar transactions accurate to the penny.
So don't use 64 bit integers to calculate the world GDP in
Turkish Lira unless your system is tolerant of small errors.
You still fail to see how the financial world is looking at it.
They require exactness to some predefined unit. And if some
system requires precision to the cent, do the calculations to
the cent.
i think that
"exactness to some predefined unit"
not exist if i have to do divisions
all you that have the experience that i don't have
What about to
considering money like a fixed point number of type
xIntegers.10Integers
than i show the number in form "x.xx" (with round to 3 decimal digits
afther the point)?
(but that number is stored like its format e.g.
in hex 123.12345678 12345678 12345678 12345678 12345678
12345678 12345678 12345678 12345678 12345678
)
how many divisions, sum, differences i have to do for to have
an error of 1 cent show when print it, with above numbers? (if it is
supposed implementation bug-free)
thank you
On 21 Dec 2006 21:08:59 -0800, in comp.lang.c , "William Hughes"
<wp*******@hotmail.comwrote:
>
Assume possible precise answers are spaced at intervals of the smallest
currency unit.
We convert the floating point value to a precise answer by
finding the closest precise answer.
We now see that as long as the error is less that 1/2 of the smallest
currency spacing, the closest precise answer will also be the
correct answer.
This doesn't follow, unless the currency rounding rule is to select
the closest precise answer, and in that case its tautological.
Several markets and currencies do not follow this rule - eg they
always round down, or always discard pennies, or round up if the
integer part is even, and down if its odd. Or whatever.
If you want "correct" values, you need to implement special handling
routines for rounding.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mark McIntyre wrote:
On 21 Dec 2006 21:08:59 -0800, in comp.lang.c , "William Hughes"
<wp*******@hotmail.comwrote:
Assume possible precise answers are spaced at intervals of the smallest
currency unit.
We convert the floating point value to a precise answer by
finding the closest precise answer.
We now see that as long as the error is less that 1/2 of the smallest
currency spacing, the closest precise answer will also be the
correct answer.
This doesn't follow, unless the currency rounding rule is to select
the closest precise answer, and in that case its tautological.
You are confusing levels.
Calculate the precise answer.
(This may include arbitrary rules, such as
"every second thursday of a month that doesn't
contain r, add 1). It is at this level
that the rounding rules you are talking about
are relevent
Represent the precise answer. (assumed to
be an integral number of currency units)
One method is to store the precise answer
as an integer. However, any method of
coding that can be unabiguously solved
will work. An obvious alternative is to
code the precise answer as any floating
point number with the property that it is
closer to the desired value, than any
non desired value. The "rounding" here is
just a decoding mechanism. It has nothing
to do with the accounting rules of rounding.
Several markets and currencies do not follow this rule - eg they
always round down, or always discard pennies, or round up if the
integer part is even, and down if its odd. Or whatever.
If you want "correct" values, you need to implement special handling
routines for rounding.
Duh! If you want the correct answer you have to calculate it.
I am not saying that floating point arithmetic mirrors financial
rules, only that financial rules can be expressed as conveniently
in floating point as in integer.
- William Hughes
2006-12-22 <JA********@cwi.nl>,
Dik T. Winter wrote:
In article <11**********************@80g2000cwy.googlegroups. com"christian.bau" <ch***********@cbau.wanadoo.co.ukwrites:
Ernie Wright wrote:
>
If the floats you're getting are precise to one cent, you can recover
their exact values with
dollars = ( int ) f;
cents = ( int )( f * 100 + 0.5 ) % 100;
>
Before you do this in real life, try what happens when f = 19.999.
Is that a float precise to one cent?
Not as such. But generally when doing such a thing we would want it to
properly translate 19.9999980926513671875 (i.e. a single value off in
either direction) to 20.00
In article <sl*******************@rlaptop.random.yi.org ra*******@gmail.com writes:
2006-12-22 <JA********@cwi.nl>,
Dik T. Winter wrote:
In article <11**********************@80g2000cwy.googlegroups. com"christian.bau" <ch***********@cbau.wanadoo.co.ukwrites:
Ernie Wright wrote:
If the floats you're getting are precise to one cent, you can recover
their exact values with
dollars = ( int ) f;
cents = ( int )( f * 100 + 0.5 ) % 100;
>
Before you do this in real life, try what happens when f = 19.999.
Is that a float precise to one cent?
Not as such. But generally when doing such a thing we would want it to
properly translate 19.9999980926513671875 (i.e. a single value off in
either direction) to 20.00
Indeed. The statement for dollars should have been:
dollars = (int)(f * 100 + 0.5) / 100;
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter wrote:
In article <11*********************@42g2000cwt.googlegroups.c om"christian.bau" <ch***********@cbau.wanadoo.co.ukwrites:
Christian. I thought you knew better than this. With the multiplication
by 1000 we get another rounding. (The multiplication is done in single
precision.) But apparently you should avoid gcc on both Linux and
Solaris. Try the following program with your favourite compiler:
Yes, I got this wrong. I missed that f * 1000.0 was again assigned to a
float. Which makes the situation more interesting. So here is my
analysis:
Given is a number f, which is equal to an integer x, divided by 100,
rounded to the nearest float value - which obviously gives a rather
large rounding error. An attempt to recover a more precise value is
done by calculating t = (float) (f * 1000.0), then calculating d =
(double) t / 1000.0.
Assume 2^k <= f < 2*2^k. f is equal to the correct x/100 + eps, where
|eps| is less than 1/2 of the least significant bit. f * 1000 is equal
to 10x + 1000eps. t will often be in the range 2^(k+10) <= t <
2*2^(k+10). The difference between f * 1000 and 10x is 1000eps, the
absolute value of this is less than 500 times the least significant
bit.
If 10x can be exactly represented as a float, and 10x >= 2^(2k+10),
then f * 1000 is guaranteed to be so close to 10x that it will be
rounded to 10x, so t = 10x, and therefore d will be a much more precise
result. However, this is not the case if 10x < 2^(2k+10) = 1024 * 2^k
or 1000f < 1024 * 2^k or f < 1.024 * 2^k. So any dollar values between
2^k and 1.024 * 2^k are suspicious, that is values 1.01 and 1.02, 2.01
to 2.04, 4.01 to 4.09 and so on.
The first number where this algorithm fails is 4.01, and it fails for
many values slightly above 4, 8, 16, 32 and so on. It also fails when
10x cannot be represented in a float value; since 10x is even this will
be the case when 10x 2^25 (using 32 bit float) or when the dollar
value is more than 1.024 * $32768.
There is a twist if this is used for share prices: While most share
prices are a whole number of cents, prices for low valued shares can be
in tenths of cents or hundredths of cents. This algorithm also recovers
most, but not all, prices that are in tenths of cents correctly (and
will usually fail for hundredths of cents). Replacing the code with
something that rounds to the nearest cent will make this stop working.
"Dik T. Winter" wrote:
>
.... snip ...
>
Indeed. The statement for dollars should have been:
dollars = (int)(f * 100 + 0.5) / 100;
Assuming dollars is an int (or even a double or float) the usual
rule about casts applies. They are almost always an error, or
useless. Simply omit them unless you have a very good and clear
reason for them. In this particular case the compiler will happily
adapt to declaring dollars as a long, or even a long long (for
C99). In fact, the code shown will happily discard the cents field
when destined for a float or double. Maybe that is what you
intended.
Assuming that is the intention (i.e. exact float representations by
making them integral) you can improve efficiency by:
int incents;
float dollars, cents, f;
incents = f * 100 + 0.5;
dollars = incents / 100;
cents = incents % 100;
avoiding the run time expense of multiple float to int conversions
(which the optimizer might have handled) and avoiding all casts.
The code will remain correct if the floats are changed to doubles,
simplifying maintenance.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
In article <11*********************@a3g2000cwd.googlegroups.c om"William Hughes" <wp*******@hotmail.comwrites:
Dik T. Winter wrote:
In article <11**********************@a3g2000cwd.googlegroups. com"William Hughes" <wp*******@hotmail.comwrites:
....
I:
The whole point is that in most financial transactions it is
precisely defined how fractions of something should be rounded.
Any attempt to be slightly imprecise (using floating point)
will fail at some point or another.
....
??. You cannot do non-trivial calculations to a precision
greater that 1/2 of your smallest currency unit?
Eh? I can not follow this.
The question is. Can we determine the correct answer from
the floating point value.
And I state: no.
Assume possible precise answers are spaced at intervals of the smallest
currency unit.
We convert the floating point value to a precise answer by
finding the closest precise answer.
We now see that as long as the error is less that 1/2 of the smallest
currency spacing, the closest precise answer will also be the
correct answer.
Care to explain? I find that with an initial amount of $100 and with
an interest rate over some period of 2.5%, where the rules state that
the interest has been truncated to the nearest cent, the following
statements (assuming amount to be a long, damount and eamount doubles):
amount += amount * 5 / 200;
damount += damount * 5 / 200;
eamount = rint(eamount * 205 / 200);
there are already differences after the third calculation. You really
need "floor" rather than "rint" in the eamount statement to get the
correct results. And this is only a simple problem of compound
interest.
Determining whether the final result after a number of f-p
calculations is within 1/2 of the correct result is not doable.
As long as you use only integer representations in your floating point
type there is no problem.
No, as long as the floating point representation remains within
half of your smallest currency unit there is not problem.
Depends on the kind of rounding needed for the particular problem.
And when the calculations are only slightly difficult you get problems.
However, be aware that each time you should
be sure that your floating point variable represents an integer.
Why? All I need is to be sure that I can recover the correct value.
And how can you be sure of that?
This can be done as conveniently using floating point arithmetic
as using fixed point arithmetic. In either case you have to
do rounding.
If you need rounding at each step of your floating point calculations, I
do not see any advantage using that type over an integral type.
No, you round where required by accountancy rules or when
needed for precision. This may be much less than every step.
How do you keep track when you should round? In the above compound
interest example I see already that if I do not round at every step
that I get already a wrong result with f-p after three iterations.
And there is a big advantage
in being able to use the existing floating point system rather
than having to obtain or roll you own fixed point system.
I do not think so. 64-bit integers are becoming quite common, and
they give better precision than double precision f-p.
On the
other hand, when you are using floating-point it is likely that you will
use the exp function to calculate compound interest. That will, almost
certainly, give the wrong result.
Why? There is no reason to turn you brain off when you use floating
point. If the exp function does not give the accounting answer, and
you want the accounting answer, then don't use the exp function (Duh!).
And if floating point does not give the accounting answer, and you want
the accounting answer, then don't use floating point.
But try it out with the above rules and an interest rate of 0.5 % per
period (which means that if that is a monthly period, the yearly
interest rate is about 6.12 %). After about 2 to 4 periods there is
a difference between integer and f-p when you do not do intermittently
rounding. (And if the initial capital is $101 the difference shows up
earlier...)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter wrote:
In article <11*********************@a3g2000cwd.googlegroups.c om"William Hughes" <wp*******@hotmail.comwrites:
Dik T. Winter wrote:
In article <11**********************@a3g2000cwd.googlegroups. com"William Hughes" <wp*******@hotmail.comwrites:
...
I:
The whole point is that in most financial transactions it is
precisely defined how fractions of something should be rounded.
Any attempt to be slightly imprecise (using floating point)
will fail at some point or another.
...
??. You cannot do non-trivial calculations to a precision
greater that 1/2 of your smallest currency unit?
Eh? I can not follow this.
>
The question is. Can we determine the correct answer from
the floating point value.
And I state: no.
Assume possible precise answers are spaced at intervals of the smallest
currency unit.
>
We convert the floating point value to a precise answer by
finding the closest precise answer.
>
We now see that as long as the error is less that 1/2 of the smallest
currency spacing, the closest precise answer will also be the
correct answer.
Care to explain? I find that with an initial amount of $100 and with
an interest rate over some period of 2.5%, where the rules state that
the interest has been truncated to the nearest cent, the following
statements (assuming amount to be a long, damount and eamount doubles):
amount += amount * 5 / 200;
damount += damount * 5 / 200;
eamount = rint(eamount * 205 / 200);
there are already differences after the third calculation. You really
need "floor" rather than "rint" in the eamount statement to get the
correct results. And this is only a simple problem of compound
interest.
You are confusing levels. If the rule says truncate, then
truncate do not round. The "rounding" required to
convert a double representation to an integer
representation has little to do with the algorithm used
to compute the double representation.
There are two questions:
What algorithm should be implemented?
What data type should be used to implement the algorithm?
The two questions are different, and the first dominates. When you
change
data type should not change the algorithm!
Consider an algorithm for compound intererest with slightly
modified rounding, principal
p, interest rate per period i, number of periods n, currency dollar.
For period 1 to n
p = round to nearest cent ( p + i p)
We can calculate this using a sufficiently large integer type
or a sufficiently large floating point type. Assume p = 100.00
i= .05/year, the period is 6 months and there are 10 periods.
An integer implementation might look like
long p = 10000;
int 1000_i = 50;
int number_of_periods n=10;
int 1000_i_per_n;
1000_i_per_n = 1000_i / 2;
for(i = 1;i<=n;i++){
p += p*1000_i_per_n/1000
if( 2*( p%1000_i_per_n) >= 1000_i_per_n ){
p++;
}
}
At the end we convert to dollars and cents, dollars = p/100,
cents = p%100.
A floating point implemenation might look like
double p = 10000;
double i = .05;
double i_per_n;
int number_of_periods n = 10;
i_per_n = i/2.0;
for(i = 1;i<=10;i++){
p += p*i_per_n;
if( fmod(100*p,1.0) 0.495) {
p += .01;
}
}
At the end you determine dollars = floor(p), cents = floor(100*p + 0.5)
I see no clear winner here. Both give exaclty the
same answer (even for unrealistically large values
of n) The rounding rule is a bit clearer
in the integer form (and if we specify truncation it can be
ommited altogether in the integer form, not so in the floating
point form) but the interest rate calculation is a bit more
natural in the floating point form. The integer form only works with
interest rate
per period in multiples of .001. This may need to be made
more precise. If accounting rules so specifiy, the interest rate
per period of the floating point form might have to be made less
precise.
Determining whether the final result after a number of f-p
calculations is within 1/2 of the correct result is not doable.
As long as you use only integer representations in your floating point
type there is no problem.
>
No, as long as the floating point representation remains within
half of your smallest currency unit there is not problem.
Depends on the kind of rounding needed for the particular problem.
No. The rounding needed for the particluar problem
is performed. The "rounding" needed to convert from the floating
point representation to an integer representation is something
different.
And when the calculations are only slightly difficult you get problems.
Not different than the problems associated with integer
calculations (you have the advantage that a truncation is
a nop with integer math. Given that you need to implement
general rounding rules in any case, I do not see this as
a big advantage)
However, be aware that each time you should
be sure that your floating point variable represents an integer.
>
Why? All I need is to be sure that I can recover the correct value.
And how can you be sure of that?
This can be done as conveniently using floating point arithmetic
as using fixed point arithmetic. In either case you have to
do rounding.
If you need rounding at each step of your floating point calculations, I
do not see any advantage using that type over an integral type.
>
No, you round where required by accountancy rules or when
needed for precision. This may be much less than every step.
How do you keep track when you should round? In the above compound
interest example I see already that if I do not round at every step
that I get already a wrong result with f-p after three iterations.
If you do not implement the correct algorithm you get
the wrong answer (Duh!).
You have to round after every step with integer arithmetic.
The fact that if the rounding rule is truncation you can
ommit this step is not true in general.
And there is a big advantage
in being able to use the existing floating point system rather
than having to obtain or roll you own fixed point system.
I do not think so. 64-bit integers are becoming quite common, and
they give better precision than double precision f-p.
And both are too small for some real world problems.
The class of problems for which double is insufficient, but
64 bit integer is sufficient, is not very large.
You still need to deal with fractions. Whether
you do so by using a fixed point system or
approximate rational arithmetic, native
support for 64 bits will only take you so far.
On the
other hand, when you are using floating-point it is likely that you will
use the exp function to calculate compound interest. That will, almost
certainly, give the wrong result.
>
Why? There is no reason to turn you brain off when you use floating
point. If the exp function does not give the accounting answer, and
you want the accounting answer, then don't use the exp function (Duh!).
And if floating point does not give the accounting answer, and you want
the accounting answer, then don't use floating point.
A sufficiently precise floating point can be used to implement
any accounting algorithm. The question is whether
this is less convenient that using (sufficiently large)
integer arithmetic.
- William Hughes
William Hughes wrote:
Dik T. Winter wrote:
>>
A floating point implemenation might look like
double p = 10000;
double i = .05;
double i_per_n;
int number_of_periods n = 10;
i_per_n = i/2.0;
for(i = 1;i<=10;i++){
p += p*i_per_n;
Correction
if( fmod(100*p,1.0) 0.495) {
p += .01;
}
Should be
if( fmod(100*p,1.0) 0.495) {
p += .01 - fmod(p,0.01);
}
else {
p -= fmod(p,0.01);
}
- William Hughes
In article <11*********************@80g2000cwy.googlegroups.c om"William Hughes" <wp*******@hotmail.comwrites:
Dik T. Winter wrote:
....
Consider an algorithm for compound intererest with slightly
modified rounding, principal
p, interest rate per period i, number of periods n, currency dollar.
For period 1 to n
p = round to nearest cent ( p + i p)
We can calculate this using a sufficiently large integer type
or a sufficiently large floating point type. Assume p = 100.00
i= .05/year, the period is 6 months and there are 10 periods.
If the period is 1/2 year, the interest per period is not one half of
the year interest. Try to do it over a five year period. A yearly
interest rate of .05 gives after five years $ 127.63 and an half-yearly
interest rate of .025 gives after five years $ 128.01. A difference
that some accountants worry about. There are specific rules how to
do interest about a period smaller than the base period (although the
rules depend on the situation).
But let me assume that the interest is 0.025 / 6 months.
An integer implementation might look like
long p = 10000;
int 1000_i = 50;
int number_of_periods n=10;
int 1000_i_per_n;
1000_i_per_n = 1000_i / 2;
for(i = 1;i<=n;i++){
p += p*1000_i_per_n/1000
if( 2*( p%1000_i_per_n) >= 1000_i_per_n ){
p++;
}
}
I would do it as:
long amount = 20000; /* 2 times the amount in cents */
...
for(i = 1; i <= n; i++) {
amount += amount * 1000_i_per_n / 1000;
amount += (amount & 1);
}
amount /= 2; /* the real amount in cents after the calculations */
Your formulation is wrong. When the amount is 10769 cents (3-rd
iteration), the interest calculations give an interest of 269.225 cents,
that is rounded 269 cents. The next result is 11038 cents. Your formula
gives 11039.
What is wrong is that your formulation uses cents as units for p and
you try to find out what has been rounded off from that value. But your
formulation is about twice as slow as mine. (For 1,000,000 iterations
52 vs. 32 seconds.) Improving the condition when a cent should be added
would increase the calculation time.
A floating point implemenation might look like
double p = 10000;
double i = .05;
double i_per_n;
int number_of_periods n = 10;
i_per_n = i/2.0;
for(i = 1;i<=10;i++){
p += p*i_per_n;
if( fmod(100*p,1.0) 0.495) {
p += .01 - fmod(p, 0.01);
} else {
p -= fmod(p, 0.01);
}
}
I incorporated your later improvement. But the result still is wrong.
You get already a difference after the 18-th iteration with the
formulation I did give. And when I introduce a "p = floor(p + 0.5);"
in each iteration it goes wrong at the 63-rd step (strange enough
the first case where the error is in favour of the bank). And without
the ftrunc the calculation (with 1,000,000 iterations) takes 0.73
seconds, with it it takes 0.90 seconds. You would be better off if
you had eliminated the complete conditional statement and replaced it
by a simple "p = floor(p + 0.5)". In that case the formulation would
be correct (and it would win in terms of speed on the machine I did
try it on: 0,22 seconds for 1,000,000 iterations). But now you simply
do an emulated version of integer arithmetic with floating point.
That can or can not be faster than a true integer formulation, depending
on machine architecture.
I see no clear winner here. Both give exaclty the
same answer (even for unrealistically large values
of n)
I have indicated above where your calculations give wrong results.
The rounding rule is a bit clearer
in the integer form (and if we specify truncation it can be
ommited altogether in the integer form, not so in the floating
point form) but the interest rate calculation is a bit more
natural in the floating point form.
But interest calculations for part periods are *far* from natural.
In my opinion, my formulation is clear, concise, and fast. *And*
you need proper scaling.
And when the calculations are only slightly difficult you get problems.
Not different than the problems associated with integer
calculations (you have the advantage that a truncation is
a nop with integer math. Given that you need to implement
general rounding rules in any case, I do not see this as
a big advantage)
See above.
How do you keep track when you should round? In the above compound
interest example I see already that if I do not round at every step
that I get already a wrong result with f-p after three iterations.
If you do not implement the correct algorithm you get
the wrong answer (Duh!).
Well, you did not do that either.
You have to round after every step with integer arithmetic.
The fact that if the rounding rule is truncation you can
ommit this step is not true in general.
You also have to round after every step with f-p arithmetic. And it
does not matter whether the rounding rule is round to nearest, truncate
or the bankers rule. You have to do it. And I admit that bankers rule
is not easy in integer arithmetic, but it is also not easy in f-p
arithmetic. Let me make an attempt. a is the amount in cents, interest
is the interest per 1000 per period.
i = a * interest / 500;
if(i & 1) { /* if the interest truncates to half a cent */
if(i * 500 a * interest) { /* if less than 0.5 is truncated */
i++; /* round up */
} else if(i & 2) { /* amount in cents is odd */
i++; /* round up */
}
}
a += (i >1);
This, indeed, can be done better in IEEE f-p:
i = rint(a * interest / 1000);
a += i;
But you are still emulating integer arithmetic in f-p.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Marc Schellens |
last post by:
My compiler warns about assignment to int form
float/double.
Will it nevertheless do what I expect?
Are there caveeats/pits?
(Apart from the range and the precision of course)
What would be the...
|
by: Alexander Block |
last post by:
Hello newsgroup,
let's say I have a function like
template<class Type>
inline bool areEqual(const Type &a, const Type &b)
{
return ( a == b );
}
|
by: JKop |
last post by:
Does the Standard specify any minimum range or minimum
precision for the float, double and long double. I haven't
found anything in the Standard about it.
-JKop
|
by: Madan |
last post by:
Hi all,
I had problem regarding float/double arithmetic only with + and -
operations, which gives inaccurate precisions. I would like to know how the
arithmetic operations are internally handled...
|
by: Ollie |
last post by:
Ok, As the Convert.ToDateTime has not been implimented yet, how do I convert
a double to datetime???
I have looked all over with no luck at all.
Please help me!
|
by: illegal.prime |
last post by:
Hi all, I have a class that I would like to use to hide the data type
I'm using to store decimal point numbers. Failing all else, I will
just use object and do conversion/casts as necessary. But...
|
by: veremue |
last post by:
I want to store a float/double as String. I have an input file with a column with float values i.e. have the form 1.4E15. I want to store these values as Strings. Here is my code which is resulting...
|
by: Wander |
last post by:
currently there are those functions is_float, is_double and is_real,
which do exactly the same as far as i can see
what surprises me is that $a = (float/double/real) 1; all work, while
with...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
