[This message was posted by Harly hE of IT <[email protected]> to the "FAST 
Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply 
to it on-line at http://fixprotocol.org/discuss/read/a95d4fd1 - PLEASE DO NOT 
REPLY BY MAIL.]

> Thank you very much David.
> I had just found that explaination in the handbook.
> 
> -- Ale
> 
> > The delta value for an *optional* string field will use a *nullable*
> > signed integer to convey the subtraction length. A non-negative nullable
> > integer is increased by one when encoding, and conversely decreased when
> > decoding. That operation is independent of the excess-1 coding used for
> > the subtraction length itself.
> > 
> > /David
> > 
> > > Many thanks for your prompt reply. For the best of my knowledge,
> > > positive subtraction lengths have not to be adjusted for the excess-1
> > > encoding. So 1 is the value in the stream, without any manipulations.
> > >
> > > W.r.t. FAST specification, if I had received a subtraction length =
> > >        -1, it would have been correct (because after excess-1 encoding
> > >        I would have got subtraction length=0).
> > >
> > > So could the error be on the SWX stream (forgetting the minus)?
> > >
> > >
> > > P.S. In your opinion what's the lenght of the string "\0"? Is it 0 or
> > >      is it 1?
> > >
> > > Thanks in advance.
> > >
> > >
> > >
> > > > How an empty string is represented within a particular
> > > > implementation is not specified by the FAST specification. However,
> > > > it should of course have the length 0.
> > > >
> > > > If the subtraction length is 1 and the base value is the empty
> > > > string, then this is indeed an error.
> > > >
> > > > When you get the subtraction length 1, is this after you've adjusted
> > > > it for the excess-1 coding used for nullable string deltas?
> > > > Otherwise that could explain the problem you're facing.
> > > >
> > > > /David
> > > >
> > > >
> > > > > Hi, I'm trying to decode the SWX FAST stream, and in particular an
> > > > > optional ASCII string attribute (named RandomisedInterval) with
> > > > > delta operator and no initial value (default base value 'Empty
> > > > > String' is used). Let suppose we have an undefined dictionary
> > > > > previous value (i.e. the 'Empty String' should be used as previous
> > > > > value) and we read from the stream an ASCII String Delta made by a
> > > > > Substraction Length = 1 followed by an ASCII String that in that
> > > > > case corresponds to the whole RandomisedInterval string
> > > > > "00:02:00".
> > > > >
> > > > > The problem I'm facing with is quite simple: since I consider the
> > > > > 'Empty String' (the default base value) as a string with lenght=0,
> > > > > a Substraction Length = 1 (meaning to remove 1 character from the
> > > > > back of base value) makes my application to report the error [ERR
> > > > > D7].
> > > > >
> > > > > I would like to undertand if I'm making a mistake calculating the
> > > > > actual length of the 'Empty String' or if the right behaviour is
> > > > > actually to report the error.
> > > > >
> > > > >
> > > > > Furthermore, since I also consider the string "\0" as it had
> > > > > length=0, I think a similar problem could arise in any case I have
> > > > > a dictionary previous value = 'Empty String' or "\0".
> > > > >
> > > > > Many thanks in advance.

The QuickFast's codes [FieldInstructionAscii::encodeDelta(...)] give you a 
explain. 

God help you


[You can unsubscribe from this discussion group by sending a message to 
mailto:[email protected]]

-- 
You received this message because you are subscribed to the Google Groups 
"Financial Information eXchange" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/fix-protocol?hl=en.

  • [FIX] Re: Empy String and "... 'FAST Protocol' forum at fixprotocol . org

Reply via email to