[erlang-patches] [patch] binary to/from integer (was: Added application:get_env/3)

Björn-Egil Dahlberg <>
Thu Jan 10 19:50:47 CET 2013


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

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
>>
>> 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 <
>>>> <mailto:>> 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> get_env
>>>>       >>
>>>>       >> https://github.com/saleyn/otp/compare/erlang:master...get_env
>>>>       >>
>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.patch
>>>>       >> _______________________________________________
>>>>       >> erlang-patches mailing list
>>>>       >>  <mailto:>
>>>>       >> http://erlang.org/mailman/listinfo/erlang-patches
>>>>       >
>>>>       _______________________________________________
>>>>       erlang-patches mailing list
>>>>        <mailto:>
>>>>       http://erlang.org/mailman/listinfo/erlang-patches
>>>>
>>>>
>>> _______________________________________________
>>> 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