Re: [Boost-users] [serialization]

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-11-10 23:54:30

Ian McCulloch wrote:
> Robert Ramey wrote:
>> 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?

> I don't really have an opinion here, but why is it the job of the
> serialization library to attempt to detect completely unrelated
> programmer errors?

Every time someone has a problem of this nature, they ask me.  So
naturally I have a lot of incentive to see that these things are trapped
before they get to me.  So for me personally, there is an upside.
The question remains - What is the downside of doing this?

>> What I'm curious about is what is the utility of serializing a NaN?
>> Why would someone want to do this? What does it usually mean?
>> The only thing that occurs to me is that it would be uninitialized
>> data. If NaN has been overloaded with some sort of meaning like
>> "undetermined value" or something like that I would think its 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.
>
> NaN, +/- inf, +/- zero should all be serializable.  NaN arises in
> arithmetic operations in numerous places, 0/0, inf/inf, sqrt(-1.0),
> and so on.  Inf is perhaps more common, and more useful (some
> operations on inf return normal numbers, eg exp(-inf) == 0.0).  This
> allow you to avoid inserting checks everywhere for invalid values,
> instead you just let the NaN/inf propogate through the calculation.
> Although I think it is quite rare to design floating point code to
> handle NaN, a few algorithms make use of inf (some of LAPACK, for
> example).

Your reference below - http://lists.boost.org/boost-users/2005/01/9359.php -
touches upon this subject in an interesting way. "This [NaN problem] seems
to be a result  of relying on the, AFAIK, undefined behavior of writing 
NaN/infinity
to a stream; it will work correctly with some standard library 
implementations,
but not all."  I don't know what the standard says about writing/reading
a NaN or +/-inf to a stream and reading it back.  Also what do most i/o
stream implementations do?  Certainly, the users that have had the
problem aren't using stream libraries which support this behavior.  Then
the question arises, if it isn't important enough for the common stream
library implementations to support it, why should we invest effort in it.  I 
would
guess that the the reason the problem has come up so infrequently is
that users don't need to save/load these types of values very often or its 
easy
to work around.  Otheriwise the standard stream library would have addressed
this stuff long ago - and of course we wouldn't be discussing the issue now.

>> 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.
>
> That isn't true; see below

Sorry two users - one in thread july 2004 and the most recent one Jan 2005

>>> 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.
>
> The issue with NaN/inf has come up before:
> http://lists.boost.org/Archives/boost/2004/07/67259.php
> http://lists.boost.org/boost-users/2005/01/9359.php
>
> Well over a year later, and no progress?

LOL - what have YOU accomplished in the last year?

> Not to mention fast array serialization, for which Matthias Troyer
> has, to my mind, presented convincing arguments that it should be
> part of the core functionality.

He's wrong about this.  There is no advantage to including it in the place
he wants to.  Everything he want's to achieve can be obtained without 
mucking about
in the library itself which is already large and complex enough.  The final
result would be less tightly coupled, more reliable, optional for users who
don't need it, more easily testable and demonstrably correct.

>>> 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.
>>
>
> I have heard mumblings to that effect.
>
>> Hmm - I can't imagine why anyone would want to do that.
>
> and THAT, I think, is the crux of the problem.

OK, let me rephrase that.  There would be no advantage to doing that
since one could ->

>> 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.

> Regards,
> Ian McCulloch