Double-> String and String -> Double

Hello,

i talked also with Mr Georg Heeg ( responsibly for Cincom support in Germany ).

The best way would be a binary socket. But a binary socket needs to much implementation time.
I am looking for a simple solution.
One solution would be to send the two party of the double ( in german: exponent and mantisse ) seperate as integer over socket.

An idea of Mr Heeg was following:

Sender:
Point-Collection ( Double-points) --TO--> bytearray --TO--> ashexprintstring -->>> Socket

Receiver:
Socket-->>> asHexprintstring  --TO--> bytearray   --TO--> point collection of doubles


Mit freundlichen Grüßen - best regards,

Peter Dziedzic

--------------------------------------

Carl Zeiss Industrielle Meßtechnik GmbH/ Industrial Metrology
Softwareentwicklung/Software Development

P e t e r  D z i e d z i c

73446 Oberkochen, Germany

tel: +49 73 64 20-84 48
fax: +49 73 64 20-48 00
e-mail: [hidden email]
http://www.zeiss.de/imt

Carl Zeiss Industrielle Messtechnik GmbH
Carl-Zeiss-Straße 22, 73447 Oberkochen
Aufsichtsratsvorsitzender: Dr. Dieter Kurz
Geschäftsführer: Dr. Rainer Ohnheiser, Felix Hoben, Hanspeter Mürle
Sitz der Gesellschaft: 73446 Oberkochen, Deutschland
Amtsgericht Ulm, HRB 501561, USt-IdNr.: DE 811 515 346

Jan Weerts <j.weerts <at> i-views.de> writes:

>
> Hi Peter!
>
> Dziedzic, Peter wrote:
> > i make some tests with socket.
> > I want to send a large amount of points over the socket.
> > But i have the problem that it needs to much time.
> >
> > Are there faster methods than asDouble to convert a point ( x asDouble, y
> > asDouble and z asDouble ) to a string.
> >
> > Are there faster methods than printStringWithoutExponent or
> > asStringWithDigets: 10 for converting a string to a double.
>
> Depending on the receiving end, you can also write binary data to that
> socket. If the receiver depends on string representations I would use
> the TimeProfiler to identify the problematik portions of the data
> writing. It might be possible, that chunking your data could improve
> throughput, but maybe the mentioned methods just need some optimizing.
> In my experience, network I/O is more often the problem, than
> stringifying some simple float.
>
> Regards
>    Jan
>

Agree, I would serialize/deserialize binary data in a ByteArray taking care of
machine endianness (in the spirit of htons() ntohs() for example).
A double is just 8 bytes long, String representation could be more ((1/3)
asDouble printString size).

Also, be aware that both #asString and #asDouble generally causes round-off
errors and that the double won't be bit-identical at both socket ends.
Maybe you don't care, but for example testing inclusion in a polygon might lead
to different results, whatever the tolerance used.

In binary mode,
- you economize conversion costs,
- you economize transmission costs (binary being more compact),
- you have an exact bitwise replication

Nicolas

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



----------------------------------------
This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted.