Re: [Boost-users] [serialization]

From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-11-10 22:20:04

Robert Ramey wrote:

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

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?

> 
>>> This naturally suggests the following for floats and doubles.
>>>
>>> * any attempt to save floats or doubles for which the result of
>>> isnan(..) is false
>>> will trap with an assertion.
> 
>> So, you're going to assert whenever someone tries to save a non-NaN?
>> That sounds pretty useless.  Even if you meant the opposite,
> 
> LOL - of course I meant the opposite.
> 
>>  it would be an unfortunate choice.  Non-signalling NaNs should be
>> serializable.
> 
> Hmm - that sounds like a matter of opinion to me.
> 
>>> 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.
> 
>>> 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? 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).

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

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

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.

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

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

Regards,
Ian McCulloch