A question about floating number

[YuanWangC]

When I execute the testcase below, chakra gives a different output which is not the same as other engines (like V8, spiderMonkey,javascriptCore). I wonder if chakra has any special ways to deal with floating numbers.

version

eaaf7ac

testcase

var NISLFuzzingFunc = function(){
    print(32.963645576628462);
};
NISLFuzzingFunc();

output

32.963645576628465

expected output

32.963645576628466

[rhuanjl]

This is due to the algorithm used for converting a floating point number to a string.

Last time I looked at this the specifics of the algorithm were not specified and so CC's behaviour was not violating spec.

The other 3 engines all use forks of the same library (which can be seen here: https://github.com/google/double-conversion) for handling this conversion and hence get the same result.

There is prior discussion in issue #149

There was a possible quick fix to bring the behaviour in line but it had a significant performance cost so was rejected. To bring the behaviour inline without the performance cost would involve either using that library I've linked above OR some more extensive work to significantly re-write the algorithm currently used.

[rhuanjl]

Closing as duplicate as #149

[YiWen-y]

Version:

chakra-1.11.8

Testcase:

var NISLFuzzingFunc =function (nislMutationParameter0){
    print(Math.pow(nislMutationParameter0,1/3));
};
var nislMutationArgument0=52356; 
NISLFuzzingFunc(nislMutationArgument0); 

Command:

./ChakraCore/out/Debug/ch testcase.js

Output:

37.41009574268063

Expected output:

37.41009574268064

Description:

I manually calculated 52356^(1/3) and the result is 37.410095742680642522405335528085...‬, but the output of the engine is 37.41009574268063. What is the reason for this?

[rhuanjl]

It is to do with the process for converting from a floating point number to a string you can actually display.

A float is stored internally as described here: https://en.wikipedia.org/wiki/Double-precision_floating-point_format

The method for doing this conversion is not simple AND can never be completely exact. The question is how precise can you manage - being out by 1 on the 16th decimal place is good enough for the majority of uses - though as above it would be good to update to be in sync with the other engines, which is what issue #149 is about.

NOTE - as this is only a conversion for output question - if you do further sums on the number within JS it is is not being truncated or rounded incorrectly until the moment you display it which is why this is not a major issue.