Implement printing in the specified radix for Number.prototype.toString().

[dbatyai]

Depends on #100.

JerryScript-DCO-1.0-Signed-off-by: Dániel Bátyai [email protected]

[egavrin]

/home/jenk/.jenkins/jobs/GitHubAuto/workspace/jerry-core/ecma/builtin-objects/ecma-builtin-number-prototype.cpp: In function ‘ecma_completion_value_t ecma_builtin_number_prototype_object_to_string(ecma_value_t, const ecma_value_t*, ecma_length_t)’:
/home/jenk/.jenkins/jobs/GitHubAuto/workspace/jerry-core/ecma/builtin-objects/ecma-builtin-number-prototype.cpp:150:78: error: ‘ecma_number_calc_params’ was not declared in this scope
     ecma_number_calc_params (this_arg_number, &digits, &num_digits, &exponent);
                                                                              ^
compilation terminated due to -Wfatal-errors.
jerry-core/CMakeFiles/debug.jerry-core.dir/build.make:1296: recipe for target 'jerry-core/CMakeFiles/debug.jerry-core.dir/ecma/builtin-objects/ecma-builtin-number-prototype.cpp.o' failed

[dbatyai]

@egavrin,
Indeed, since this patch depends on #100, that will introduce this function.
When that patch lands, I'll rebase this one, and precommit will pass.

Until then, please take a look at the code.

[egavrin]

str_p

[egavrin]

Please rebase to master

[dbatyai]

I've rebased to master.

Also, I'd like to ask your opinion on the buffer. Currently it's set to a fixed 1080 size, since this is the largest we would ever need. Of course, it would be better to use a dynamic buffer, but I don't know if it would be worthwhile to implement something like that only for this function. We could also try to use a smaller buffer and limit the string size. What do you think?

[ruben-ayrapetyan]

@dbatyai, MEM_DEFINE_LOCAL_ARRAY, currently, provides a way to create dynamic buffer.

[dbatyai]

@ruben-ayrapetyan, could you please explain how exactly? The way I see it, MEM_DEFINE_LOCAL_ARRAY allocates a fix sized block, or am I missing something?

[ruben-ayrapetyan]

@dbatyai, I see. You mean dynamically extensible buffer, but MEM_DEFINE_LOCAL_ARRAY allocates fixed-sized buffer with length, unknown at compile time.

Could we somehow calculate the number of digits prior to buffer allocation, maybe using log? In the case, we could use the MEM_DEFINE_LOCAL_ARRAY.

[dbatyai]

@ruben-ayrapetyan, Unfortunately we can't calculate the number of digits, because some finite fractions can become infinite when we convert them to a different radix.

[ruben-ayrapetyan]

@dbatyai, yes, but in the case we anyway would truncate them to some finite number of digits. So, in the case, number of digits in output buffer is known, isn't it?

[dbatyai]

@ruben-ayrapetyan, you're right, I'll calculate a buffer size with log then.

[dbatyai]

@ruben-ayrapetyan, I've tried to get buffer size with log, but unfortunately it can only be used to calculate digit count for whole numbers, and not for fractions. Any other ideas?

[ruben-ayrapetyan]

@ruben-ayrapetyan, I've tried to get buffer size with log, but unfortunately it can only be used to calculate digit count for whole numbers, and not for fractions. Any other ideas?

Can't digits number of fraction part be calculated from scale?

[dbatyai]

@ruben-ayrapetyan , scale only tells us how many zeros are there between the radix point and the first non-zero digit. This can be used to get a rough estimate, but has no real connection to the actual digit count.

[zherczeg]

It would be good to add some automated test, which runs through the 2 digit numbers for all 36 radix.

[egavrin]

+1

[dbatyai]

Continued here: #306