public static int mpf_set_str(
	mpf_t rop,
	char_ptr str,
	int base
)

Public Shared Function mpf_set_str ( 
	rop As mpf_t,
	str As char_ptr,
	base As Integer
) As Integer

public:
static int mpf_set_str(
	mpf_t^ rop, 
	char_ptr str, 
	int base
)

static member mpf_set_str : 
        rop : mpf_t * 
        str : char_ptr * 
        base : int -> int 

Parameters

rop

Type: Math.Gmp.Nativempf_t
The result float.

str

Type: Math.Gmp.Nativechar_ptr
The input string.

base

Type: SystemInt32
The base.

Return Value

The string is of the form "M@N" or, if the base is 10 or less, alternatively "MeN". "M" is the mantissa and "N" is the exponent. The mantissa is always in the specified base. The exponent is either in the specified base or, if base is negative, in decimal. The decimal point expected is taken from the current locale, on systems providing localeconv.

The argument base may be in the ranges 2 to 62, or -62 to -2. Negative values are used to specify that the exponent is in decimal.

For bases up to 36, case is ignored; upper-case and lower-case letters have the same value; for bases 37 to 62, upper-case letter represent the usual 10..35 while lower-case letter represent 36..61.

Unlike the corresponding mpz function, the base will not be determined from the leading characters of the string if base is 0. This is so that numbers like "0.23" are not interpreted as octal.

White space is allowed in the string, and is simply ignored. [This is not really true; white-space is ignored in the beginning of the string and within the mantissa, but not in other places, such as after a minus sign or in the exponent. We are considering changing the definition of this function, making it fail when there is any white-space in the input, since that makes a lot of sense. Please tell us your opinion about this change. Do you really want it to accept "3 14" as meaning 314 as it does now?]

Reference