in reply to how to convert fractional string to decimal numbers ?

No need for any risky sort of eval in this particular case -- use a regex to "untaint" the string:
my $fractionString = "1/2"; my $fractionValue = ( $fractionString =~ m{^(\d+)/([1-9]\d*)} ) ? $1/$ +2 : "undefined"; print "$fractionString is actually $fractionValue <br>";
You could even reduce that to an in-place substition that would leave non-valid "fraction" strings unchanged:
$fractionString =~ s{(\d+)/([1-9]\d*)}{$1/$2}e;

(update: In view of the (seemingly picky but admittedly valid) concerns expressed below by tilly, I should point out up front that my suggestions here are extrapolating from the particular case given in the OP, to extend to all and only positive fraction strings. If you want to handle negatives or other embellishments, further work is needed. Other solutions are possible that do not extrapolate, or that make different extrapolations, YMMV, etc, and good luck with all that. ;-)

Replies are listed 'Best First'.
Re^2: how to convert fractional string to decimal numbers ?
by tilly (Archbishop) on Dec 17, 2008 at 06:41 UTC
    Apparently -1/2 is undefined.
      Absolutely! Because it doesn't match the particular case given in the OP -- whereas things like "2/3", "234/567", etc, do match that case.

      Another example that won't match that particular case is something like "3-1/2", which I've seen used fairly often to convey the notion of "3.5" rather than "2.5"; things like this can be accommodated, of course, but you really need to be clear about what the conventions are for a given input source (and take the trouble to enforce these conventions by rejecting violations).

        Um, the string "2/3" no more matches the op's stated case than "-1/2" does. If you really only want to match the given case you could just test for string equality with "1/2" and return 0.5 or "undefined". Anything else is a generalization. It is a fallacy to say that one thing matches the particular case while another doesn't because it fits your first approach. And taking such assumptions and running with them is a sure way to wind up miscommunicating.

        We agree that you need to generalize somehow, and errors should be explicit. But I think that you stopped with too limited a generalization, and I would have liked to see the limits of your approach stated up front.