do we have to deal with arbitrary precision numbers

# Multiprecision needed?

## Multiprecision needed?

For more complete information about compiler optimizations, see our Optimization Notice.

Hi,

We don't need you to support multiprecision math.

Thanks

-Rama

Quoting Rama Kishan Malladi (Intel)*Hi,We don't need you to support multiprecision math.*

*Thanks-Rama*

Rama,

See my other post.

Your .PDF rule states:

"For example, output(50.323467) should send 50.3234670000 to the output"

50.323467 happens to NOT be a number that is exactly representable by IEEE 754 double precision. Therefore, the above rule would imply (requier) decimal math. Please comment.

Jim Dempsey

www.quickthreadprogramming.com

Quoting jimdempseyatthecove*Quoting Rama Kishan Malladi (Intel) Hi,*

We don't need you to support multiprecision math.

*Thanks-Rama*

Rama,

See my other post.

Your .PDF rule states:

"For example, output(50.323467) should send 50.3234670000 to the output"

50.323467 happens to NOT be a number that is exactly representable by IEEE 754 double precision. Therefore, the above rule would imply (requier) decimal math. Please comment.

Jim Dempsey

I think you are splitting the hairs a bit fine here. The value given will round-trip (string->double->string) andunderin mostcases provide an accurate decimal representation. When used in an expression that causes the result (or sub-result) to exceed the precision of a double (~16 digits) significant rounding canoccur. No matter what representation is chosen precision loss can occur (or memory can be exceeded). Since almost all real numbers are irrational it's reasonable to assume that rounding is a fact of life. The difference between binary and decimal arithmeticisn't a factor. Granted that any base (other than *e*) is going to accumulate small rounding differences that can lead to differing results. For this application differences due to error accumulation arevery likely to occur(regardless of base) because the handling of the partial products could easily lead to variation over the serial version. For that matter the results of two different serial implementations could vary due to partial product handling.

Jim,

Think about the output function and the example:

output(50.323467)

You receive a string: 50.323467

You convert that string and you store it in a double

variable. The variable will have the following value: 50.323467000000001

You have to convert it back to a string but you have to

truncate it and you will return:

50.3234670000

Thus, you wont return the last 5 characters.

50.3234670000 ##### 00001

If we dont simplify data types, each participant

might chose a wrong data type.Cheers,Gaston

Gastón C. Hillar

I believe this is covered this post: Input clarification

6. We are not looking for IEEE support in the mathematical expressions. Output correctness is required but precision of the output will be relaxed to keep it simple.

Exactly! That's the idea.

Gastón C. Hillar

>>Output correctness is required but precision of the output will be relaxed to keep it simple.

Good.

Gaston,

On the flip side, the double could be down by 1/2 bit too.

You receive a string: 50.323467

You convert that string and you store it in a double variable. The variable will have the following value: 50.323466999999999

You have to convert it back to a string but you have to truncate it and you will return:

50.3234669999

Now the output doesn't match the "should output 50.3234670000"

The rule as stated imply the correct answer is an exact text match rather than a numerical value approximately equal to the result as if calculated to infinite precision. I do not think it unreasonable to ask if approximately equivilent values will be acceptible.

Note, you cannot simply add .00000000005 to the internal double value because the numeric value may have many digits to the left of the ".". And in this case you cannot round up the 1/2 bitundervalued variable.

Jim

www.quickthreadprogramming.com

Quoting jimdempseyatthecove

Gaston,

On the flip side, the double could be down by 1/2 bit too.

You receive a string: 50.323467

You convert that string and you store it in a double variable. The variable will have the following value: 50.323466999999999

You have to convert it back to a string but you have to truncate it and you will return:

50.3234669999

Now the output doesn't match the "should output 50.3234670000"

Pre-round by adding +/- 0.00000000005

Jim and John,There is no need to either pre-round or post-round.The variables have to be represented by a C double, the conversion to string should truncate and add 0s as specified in the problem spec.If you use a different internal representation, you'll have different results. However, we don't want that to happen.We want the interpreter to produce the results without any rounding. Just as the problem spec says.In fact, if you add either pre-round or post-round, you are running unnecessary additional instructions and you'll lose performance.Hope it clarifies.Cheers,Gaston

Gastón C. Hillar

Clearly a straight text comparison of the output cannot be used.If the judges will take these differences into account when comparing output, then there is no issue here, but if the judges are planning to use text comparison to compare results then some smoothing of the output is needed.

double dVal1 = 3.14;

double dVal2 = 3000000.14;

printf("%.10f\n", dVal1);

printf("%.10f\n", dVal2);

Out:

3.1400000000

3000000.1400000001

When Value > 3000000, lack of floating-point precision

写字楼里写字间,写字间里程序员

程序人员写程序,又拿程序换酒钱

酒醒只在网上坐,酒醉还来网下眠

酒醉酒醒日复日,网上网下年复年

程序人员写程序,又拿程序换酒钱

酒醒只在网上坐,酒醉还来网下眠

酒醉酒醒日复日,网上网下年复年