[erlang-patches] [patch] binary to/from integer
Bob Ippolito
bob@REDACTED
Thu Jan 10 23:13:32 CET 2013
The purpose of integer_to_binary still isn't totally obvious from the name
or output type, maybe it's digits, maybe it's the big endian encoding of
that integer (which is closer to the behavior of binary_to_term /
term_to_binary). For the more seasoned Erlang developer, I think they would
expect it to behave like integer_to_string, but what about newer users?
On Thu, Jan 10, 2013 at 2:05 PM, Loïc Hoguin <essen@REDACTED> wrote:
> binary:integer_to_string/1 is hardly intuitive. Especially if you write it
> like this:
>
> Module = binary,
> %% ...
> Module:integer_to_string(123)
>
> Do you get a binary() or a string()?
>
> If you create a function type1_to_type2 it's much better if type1 and
> type2 correspond to actual types.
>
> Wherever you place it I don't think it should be named anything other than
> integer_to_binary. However it should be autoimported, because writing
> integer_to_binary first and then remembering the function doesn't exist is
> what many of us do regularly. We already have the reflex, we only miss the
> call to be available.
>
>
> On 01/10/2013 08:31 PM, Serge Aleynikov wrote:
>
>> Thanks for the explanation! The API naming is a headache indeed.
>>
>> It does make sense to define these functions in the binary module.
>> Though while binary:string_to_integer/1 is intuitive, I think
>> binary:integer_to_string/1 would be a more intuitive name than
>> binary:string_from_integer/1 (this also would be more consistent with
>> binary:{bin,list}_to_{list,**bin}.
>>
>> On 1/10/2013 1:50 PM, Björn-Egil Dahlberg wrote:
>>
>>> On 2013-01-10 18:55, Serge Aleynikov wrote:
>>>
>>>> I was under impression that Lucas would take care of modifications he
>>>> proposed in the thread you quoted. Meanwhile I'll see if I can find
>>>> time to do this.
>>>>
>>> I think the key words were "if it gets prioritized" =)
>>> Granted, we could be more clear on intention. I think in this case we
>>> supposedly had time which drastically changed at some point ..
>>>
>>>
>>>> Do you already have an implementation of binary <-> integer? If not,
>>>> maybe I could look at that one as well when I poke around the BIFs,
>>>> since this is also something very commonly needed.
>>>>
>>> Right, what I did was to take the list conversions to integer and made
>>> it binary comprehensible.
>>>
>>> That was the easy bit.
>>>
>>> However,
>>> Now I have
>>> * erlang:binary_to_integer/1 and
>>> * erlang:integer_to_binary/1
>>> which seems fine. The compiler will auto-import them as well.
>>>
>>> After I did that I began to reconsider this choice. Perhaps it should be
>>>
>>> * binary:to_integer/1 and binary:from_integer/1 instead? Or,
>>> * binary:string_from_integer/1 and binary:string_to_integer/1,
>>> emphasizing that this is a textual representation of integer in binary
>>> format. Then I got a headache.
>>>
>>> The arguments for the first one (current) is:
>>> * list_to_integer has same type of ideas, same type of behavior. Avoids
>>> confusion.
>>> The arguments against the first one,
>>> * Clutters the erlang module with yet more BIF's
>>> * We already have a binary module, let's use it!
>>> * And finally: avoid confusion! Does erlang:integer_to_binary(**102341)
>>> mean <<0,1,143,197>> or <<"102341">> ?
>>>
>>> I'm leaning towards the latter.
>>>
>>> Also, I didn't implement base conversion, so that needs doing. I think
>>> the list conversion is done in Erlang which seems backwards.
>>>
>>> Anyways, the current implementation is at:
>>> https://github.com/psyeugenic/**otp/commits/egil/r16/binary_**to_integer<https://github.com/psyeugenic/otp/commits/egil/r16/binary_to_integer>
>>>
>>> But the real work is taking a position on the API and consider the
>>> different ramifications. I still have that headache ..
>>>
>>> Yet another also, perhaps this implementation isn't the way to go. From
>>> what I remember erlang:binary_to_integer didn't have the speedup I first
>>> envisioned. Ofc, it was faster than doing
>>> binary_to_list(list_to_**integer(X)) but binary_to_integer was on par
>>> with
>>> this list_to_integer .. which seemed a bit off.
>>>
>>> I want to refrain from using strtol directly (I think that
>>> implementation is similar anyways and we still need to handle bignums).
>>>
>>> I think I want to change the current implementation to taking the base
>>> as argument to the BIF and perhaps using arity one function as an erlang
>>> wrapper. (And doing the same for list_to_integer). The arguments against
>>> that is, surely the arity one functions is far more used and it should
>>> be slightly faster to that call directly.
>>>
>>> // Björn-Egil
>>>
>>>
>>>> On 1/10/2013 12:41 PM, Björn-Egil Dahlberg wrote:
>>>>
>>>>> On 2013-01-10 18:08, Serge Aleynikov wrote:
>>>>>
>>>>>> Not quite - in two days my "new float_to_list/2" patch is celebrating
>>>>>> its 2 year anniversary sitting in the awaiting mode. ;-)
>>>>>>
>>>>> Nice =o
>>>>> However, it is not really as you imply. A simple patch that has been
>>>>> ignored for two years =)
>>>>>
>>>>> I checked in Monitor/OTP:
>>>>> * sal/float_to_list_2
>>>>> * status: unassigned
>>>>> * location: limbo (not present in any active backlog)
>>>>> * notes: waiting for response from author (noted by Lukas)
>>>>>
>>>>> Lukas is currently on a mountain somewhere in south america so I can't
>>>>> really ask him about it.
>>>>>
>>>>> As I recall, your patch had some controversy about precision?
>>>>>
>>>>> And the last mail conversation mention something about modifications
>>>>> needed and if we were to do it we had to prioritize it along with
>>>>> already planned work. Needless to say, it hasn't been prioritized.
>>>>>
>>>>> http://erlang.org/pipermail/**erlang-patches/2012-August/**002980.html<http://erlang.org/pipermail/erlang-patches/2012-August/002980.html>
>>>>>
>>>>> Personally trying to find time to get binary (text) <-> integer
>>>>> conversions into the backlog.
>>>>>
>>>>> Being realistic, neither your float conversion nor mine will make it to
>>>>> r16. *sadface*
>>>>>
>>>>>
>>>>> // Björn-Egil
>>>>>
>>>>> On 1/10/2013 10:51 AM, Max Lapshin wrote:
>>>>>>
>>>>>>> Serge, you seems to be a fast way to pull patch into upstream =)
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov <
>>>>>>> serge@REDACTED
>>>>>>> <mailto:serge@REDACTED>> wrote:
>>>>>>>
>>>>>>> That was the fastest acceptance of a patch I ever submitted.
>>>>>>> ;-)
>>>>>>>
>>>>>>> On 1/10/2013 10:03 AM, Fredrik wrote:
>>>>>>> > Hello Serge,
>>>>>>> > Your patch is now in the 'master-pu' branch.
>>>>>>> > Thanks for your contribution!
>>>>>>> >
>>>>>>> > BR Fredrik Gustafsson
>>>>>>> > Erlang OTP Team
>>>>>>> > On 01/10/2013 03:31 PM, Serge Aleynikov wrote:
>>>>>>> >> Added an application:get_env/3 function variant that
>>>>>>> provides a
>>>>>>> default
>>>>>>> >> value for a configuration parameter:
>>>>>>> >>
>>>>>>> >> application:get_env(App, Key, Default) -> Value.
>>>>>>> >>
>>>>>>> >> git fetch git://github.com/saleyn/otp.**git<http://github.com/saleyn/otp.git>
>>>>>>> <http://github.com/saleyn/otp.**git<http://github.com/saleyn/otp.git>>
>>>>>>> get_env
>>>>>>> >>
>>>>>>> >> https://github.com/saleyn/otp/**
>>>>>>> compare/erlang:master...get_**env<https://github.com/saleyn/otp/compare/erlang:master...get_env>
>>>>>>> >>
>>>>>>> https://github.com/saleyn/otp/**compare/erlang:master...get_**
>>>>>>> env.patch<https://github.com/saleyn/otp/compare/erlang:master...get_env.patch>
>>>>>>> >> ______________________________**_________________
>>>>>>> >> erlang-patches mailing list
>>>>>>> >> erlang-patches@REDACTED <mailto:erlang-patches@REDACTED**
>>>>>>> org <erlang-patches@REDACTED>>
>>>>>>> >> http://erlang.org/mailman/**listinfo/erlang-patches<http://erlang.org/mailman/listinfo/erlang-patches>
>>>>>>> >
>>>>>>> ______________________________**_________________
>>>>>>> erlang-patches mailing list
>>>>>>> erlang-patches@REDACTED <mailto:erlang-patches@REDACTED**org<erlang-patches@REDACTED>
>>>>>>> >
>>>>>>> http://erlang.org/mailman/**listinfo/erlang-patches<http://erlang.org/mailman/listinfo/erlang-patches>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________**_________________
>>>>>> erlang-patches mailing list
>>>>>> erlang-patches@REDACTED
>>>>>> http://erlang.org/mailman/**listinfo/erlang-patches<http://erlang.org/mailman/listinfo/erlang-patches>
>>>>>>
>>>>>>
>>>>>> ______________________________**_________________
>>>>> erlang-patches mailing list
>>>>> erlang-patches@REDACTED
>>>>> http://erlang.org/mailman/**listinfo/erlang-patches<http://erlang.org/mailman/listinfo/erlang-patches>
>>>>>
>>>>
>>>>
>>> ______________________________**_________________
>> erlang-patches mailing list
>> erlang-patches@REDACTED
>> http://erlang.org/mailman/**listinfo/erlang-patches<http://erlang.org/mailman/listinfo/erlang-patches>
>>
>>
>
> --
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
>
> ______________________________**_________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-patches<http://erlang.org/mailman/listinfo/erlang-patches>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20130110/5fa4e6d1/attachment.htm>
More information about the erlang-patches
mailing list