[erlang-patches] [patch] binary to/from integer
Serge Aleynikov
serge@REDACTED
Thu Jan 10 23:32:25 CET 2013
This is exactly what Björn-Egil was talking about below ("Does
erlang:integer_to_binary(102341) mean <<0,1,143,197>> or <<"102341">>").
I can think of two other alternatives:
binary:integer_to_binstring/1 & binary:binstring_to_integer/1
binary:integer_to_text/1 & binary:text_to_integer/1
On 1/10/2013 5:13 PM, Bob Ippolito wrote:
> 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
> <mailto: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>
> <mailto: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>
> <mailto:erlang-patches@REDACTED
> <mailto: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>
> <mailto:erlang-patches@REDACTED
> <mailto: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>
> 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>
> 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>
> 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 <mailto:erlang-patches@REDACTED>
> http://erlang.org/mailman/__listinfo/erlang-patches
> <http://erlang.org/mailman/listinfo/erlang-patches>
>
>
More information about the erlang-patches
mailing list