phpxmlrpc-devel

Re: R: [phpxmlrpc-devel] is this list working?

[lukasz m. <lu...@ma...>]

Gaetano Giunta wrote:
>>so i'm wondering if those mail successfull arrived to list.
>>
> 
> 
> yes, it deed

	funny, when i asked this question, suddenly both mails 
(last and those about floats) appeared on sourceforge.
maybe there is some kind of buffer, which have to be 
overflowed to appear message on board?

> 
> 
>>had anybody read mail about float/double numbers encoding?
>>
> 
> 
> I am in no way a major developer of the lib, here's my take anyway:
> 
> 
>>there is a problem with very big(or very small) float 
>>numbers. php automagically converts it to scientific number
>>for example
>>	1300000000000000000000 to 1.3e21
>>
>>xmlrpc server accepts it as valid double value, but xmlrpc 
>>client "converts" it to ERROR_NON_NUMERIC_FOUND, because it 
>>doesn't match to "^[0-9\+\-\.]+$" regexp.
>>	i see 2 solutions:
>>1) let php server accept scientific format, and replace 
>>regexp based check by is_float(). but xmlrpc specification 
>>is unclear for me, and i'm not sure if it allow scientific 
>>format of double number.
>>
> 
> 
> The spec is deceptively simple in many places, here's the concerning paragraph:
> 
>   # What is the legal syntax (and range) for floating point values (doubles)? How is the exponent represented? How to deal with whitespace?  Can infinity and "not a number" be represented?
> 
>   There is no representation for infinity or negative infinity or "not a number". At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified.
> 
> As far as my understanding goes, NO scientific notation allowed.

	it isn't forbidden explicit. but it looks like you're right.

[ciach]
> 
>>2) convert every big or small double to normal format using 
>>sprintf and proper precision modifier. but it can generate 
>>amount of unneeded data (1.3e55 takes 6 bytes, 13000....0000 
>>takes 56 bytes).
>>
> 
> 
> A very large amount of data indeed, but it is the only way to go!

and problem is, how to code VERY BIG float to non-scientific 
format. simply sprintf(%f,$number) seems to be not working 
properly.

printf("%f",1.3e200) produces 
1299999999999997700000000000000000000000000000000000000000000000000000000000000.00000000
which is near 1.3e78.

1.3e200 should by inside double range.


so maybe we should consider allow to use scientific format?

regards

maHo

Re: R: [phpxmlrpc-devel] is this list working?

[Ryan H. <rh...@is...>]

lukasz mach wrote:

> Gaetano Giunta wrote:
>
>> A very large amount of data indeed, but it is the only way to go!
>
> and problem is, how to code VERY BIG float to non-scientific format. 
> simply sprintf(%f,$number) seems to be not working properly.
>
> printf("%f",1.3e200) produces 
> 1299999999999997700000000000000000000000000000000000000000000000000000000000000.00000000 
>
> which is near 1.3e78.
>
> 1.3e200 should by inside double range.
>
> so maybe we should consider allow to use scientific format?

 From an interoperability standpoint, this seems wrong.  I would suggest 
handling scientific notation at the application layer instead of the RPC 
layer.  Use a string and do validation within your app.

--
Ryan Hoegg
Contributor, Apache XML-RPC project

R: R: [phpxmlrpc-devel] is this list working?

[Gaetano G. <giu...@se...>]

...
>=20
> and problem is, how to code VERY BIG float to non-scientific=20
> format. simply sprintf(%f,$number) seems to be not working=20
> properly.
>=20
> printf("%f",1.3e200) produces=20
> 12999999999999977000000000000000000000000000000000000000000000
> 00000000000000000.00000000
> which is near 1.3e78.
>=20
> 1.3e200 should by inside double range.
>

max float =3D	+3.4028235e38
max double =3D  +1.7976931348623157e308
[I found these values somewhere on the net other than the C(glibc?) =
spec, so I'm not too confident:]

>=20
> so maybe we should consider allow to use scientific format?
>=20

Another option would be to simply encode/decode the scientific-formatted =
values as strings, and do the conversion inside the application.
If you're developing a private app there's no problem, since you build =
both client & server.
If you are developing a server open to public usage it might not look =
very 'clean', but then you're better off sticking to the protocol as =
much as you can anyway ...

regards,
Gaetano

Re: R: R: [phpxmlrpc-devel] is this list working?

[lukasz m. <lu...@ma...>]

Gaetano Giunta wrote:
[ciach]

> Another option would be to simply encode/decode the scientific-formatted values as strings, and do the conversion inside the application.
> If you're developing a private app there's no problem, since you build both client & server.

	i'm developing private app, but i do recognize by type, an 
another action is taken for string, and another for double.
	i think i must use something like
<struct>
<member><name>type</name><value>scientific</value></member>
<member><name>value</name><value>1.3e200</value></member>
</struct>

instead of <double>1.3e200</double>

sad. all simplicity goes to hell.....

> If you are developing a server open to public usage it might not look very 'clean', but then you're better off sticking to the protocol as much as you can anyway ...
yes, you're right.
another option: influence xmlrpc spec to allow scientific 
format. but how, i don't know yet.


regards

maHo

R: R: R: [phpxmlrpc-devel] is this list working?

[Gaetano G. <giu...@se...>]

[SNIP]

>=20
> > If you are developing a server open to public usage it=20
> > might not look very 'clean', but then you're better off=20
> > sticking to the protocol as much as you can anyway ...
> > yes, you're right.

> another option: influence xmlrpc spec to allow scientific=20
> format. but how, i don't know yet.
>=20

Sorry, but this is not an option.
If you dig a bit in the xml-rpc mailing list, then you'll see that Dave =
Winer (spec author and copyright holder of the name) has a fairly =
precise opinion on it: xml-rpc is 'cast in stone'. He won't even allow =
changes in the wording of the spec that would clarify =
long-(long)-standing issues (such as: is ISO-DATETIME meant to be a full =
ISO confomant representation or is the only valid format for dates the =
one specified in the example? etc...).
Some people even started out their own 'improved' version of the =
protocol (e.g. xml-rpc over e-mail), but I dunno if those dialects are =
still growing or plain dead.