[erlang-patches] new float_to_list/2

Björn-Egil Dahlberg <>
Tue Jan 22 15:39:56 CET 2013


On 2013-01-22 15:04, Serge Aleynikov wrote:
> So erts_snprintf formats floats slightly differently on windows?
yep
>
> Would you like me I adjust the test cases (there are 6 of them that
> would need to be made less strict) and repush or you can do it on your end?
This is sort of a separate issue.

I'll fix the cases and move on.

// egil
>
> On 1/22/2013 5:37 AM, Björn-Egil Dahlberg wrote:
>> Heh, so this is not your fault =)
>>
>> R15B03 has this behaviour,
>> R13B has this behaviour as well.
>>
>> Your new testcase is too strict.
>>
>> // Björn-Egil
>>
>>
>> On 2013-01-22 11:08, Björn-Egil Dahlberg wrote:
>>> Found an issue not caught in pu due to windows being down because of
>>> other issues in pu on windows.
>>>
>>>
>>> *** User 2013-01-21 22:53:27.711 ***
>>> num_bif_SUITE:t_float_to_list failed on line 126
>>> Reason: {badmatch,"1.00000000000000000000e+000"}
>>>
>>>
>>>
>>>
>>> === Ended at 2013-01-21 22:53:27
>>> === location [{num_bif_SUITE,t_float_to_list,126},
>>>                {test_server,ts_tc,1362},
>>>                {test_server,run_test_case_eval1,979},
>>>                {test_server,run_test_case_eval,928}]
>>> === reason = no match of right hand side value
>>> "1.00000000000000000000e+000"
>>>    in function  num_bif_SUITE:t_float_to_list/1 (num_bif_SUITE.erl,
>>> line 126)
>>>    in call from test_server:ts_tc/3 (test_server.erl, line 1362)
>>>    in call from test_server:run_test_case_eval1/6 (test_server.erl,
>>> line 979)
>>>    in call from test_server:run_test_case_eval/9 (test_server.erl, line
>>> 928)
>>>
>>>
>>>    126:     "1.00000000000000000000e+00"  = float_to_list(1.0), <- this
>>> one
>>>
>>> This is on Windows XP.
>>>
>>> // Björn-Egil
>>>
>>>
>>> On 2013-01-21 15:42, Serge Aleynikov wrote:
>>>> Thanks for expediting this for the upcoming release!
>>>>
>>>> Just to make sure that Lukas suggestion doesn't go unnoticed - the only
>>>> remaining point not included in the patch (that can be addressed in a
>>>> later release) is taking advantage of the float formatting speedup in
>>>> erts/lib_src/common/erl_printf_format.c suggested by Lukas, which I
>>>> addressed in the attached email earlier in this thread.
>>>>
>>>> On 1/21/2013 9:30 AM, Björn-Egil Dahlberg wrote:
>>>>> Great, I'll fetch and put into master-opu.
>>>>>
>>>>> Hopefully we have found all issues. *crossing fingers*
>>>>>> For your convenience I repushed the change with this fix, that
>>>>>> affected:
>>>>>>
>>>>>> bif.c
>>>>>> erlang.xml (documented reference to badarg instead of internal_error)
>>>>>> num_bif_SUITE.erl
>>>>>> Commit message
>>>>>>
>>>>>> Serge
>>>>>>
>>>>>> On 1/21/2013 9:14 AM, Björn-Egil Dahlberg wrote:
>>>>>>> Ok, so regarding internal_error.
>>>>>>>
>>>>>>> It is clearly specially handled in the vm, and in the debug vm an
>>>>>>> asserts checks for it *not* to be set, i.e.:
>>>>>>>
>>>>>>> Eshell V5.10  (abort with ^G)
>>>>>>> 1> erlang:float_to_list(1.0e300,  [{decimals, 1}]).
>>>>>>> Assertion failed: Value != am_internal_error in beam/beam_emu.c, line
>>>>>>> 5317
>>>>>>> Aborted (core dumped)
>>>>>>>
>>>>>>>
>>>>>>> I asked Björn and Patrik since they have been here the longest:
>>>>>>> - "How is exception internal_error handled, and what is special about
>>>>>>> it?"
>>>>>>> - "The what now?"
>>>>>>>
>>>>>>> Anyhow,
>>>>>>> EXC_INTERNAL_ERROR is defined by ((2 << 8) | EXC_ERROR | EXF_PANIC)
>>>>>>> where EXF_PANIC means uncatchable.
>>>>>>>
>>>>>>> My take on it is, it is literally meant to be an internal error and
>>>>>>> should not be recovered from. Thus those test cases will result in
>>>>>>> cores
>>>>>>> in debug builds. Not great. More importantly, we can trigger this
>>>>>>> from
>>>>>>> bad input.
>>>>>>>
>>>>>>> I'm sorry, but I have revert my previous statement and return BADARG
>>>>>>> instead.
>>>>>>>
>>>>>>> I'll update the code and put it in master-opu.
>>>>>>>
>>>>>>> // egil
>>>>>>>
>>>>>>> On 2013-01-21 04:17, Serge Aleynikov wrote:
>>>>>>>> On 1/19/2013 8:40 PM, Björn-Egil Dahlberg wrote:> I don't think the
>>>>>>>> 'compact' option is doing what is says. See the following:
>>>>>>>>> 25> erlang:float_to_list(7/3, [{decimals, 6}, compact]).
>>>>>>>>> "2.3333"
>>>>>>>>> 26> erlang:float_to_list(7/3, [{decimals, 6}]).
>>>>>>>>> "2.333333"
>>>>>>>>>
>>>>>>>> Egil,
>>>>>>>>
>>>>>>>> I repushed the fix for this issue along with your recommendation to
>>>>>>>> limit the range of Decimals.  The only thing - the valid range is
>>>>>>>> not
>>>>>>>> 0..255, but 0..249, since we need to keep in mind that a properly
>>>>>>>> formatted number includes "X." (minimally one digit before the
>>>>>>>> decimal
>>>>>>>> point) and "e+YY" (in case of scientific notation).
>>>>>>>>
>>>>>>>> We still could get internal_error, when the number is too large
>>>>>>>> irrespective of the number of decimals:
>>>>>>>>
>>>>>>>>         float_to_list(1.0e+300, [{decimals, 1}]).
>>>>>>>>
>>>>>>>> Here the number doesn't fit in the buffer irrespective of the tail
>>>>>>>> after
>>>>>>>> the decimal point.  This brings me back to the question you raised
>>>>>>>> earlier in the thread if 256 is indeed a good default for the buffer
>>>>>>>> size or it needs to be increased.  I still think it's good as
>>>>>>>> when one
>>>>>>>> deals with formatting such large numbers, he should use scientific
>>>>>>>> notation, so float_to_list(1.0e+300, [{scientific, 1}]) would do
>>>>>>>> just
>>>>>>>> fine.
>>>>>>>>
>>>>>>>> Added appropriate test cases.
>>>>>>>>
>>>>>>>> While trying one test case, there's a weird issue that I don't
>>>>>>>> understand (or maybe it's too late now and I am failing to see
>>>>>>>> something
>>>>>>>> silly).  Why am I not able to catch the internal_error exception?
>>>>>>>>
>>>>>>>> This is expected:
>>>>>>>> 7> (catch float_to_list(1.0,  [{decimals, 250}])).
>>>>>>>> {'EXIT',{badarg,[{erlang,float_to_list,
>>>>>>>>                              [1.0,[{decimals,250}]],
>>>>>>>>                              []},
>>>>>>>>                      ...}
>>>>>>>>
>>>>>>>> This is not expected. I should see the same
>>>>>>>> {'EXIT', {internal_error, _}} result, no?
>>>>>>>>
>>>>>>>> 8> (catch float_to_list(1.0e300,  [{decimals, 1}])).
>>>>>>>>
>>>>>>>> =ERROR REPORT==== 20-Jan-2013::22:01:26 ===
>>>>>>>> Error in process <0.40.0> with exit value:
>>>>>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,expr,5,[{file,"erl_eval.erl"},{line,352}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ** exception exit: internal_error
>>>>>>>>          in function  float_to_list/2
>>>>>>>>             called as float_to_list(1.0e300,[{decimals,1}])
>>>>>>>>
>>>>>>>> This doesn't catch the exception either:
>>>>>>>>
>>>>>>>> 9> try float_to_list(1.0e300,  [{decimals, 1}]) catch _:W -> W end.
>>>>>>>>
>>>>>>>> =ERROR REPORT==== 20-Jan-2013::22:02:19 ===
>>>>>>>> Error in process <0.45.0> with exit value:
>>>>>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,try_clauses,8,[{file,"erl_eval.erl"},{line,759}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ** exception exit: internal_error
>>>>>>>>          in function  float_to_list/2
>>>>>>>>             called as float_to_list(1.0e300,[{decimals,1}])
>>>>>>>>
>>>>>>>> Any idea why?  Is there something special about internal_error?  I
>>>>>>>> wanted a simple test case, but it fails due to uncaught exception:
>>>>>>>>
>>>>>>>> {'EXIT', {internal_error, _}} = (catch float_to_list(1.0e+300,
>>>>>>>> [{decimals, 1}]))
>>>>>>>>
>>>>>>>> Serge
>>> _______________________________________________
>>> erlang-patches mailing list
>>> 
>>> http://erlang.org/mailman/listinfo/erlang-patches
>>>
>>>
>> _______________________________________________
>> erlang-patches mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-patches
>



More information about the erlang-patches mailing list