Discussion Forums

Re: Optional decimal fields with individual operators
Alessio Mazzanti / List
1 Sep 2008 8:52AM ET

Thank you very much for your prompt and clear reply.

Just a little question: what if the exponent bit isn't set and the previous value is empty?
Is this a particular case of NULL exponent?

Regards,
-- Ale

> Ale -
>
> 1. No. Whether you should process the mantissa or not is only dependent
> on a single thing: if the exponent is NULL or not. Whether you use a
> operator on the exponent doesn't change this property.
>
> In your example you use the copy operator. If the bit is not set this
> means "copy the previous value". If the previous value is not NULL, then
> the value of the exponent is not NULL and the mantissa is present.
>
> 2. The mantissa and exponent parts are treated as two individual
> fields in the dictionary so there are one or two separate signed
> integer fields in the dictionary to manage. There is no
> corresponding scaled number field in the dictionary in this case.
> However, when you communicate the value of the field from the
> decoder to the application you would typically combine them into a
> scaled number or similar.
>
> /David
>
> > Actually may be I was not so clear.
> >
> > In the specific case:
> >
> > < decimal name="MDEntryPx" id="270" presence="optional" > < exponent
> > > < copy value="-2" / > < / exponent > < mantissa > < delta / > < /
> > mantissa > < /decimal >
> >
> > since the decimal is optional, then the exponent is optional.
> > Moreover, since the exponent has the individual copy operator,
> > then the exponent will have a bit in the pmap (no matter if it is
> > set or not).
> >
> > The exponent will be considered absent in two distinct cases:
> >
> > a) The bit is not set.
> > b) The bit is set but, since the exponent is optional, it is present
> > in the stream in its NULL representation.
> >
> > In both these cases the mantissa will be not present in the stream as
> > well and has to be considered absent.
> >
> > The only case in which the mantissa is present in the stream is when
> > the exponent bit in pmap is set and the exponent value is not NULL.
> >
> > 1. Is all that right?
> >
> > 2. How should we set the new previous value of the decimal (the
> > corresponding Scaled Number) if the exponent has to be
> > considered absent?
> >
> >
> >
> > Note that even if the exponent bit in pmap was not set, the value of
> > the exponent field could result assigned (for example it should be
> > assigned to the copy initial value, or to the previous value stored in
> > the dictionary).
> >
> > 3. Let suppose the mantissa is not in the stream (because of the
> > exponent absence), what does it imply in term of the mantissa field
> > value, and what in term of the mantissa new previous value?
> >
> >
> > Many thanks in advance.
> >
> > Regards, -- Ale
> >
> >
> >
> > > Ale -
> > >
> > > A bit in the pmap indicates how a field operator should be executed.
> > > The exact meaning of the bit is dependent on the operator type and
> > > its attributes.
> > >
> > > The bit doesn't automatically indicate whether an optional field is
> > > NULL or not. Only after exercising the operator according to the bit
> > > you'll know if the value is NULL or not.
> > >
> > > When using a decimal field with individual operators, and the value
> > > of an exponent field is NULL, the instruction for the mantissa
> > > should be skipped.
> > >
> > > You may want to have a look a this post (and other posts in the same
> > > thread):
> > >
> > > http://www.fixprotocol.org/discuss/read/24ed599c
> > >
> > > /David
> > >
> > >
> > > > Hello, I would need a clarification.
> > > >
> > > > The handbook [section 10.5.1 -- Presence Map and NULL Utilization]
> > > > says:
> > > >
> > > > [...]If the decimal has optional presence, the exponent field is
> > > > treated as an optional integer field and the mantissa field is
> > > > treated as a mandatory integer field. The presence of the mantissa
> > > > field and any related bits in the presence map are dependent on
> > > > the presence of the exponent. The mantissa field appears in the
> > > > stream iff the exponent value is considered present. If the
> > > > mantissa has an operator that requires a bit in the presence map,
> > > > this bit is present iff the exponent value is considered
> > > > present.[...]
> > > >
> > > > Let suppose I have the following decimal field in my template
> > > > definition:
> > > >
> > > > < decimal name="MDEntryPx" id="270" presence="optional" > <
> > > > exponent
> > > > > < copy value="-2" / > < / exponent > < mantissa > < delta / >
> > > > > < /
> > > > mantissa
> > > > > < /decimal >
> > > >
> > > > For the best of my comprehension in this case the exponent is
> > > > optional, and has its own bit in pmap (due to the copy operator).
> > > > If that bit is not set (the exponent is not present in the stream
> > > > for sure) then the mantissa will be not present in the stream as
> > > > well.
> > > >
> > > > 1. Does the same worth if the bit in pmap is set but the exponent
> > > > value is NULL?
> > > > 2. What about the new previous value of the Scaled Number if the
> > > > exponent has to be considered absent?
> > > >
> > > > Moreover, the fact that the exponent bit in pmap is not set should
> > > > not imply that the value of the exponent field will be not
> > > > assigned (e.g. it should be assigned to the copy initial value, or
> > > > to the previous value stored in the dictionary).
> > > >
> > > > 3.Let suppose the mantissa is not in the stream (because of the
> > > > exponent absence), what does it imply in term of the mantissa
> > > > field value, and in term of the mantissa new previous value?
> > > >
> > > > Many thanks in advance. Kind regards, -- Ale


Optional decimal fields with individual operators
Alessio Mazzanti / List   22 Aug 2008 4:06AM ET
Re: Optional decimal fields with individual operators
Martin Gag / nobody   26 Aug 2008 11:45AM ET
Re: Optional decimal fields with individual operators
Alessio Mazzanti / List   1 Sep 2008 7:14AM ET
Re: Optional decimal fields with individual operators
David Rosenborg / Pantor Engineering AB   27 Aug 2008 10:38AM ET
Re: Optional decimal fields with individual operators
Alessio Mazzanti / List   1 Sep 2008 6:56AM ET
Re: Optional decimal fields with individual operators
David Rosenborg / Pantor Engineering AB   1 Sep 2008 7:27AM ET
Re: Optional decimal fields with individual operators
Alessio Mazzanti / List   1 Sep 2008 8:52AM ET
Re: Optional decimal fields with individual operators
David Rosenborg / Pantor Engineering AB   1 Sep 2008 8:55AM ET
Re: Optional decimal fields with individual operators
Alessio Mazzanti / List   1 Sep 2008 9:08AM ET
Re: Optional decimal fields with individual operators
David Rosenborg / Pantor Engineering AB   1 Sep 2008 9:22AM ET
Re: Optional decimal fields with individual operators
Alessio Mazzanti / List   1 Sep 2008 9:30AM ET
Re: Optional decimal fields with individual operators
David Rosenborg / Pantor Engineering AB   1 Sep 2008 9:36AM ET
Re: Optional decimal fields with individual operators
Alessio Mazzanti / List   1 Sep 2008 9:46AM ET