Re: [Boost-users] [serialization]

From: David Abrahams (dave_at_[hidden])
Date: 2005-11-11 14:09:20

"Robert Ramey" <ramey_at_[hidden]> writes:

> David Abrahams wrote:
>
>>>
>>> * when booleans are output, booleans are converted to integers and
>>> an assertion is thrown if the resulting value is other than zero or
>>> one.
>>
>> What do you mean, "an assertion is thrown?"  Only exceptions can be
>> thrown.
>
> I mean the assert macro is passed a value of false
>
>>> This is in line with my view of trapping a program as soon as
>>> possible
>>> when any kind of programmign error has been detected.
>>
>> Some kinds of programming errors aren't worth trying to detect.
>> Passing uninitialized data is fundamental brokenness, and looking for
>> it with only in bools is rather silly.
>
> Hmm - here I have a situation where I can trap an error commited
> when an archive is saved that would not otherwise be detected until
> the archive is loaded.  The fact I can't trap it for all data types doesn't
> mean one should pass the opportunity up for bools.  Since its an
> assert, it will have no detrimental effect on runtime of release
> build code.  What is the downside of doing this?

Not much:

  - it's something you have to maintain
  - it may lead users into a false sense of security.

>>  it would be an unfortunate choice.  Non-signalling NaNs should be 
>> serializable.
>
> Hmm - that sounds like a matter of opinion to me.

I guess if you hold the opposite opinion it's a matter of opinion.
Nonetheless, it's true.  NaNs are not just invalid numbers.  They can
be used intentionally (we had to represent "no data" in a time series
for one client, and NaNs worked like a charm for that purpose), and
they are meaningful results of some floating calculations.

>>> This would be a good thing from my standpoint as up until now a NaN
>>> could be saved but not recovered as the standard text stream input
>>> chokes on the Nan Text.
>>
>> Seems like you should work around that problem.
>
> If it indeed it is a problem.

I don't know what to say.  If I, as a client of your library, say the
lack of this functionality would represent a problem for me, and you
doubt the truth of it, it seems the discussion is over.

>>> Meanwhile the binary input just loads the bits whatever they were.
>>> This conclicts with my goal of making all archives behave alike.
>
>> ...
>
>>> I'm concerned that someone standup and show "But NaN is a valid value
>>> for a float or double and I should be able to serialize that!!!".
>>
>> Damn straight.
>
>>> I'm inclined to reject this characterisation basically because doing
>>> so will make my life easier.  This will trap some user's errors at
>>> the cost of prohibiting some behavior that could be defended as
>>> correct.
>
> What I'm curious about is what is the utility of serializing a NaN?
> Why would someone want to do this? 

So that when they deserialize, they get the same data back that they
started with.  It seems pretty obvious to me.

> What does it usually mean?

It could mean a variety of things, including that someone divided zero
by zero.

> The only thing that occurs to me is that it would be uninitialized
> data.

It's *highly* unlikely that any given random sequence of bits will
turn out to be a valid NaN.

> If NaN has been overloaded with some sort of meaning like
> "undetermined value" or something like that 

Overloaded?  What do you mean by that?

> I would think its a questionable and error prone practice.  

What is a questionable and error prone practice?

> If that's the case, I don't see its a bad thing if the libray fails
> to support it.

This seems to be an area in which you have little or no experience.
It seems as though because you don't really understand NaNs, you're
loathe to support them.  Why not trust the people that actually know
how NaNs work and can be used instead?

> So far only one user has raised the issue of having serialized a NaN
> and having it trap on reading back the archive.  I don't read a whole
> lot into this as this would only occur in text and xml archives and
> perhaps others who do this are using binary archives.  But it does
> suggest that this isn't a huge issue for people actually using the
> library.

Maybe that's because people in the numerics community, who use NaNs,
have other needs not addressed by the library that make rapid adoption
unlikely.

>> I find it very distressing that you keep dismissing the needs of the
>> numerics community.
>
> I have not done this. And I resent the accusation that I have.

Your responses to Matthias about fast array serialization certainly
gave me the impression that you're brushing off valid arguments in a
very cavalier manner.  Further, IIRC, you ignored his last question:

  Shall the serialization library documentation encourage the
  implementors of those functions to make use of array serialization
  features when available, or not?

>> This is likely to lead to something very distasteful, like a
>> semi-official branch of the serialization library that works the
>> way we need it to.
>
> Hmm - I can't imagine why anyone would want to do that.  Someone
> might want to make thier own derivation(s) of one or more archive
> classes or even a whole new archive class - but that doesn't
> represent any conflict with the current library.

We are working on a library for parallel computing that uses the
serialization library to ship data via MPI.  If you reject the
proposed integration of fast array serialization into the library, we
will need to encourage 3rd-party authors of serialization for types
containing arrays to use some non-standard fast mechanism, or clients
of our library will complain to us that performance with these
3rd-party types is unacceptable, and there will be no clean way to fix
them after the fact.  Every way we can think of to accomplish that
eventually leads to something that feels like "hijacking" the library.
We _really_ don't want to do that.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com