| Author |
Message |
|
| demius_md |
 Posted: Wed Aug 09, 2006 10:30 am |
 |
|
|
Joined: 02 Aug 2006
Posts: 1
|
list_to_float("0") exited with badarg
it must work as list_to_float("0.0")
Post recived from mailinglist |
|
|
| Back to top |
 
|
| Guest |
| Posted: Wed Aug 09, 2006 6:03 pm |
|
|
|
Guest
|
Demius Academius wrote:
> list_to_float("0") exited with badarg
> it must work as list_to_float("0.0")
>
you'll have to do something like:
str_to_float(Str) ->
try float(list_to_integer(Str))
catch error:_ -> list_to_float(Str)
end.
or
str_to_float(Str) ->
case string:to_float(Str) of
{error, no_float} ->
{Int, []} = case string:to_integer(Str),
float(Int);
{Float, []} -> Float
end.
as "0" is considered a integer(), while "0.0" is treated as a float().
But I agree that it would be much nicer if list_to_float/1 and
string:to_float/1 would do this by themselves.
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 09, 2006 6:12 pm |
|
|
|
Guest
|
Actually list_to_number would be a good standard library addition. It would
call list_to_integer first, then if that failed, call list_to_float.
-----Original Message-----
From: owner-erlang-bugs@erlang.org [mailto:owner-erlang-bugs@erlang.org] On
Behalf Of H |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 09, 2006 6:33 pm |
|
|
|
Guest
|
As I understand the name "list_to_float" means conversion _to_ float
(not integer!) from _some_ list representation.
The current implementation is limited to string only argument - this is
reasonable, but it's not clear why implementation is limited to narrow
X.X representation? Couldn't float be expressed as "0"?
As to list_to_number idea, what type of result is expected? Depending on
argument text representation?
James Hague wrote:
> Actually list_to_number would be a good standard library addition. It would
> call list_to_integer first, then if that failed, call list_to_float.
>
> -----Original Message-----
> From: owner-erlang-bugs@erlang.org [mailto:owner-erlang-bugs@erlang.org] On
> Behalf Of H |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 09, 2006 6:37 pm |
|
|
|
Guest
|
>The current implementation is limited to string only argument - this is
>reasonable, but it's not clear why implementation is limited to narrow
>X.X representation? Couldn't float be expressed as "0"?
"0" in Erlang means "integer zero." You need to specify "0.0" for a float.
Try these in the shell:
is_integer(0 + 1). % gives true
is_integer(0.0 + 1). % gives false
>As to list_to_number idea, what type of result is expected? Depending on
>argument text representation?
Correct. It's analogous to the is_number function, which checks if a value
is either an integer or float.
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 09, 2006 8:27 pm |
|
|
|
Guest
|
I was just trying to say that I don't see any reason for such limitation
when we're converting from string to float.
James Hague wrote:
>> The current implementation is limited to string only argument - this is
>> reasonable, but it's not clear why implementation is limited to narrow
>> X.X representation? Couldn't float be expressed as "0"?
>
> "0" in Erlang means "integer zero." You need to specify "0.0" for a float.
Depends on context. If you are talking about term syntax (as in an
example below) yes, I agree. If we're considering external text that
should be interpreted (during the IO operations) as an integer or float,
no, I do not agree that there is any reason to limit text representation
when we know what we want to have as the result of conversion.
> Try these in the shell:
>
> is_integer(0 + 1). % gives true
> is_integer(0.0 + 1). % gives false
>
>> As to list_to_number idea, what type of result is expected? Depending on
>> argument text representation?
>
> Correct. It's analogous to the is_number function, which checks if a value
> is either an integer or float.
>
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Aug 10, 2006 9:16 am |
|
|
|
Guest
|
There have been external and internal discussions about this one.
Anyway, the semantics can not be changed now. There must be
lots of written code that relies on an exception from
erlang:list_to_float("0"), since it is not a valid
erlang float - it is an integer.
An erlang:list_to_number/1 might be an useful addition, but
it is easy enough to write for yourself. If such a function
is desired, I can imagine an an erlang:list_to_term/1 also
(instead?) would be. It should do all the erl_scan:string(S),
erl_parse:parse_term(T) that repeatedly pops up on
erlang-questions. Erlang shell example:
1> f(S),S="{tuple}",f(T),{ok,T,_}=erl_scan:string(S++".").
2> f(X),{ok,X}=erl_parse:parse_term(T),X.
{tuple}
But that is a beast that involves erl_scan and erl_parse
functionality into the erlang module itself - mixing
run-time with compile-time. It might fit better into
some other module, the question remains which.
Enough rambling. Here is another fix for your problem:
how_to_float(S) ->
case string:to_float(S++".0") of
{F,_} when is_float(F) -> F;
_ -> erlang:error(badarg, [S]);
end.
Assuming S is known to not be huge. You probably only
need to pick out the best parts of the case statement
(you get the idea, ``string:to_float(S++".0")'' is the trick).
demius_md@mail.ru (Demius Academius) writes:
> list_to_float("0") exited with badarg
> it must work as list_to_float("0.0")
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
