Re: ideal interface for Random Number Generators?
On Jun 11, 7:17 pm, orz <cdh...@gmail.com> wrote:
Maybe, but why do you want to do this? Have you shown that text has
inherent inefficiencies that produce significant bottlenecks for your
application? For the design goals of TR1 and C++0x, text is sufficient
and simple.
Text does have major bottlenecks for both state size and runtime
speed.
Non-answer. Again: have you shown that text has inherent
inefficiencies that produce significant bottlenecks for your
application? Hint: you need to establish that text is
significantly slower than your unspecified binary approach,
then analyze how often your program has to do this and
compare that with how often it does other things. One good
tool for this is a profiler.
On the rare occasions when you wouldn't otherwise be
linked with string handling code it also forces that.
Shrug. On the rare occasions when you wouldn't otherwise be
linked with the code for handling your presently unspecified
binary protocol it also forces that.
I do not know why you are acting as if text serialization and
binary serialization+deserialization are of similar
complexity. Text representation involves converting to/from
base 10, packing only 3 and a fraction bits in to each 8 bits,
a variable length format, and either scientific notation or
otherwise depending upon the magnitude of the number.
Binary may or may not have many of the same problems. The big
advantage is 1) a fixed length format, so you don't need
separators (although this isn't true for all binary, and of
course, in many cases, a binary variable length format will
result in smaller files than either text or fixed length
binary), and 2) the fact that all of the multiplication/division
is by 256, which on most modern machines, a good compiler will
handle by using byte addressing, with no multiplication or
division whatsoever.
Another frequent advantage is that the format is much more
rigorously specified---any given value has exactly one format,
rather than "10.", "1e1", etc.
The natural binary representation for integers would simply be
the normal integer binary representation in whatever
endianness you considered to have the most moral weight,
Which leaves open the question of representation of negative
values.
and the normal FP representation would be that representation
defined in IEEE 754, once again in whatever endianness you
consider to have the most moral weight.
Which is fine if (and only if) you can limit your portability to
machines which use IEEE 754. Which excludes pretty much all
mainframes.
Can you *really* argue that variable-length low-density multi-
format representations are of comparable complexity to integer
representations that require, at most, swapping byte orders,
or FP representations that involve, in a worst-case non-IEEE
compliant setting, a couple of bitwise operations and either
knowledge of the local FP format or calls to frexp and ldexp.
For output, there's really not a significant difference in
complexity. For input, the problem is that text generally
allows many different representations for the same format. For
both, however, text requires separators (unless you're using
fixed with formats, but in that case, the C++ conversions aren't
that easy to use), which binary doesn't.
--
James Kanze