RE: IEEE floats and binary XML [Re: [xml-dev] binary XML API and scientific use cases [Re: [xml-dev] [ANN] nux-1.0beta2 release

That was more or less intended to be the thrust of the use case you
site.  If the requirement you are talking about has not been covered
adequately I think we need to revisit the use case, which is basically
about scientific computing.  Don't let the energy industry focus mislead
you -- this is the industry that discovered statistical deconvolution
(Enders Robinson) and, in a proprietary context, FFT long before
Cooly-Tukey (Vern Herbert).  Feel free, however, to suggest variants or
additions to the usage case.  (Astronomical data, perhaps?)  Or, I
suppose, a completely new use case, but I really do think that the
intention was to cover what concerns you.

-----Original Message-----
From: public-xml-binary-request@w3.org
[mailto:public-xml-binary-request@w3.org] On Behalf Of Aleksander
Slominski
Sent: Monday, November 22, 2004 4:11 PM
To: Wolfgang Hoschek
Cc: public-xml-binary@w3.org; xml-dev@lists.xml.org
Subject: IEEE floats and binary XML [Re: [xml-dev] binary XML API and
scientific use cases [Re: [xml-dev] [ANN] nux-1.0beta2 release



Wolfgang Hoschek wrote:

> On Nov 22, 2004, at 1:01 PM, Aleksander Slominski wrote:
>
>>
>> are use cases related to XML Binary Characterization
>> <http://www.w3.org/TR/xbc-use-cases/>?
>
>
> They might fit into that "diverse" bag-of-things as well...
>
>>
>> i am a bit disappointed that scientific requirements are completely
>> omitted form XBC use cases - the closest i could find is 
>> http://www.w3.org/TR/xbc-use-cases/#FPenergy but it skips over whole 
>> issue how to transfer array of doubles without changing endianess ...
>
>
> I may be wrong, but conversion of doubles to strings and back seems
> the main CPU drain here, rather than byte swapping. 

that is what is our concern: we want to sent scientific data structures 
in such way that it is efficient both network bandwidth and CPU and that

implies to support directly writing unchanged binary including not 
changing IEEE reps and endianess so that pieces of metadata must be 
included in binary XML ...

> Try doing this for billions of floats, gulp.

yep

> Hence one would need to ship arrays of doubles in IEEE floating point
> representation or native format to avoid string conversions, perhaps 
> most appropriately as an "attachment" according to the various related

> standards out there. 

i am looking what would it take to do it with MTOM/XOP but second 
possibility is to have extensible binary XML that would allow to include

directly into the representation IEEE floats with appropriate metadata 
to reconstruct their string representation if needed (for apps that 
needs pure XML view)

> When working with a binary representation, one could also extend
> DOM-like APIs in somewhat counter-intuitive manners, with subclasses 
> like DoubleArrayText, converting from double to IEEE floating point 
> and back, or similar.

i am more concerned about "standard" binary XML format that can do this 
than APIs

>
>>
>> we did lot of work in past related to XML performance (in Indiana
>> University and Binghamton) and are very concerned that whatever 
>> binary XML will be characterized/standardized in W3C will be of no 
>> much use for scientific computing and grids ...
>
>
> You would need strong advocates/evangelists, it seems.

scientific and business worlds seems sometimes quite disconnected in 
their requirements about XML ...

thanks,

alek

-- 
The best way to predict the future is to invent it - Alan Kay

Received on Monday, 22 November 2004 22:24:18 UTC