Re: Data table text I/O package?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 23 Jun 2005 11:47:10 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> On Thu, 23 Jun 2005 00:24:30 +0200, Georg Bauhaus wrote:
>> 
>>>Dmitry A. Kazakov wrote:
>>>
>>>>But for data exchange there are better techniques than XML.
>>>
>>>Such as ...?
>> 
>> Take any middleware available.
> 
> Uhm, yes, such as ...?

CORBA, OPC (hmm), RPC etc, Ada.Streams after all.

>> No, it is still one interval that contains the true number. This is the way 
>> floating-point arithmetic functions. The result of a+b is c, such that 
>> [c'Pred, c'Succ] contains the exact result. [*] The problem is that 'Pred 
>> and 'Succ are of course machine dependent. So when you send c you should 
>> also convey the range. Depending on that the receiver should chose an 
>> appropriate internal representation for c, which might require a "true" 
>> interval.
> 
> This amounts to specifying the precise details of a floating
> point computation in a data stream; a rather special case I think.
> Take for example prices, guesstimates of future price changes,

Those are fixed point with the problems of their own. You are bound to a
definite radix, because all values need to be exact.

> insurance rates, direction of tomorrow's winds, day temperature,
> and the like.

These are fuzzy numbers. They are characterized by a distribution of
possible values. You need more than one value here. In natural languages we
are using "approximately 3.15", "between 3 and 4", "close to 5" etc.

> It seems quite enough to transmit one fpt
> number literal in these cases.

You mean a decimal literal for the case where a fixed-point decimal number
is expected. (:-))

>> Never use UDP, and you'll have no problems with that! (:-)) But seriously, 
>> do you really want to collapse all OSI levels into one big mess
> 
> No.
> 
>> and make an 
>> application responsible for error correction?
> 
> How can hard/software at OSI levels guarantee correct data?
> As soon as there is something real in there (i.e., real software,
> real hardware, real interference, humans, ...), degradation
> is possible.

That is true, but error correction codes (Hamming etc) are *known* to be
optimal. This is a hard mathematical fact. So any bandwidth available
should be invested there rather than at the application level in fancy
things like </> brackets. Further we should never mix this class of errors
with ones made by humans while writing and reading texts. These errors have
completely different nature. The first ones should be eliminated on the
transport level. The application level should consider all data free of any
errors of this kind.

>> [...]
> [XSL transformation]
> 
>> And why this nightmare cannot be written in Ada?
> 
> Because it would explode even more.

I don't believe it! (:-))

> Reading hint: if you see
> 
>   <apply-templates select="descendant::tbody"/>
> 
> forget about the mosaic impression conveyed by <-="::"/> for
> a moment and read it as
> 
>   Apply templates to the selection of descendant tbodies.
> 
> Or read the above aloud. I believe that XSL might look nightmarish
> to those who expect few characters on a PL text page, but
> if you actually read the text, it is quite natural :-)

I think this is an essence of misunderstanding of the readability issue.
You cannot control your perception. It isn't programmable. You can only
train yourself to ignore the loathing your "hardware" generates while
seeing XML! No matter how good you could be in that, it will cost you many
extra "CPU cycles" in any case. I prefer to spare my cycles. So I vote for
Ada and plain tables. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de