Decimal Presence Map Utilization

[joshuago_x]

Imported from previous forum

[joshuago_x]

“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.” ~ FAST 1.1 Section 10.5.1

If the decimal field is optional and the exponent is not present in the stream (pmap bit = 0), is the next bit in the pmap reserved for the mantissa or the next field in the stream?

If exponent bit is 1, then next bit is mantissa bit
If exponent bit is 0, then next bit is ??? mantissa or another field.

This is very confusing because reading from the doc, the pmap bits now seem to be conditional.

Josh

[davidrosenborg30_x]

The mantissa bit is conditional in this case. That is, if the decimal value is not present, which is indicated by an absent exponent, the operator for the mantissa is not going to be processed, and no bit will be consumed.

Note that it is the presence of the exponent that is used as the condition (the exponent would be considered absent even if its bit was 1, if the value in the stream was NULL).

The case with a conditional mantissa bit will only appear if you have an optional decimal field with individual operators and where the operator for the mantissa requires a bit in the presence map. So

would have this behavior, whereas

would not since there is no bit used for the mantissa.

/David

“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.” ~ FAST 1.1 Section 10.5.1

If the decimal field is optional and the exponent is not present in the
stream (pmap bit = 0), is the next bit in the pmap reserved for the
mantissa or the next field in the stream?

If exponent bit is 1, then next bit is mantissa bit If exponent bit is
0, then next bit is ??? mantissa or another field.

This is very confusing because reading from the doc, the pmap bits now
seem to be conditional.

Josh

[brow_x]

“If the decimal value is not present, which is indicated by an absent exponent, the operator for the mantissa is not going to be processed, and no bit will be consumed”

Is this logic still applicable when the exponent is absent from the stream while retaining a previous value? In that should I process the mantissa using the previous value of the exponent or conclude that the decimal value is absent?

Christopher

The mantissa bit is conditional in this case. That is, if the decimal
value is not present, which is indicated by an absent exponent, the
operator for the mantissa is not going to be processed, and no bit will
be consumed.

Note that it is the presence of the exponent that is used as the
condition (the exponent would be considered absent even if its bit was
1, if the value in the stream was NULL).

The case with a conditional mantissa bit will only appear if you have an
optional decimal field with individual operators and where the operator
for the mantissa requires a bit in the presence map. So

would have this behavior, whereas

would not since there is no bit used for the mantissa.

/David

“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.” ~ FAST 1.1 Section 10.5.1

If the decimal field is optional and the exponent is not present in
the stream (pmap bit = 0), is the next bit in the pmap reserved for
the mantissa or the next field in the stream?

If exponent bit is 1, then next bit is mantissa bit If exponent bit is
, then next bit is ??? mantissa or another field.

This is very confusing because reading from the doc, the pmap bits now
seem to be conditional.

Josh

[davidrosenborg30_x]

If the state of the previous value for the exponent is empty (a k a NULL), the exponent is considered absent, and no mantissa is needed, nor processed.

You could think of it as two logical steps:

1. Process the instruction of the exponent. This processing will result in an exponent value, or an absent exponent (NULL).

2. If the exponent is not NULL, process the instruction of the mantissa to form the complete decimal. If the exponent is NULL, don’t process the mantissa.

These two steps work the same regardless of how the actual computation is done: i.e, it is not dependent on whether operators, previous values or presence bits are involved in getting the exponent or the mantissa.

/David

“If the decimal value is not present, which is indicated by an absent
exponent, the operator for the mantissa is not going to be processed,
and no bit will be consumed”

Is this logic still applicable when the exponent is absent from the
stream while retaining a previous value? In that should I process the
mantissa using the previous value of the exponent or conclude that the
decimal value is absent?

Christopher

[joshuago_x]

For clarity…

Suppose the pmap value is 11100000. First bit is the stop bit, then the next two bits refer to the exponent and mantissa respectively. In this the 2nd and 3rd bit are ON, indicating the existence of the exponent and mantissa.

My question is … will the 3rd bit always refer to the mantissa? If the exponent is NULL, we are not to process the mantissa. Does that mean we skip over the 3rd bit, or does the 3rd bit now refer to a different field?

If the state of the previous value for the exponent is empty (a k a
NULL), the exponent is considered absent, and no mantissa is needed, nor
processed.

You could think of it as two logical steps:

1. Process the instruction of the exponent. This processing will result
   in an exponent value, or an absent exponent (NULL).

2. If the exponent is not NULL, process the instruction of the mantissa
   to form the complete decimal. If the exponent is NULL, don’t process
   the mantissa.

These two steps work the same regardless of how the actual computation
is done: i.e, it is not dependent on whether operators, previous values
or presence bits are involved in getting the exponent or the mantissa.

/David

“If the decimal value is not present, which is indicated by an absent
exponent, the operator for the mantissa is not going to be processed,
and no bit will be consumed”

Is this logic still applicable when the exponent is absent from the
stream while retaining a previous value? In that should I process the
mantissa using the previous value of the exponent or conclude that the
decimal value is absent?

Christopher

[davidrosenborg30_x]

The third bit will only refer to the mantissa if the exponent is not NULL. If the exponent is NULL, the third bit refers to a different field.

/David

For clarity…

Suppose the pmap value is 11100000. First bit is the stop bit, then the
next two bits refer to the exponent and mantissa respectively. In this
the 2nd and 3rd bit are ON, indicating the existence of the exponent
and mantissa.

My question is … will the 3rd bit always refer to the mantissa? If
the exponent is NULL, we are not to process the mantissa. Does that
mean we skip over the 3rd bit, or does the 3rd bit now refer to a
different field?

[stefanschwendiman_x]

Hi,

I have an additional question regarding the encoding of optional
decimals.
Same template:

Assume a previous value 192.45 (i.e. previous exponent -2, previous
mantissa 19245). If the current value is 192.63, must both the exponent and the mantissa be encoded although the exponent hasn’t changed?
(since omitting the exponent would mean to omit the entire ‘Example1’?)

Similar: if both previous and current value are 1, just the 0 exponent must be encoded, and the Pmap bits for ‘Example1’ are 10, correct?

Best regards,

Stefan

[davidrosenborg30_x]

If the exponent is the same as the previous exponent and you use the copy operator as in our exampel, then you should set the bit to 0. However this does not imply that the whole value is absent. Only if the exponent is considered to be NULL, then the whole decimal is considered absent.

In your second question, assuming that you’re encoding 110^0 followed by 110^0, then the presence bits for the second instance should be 00. That is, copy the exponent (0) and default the mantissa (1).

/David

Hi,

I have an additional question regarding the encoding of optional
decimals. Same template:

Assume a previous value 192.45 (i.e. previous exponent -2, previous
mantissa 19245). If the current value is 192.63, must both the exponent
and the mantissa be encoded although the exponent hasn’t changed? (since
omitting the exponent would mean to omit the entire ‘Example1’?)

Similar: if both previous and current value are 1, just the 0 exponent
must be encoded, and the Pmap bits for ‘Example1’ are 10, correct?

Best regards,

Stefan

[stefanschwendiman_x]

Thanks for the quick reply. I just figured it shortly after posting
from the example in the appendix. The confusion stems from the formulation
in 10.5.1 where ‘… iff the exponent value is considered present’
does apparently not mean ‘present in the stream’.

Just to make sure, slightly modified example with a constant exponent:

1.00 is encoded with just the two Pmap bits 10
1.45 is encoded with Pmap bits 11, and 145 for the mantissa
null is encoded with Pmap bit 0

Is that correct?

Best regards,

Stefan

If the exponent is the same as the previous exponent and you use the
copy operator as in our exampel, then you should set the bit to 0.
However this does not imply that the whole value is absent. Only if
the exponent is considered to be NULL, then the whole decimal is
considered absent.

In your second question, assuming that you’re encoding 110^0 followed
by 110^0, then the presence bits for the second instance should be 00.
That is, copy the exponent (0) and default the mantissa (1).

/David

[joshuago_x]

1. Is this a valid declaration?
2. Will this occupy 1 PMAP slot or 2 PMAP slots (exponent and mantissa)?

[davidrosenborg30_x]

Yes, it is valid and it will occupy exactly one PMAP slot.

/David

1. Is this a valid declaration?
2. Will this occupy 1 PMAP slot or 2 PMAP slots (exponent and mantissa)?

[joshuago_x]

Does that adhere to the latest spec?

How about this declaration? Does this also occupy one slot? It’s virtually the same as the prior declaration.

Josh

Yes, it is valid and it will occupy exactly one PMAP slot.

/David

1. Is this a valid declaration? 2) Will this occupy 1 PMAP slot or 2
   PMAP slots (exponent and mantissa)?

[davidrosenborg30_x]

It occupies one or two slots depending on the value of the exponent as we’ve just discussed.

They are not the same because in this case you treat the decimal as two individual integer fields with individual operator. In the prior case you treat the decimal as an atomic value. Those two cases are treated separately in the specification.

From a practical point of view, comparing these two particular cases, I’d always use the prior one. More typical cases where individual operators are motivated use copy or constant and delta in combination.

/David

Does that adhere to the latest spec?

How about this declaration? Does this also occupy one slot? It’s
virtually the same as the prior declaration.

Josh

Yes, it is valid and it will occupy exactly one PMAP slot.

/David

1. Is this a valid declaration? 2) Will this occupy 1 PMAP slot or 2
   PMAP slots (exponent and mantissa)?

[joshuago_x]

“atomic value” … are you implying it uses the single field method? or the twin field method?

I’ve encountered a decimal field before with the above declaration, but encoded using the twin method. Which I thought was the proper implementation because I was told that the single field method was depracated.

josh

It occupies one or two slots depending on the value of the exponent as
we’ve just discussed.

They are not the same because in this case you treat the decimal as two
individual integer fields with individual operator. In the prior case
you treat the decimal as an atomic value. Those two cases are treated
separately in the specification.

From a practical point of view, comparing these two particular cases,
I’d always use the prior one. More typical cases where individual
operators are motivated use copy or constant and delta in combination.

/David

Does that adhere to the latest spec?

How about this declaration? Does this also occupy one slot? It’s
virtually the same as the prior declaration.

Josh

Yes, it is valid and it will occupy exactly one PMAP slot.

/David

1. Is this a valid declaration? 2) Will this occupy 1 PMAP slot or
   2 PMAP slots (exponent and mantissa)?

[davidrosenborg30_x]

Atomic in the sense that it only relates to a single entry in the dictionary.

The “single field” method is, as you say, not part of FAST 1.1.

/David

“atomic value” … are you implying it uses the single field method? or
the twin field method?

I’ve encountered a decimal field before with the above declaration, but
encoded using the twin method. Which I thought was the proper
implementation because I was told that the single field method was
depracated.

josh

It occupies one or two slots depending on the value of the exponent as
we’ve just discussed.

They are not the same because in this case you treat the decimal as
two individual integer fields with individual operator. In the prior
case you treat the decimal as an atomic value. Those two cases are
treated separately in the specification.

From a practical point of view, comparing these two particular cases,
I’d always use the prior one. More typical cases where individual
operators are motivated use copy or constant and delta in combination.

/David

Does that adhere to the latest spec?

How about this declaration? Does this also occupy one slot? It’s
virtually the same as the prior declaration.

Josh

Yes, it is valid and it will occupy exactly one PMAP slot.

/David

1. Is this a valid declaration? 2) Will this occupy 1 PMAP slot
   or 2 PMAP slots (exponent and mantissa)?

[joshuago_x]

I don’t want to imply anything but from your previous reply…

<decimal name="price"><copy/></decimal>

will be encoded using the twin method, correct? And stored in one dictionary entry?

josh

Atomic in the sense that it only relates to a single entry in the
dictionary.

The “single field” method is, as you say, not part of FAST 1.1.

/David

“atomic value” … are you implying it uses the single field method?
or the twin field method?

I’ve encountered a decimal field before with the above declaration,
but encoded using the twin method. Which I thought was the proper
implementation because I was told that the single field method was
depracated.

josh

It occupies one or two slots depending on the value of the exponent
as we’ve just discussed.

They are not the same because in this case you treat the decimal as
two individual integer fields with individual operator. In the prior
case you treat the decimal as an atomic value. Those two cases are
treated separately in the specification.

From a practical point of view, comparing these two particular
cases, I’d always use the prior one. More typical cases where
individual operators are motivated use copy or constant and delta in
combination.

/David

Does that adhere to the latest spec?

How about this declaration? Does this also occupy one slot? It’s
virtually the same as the prior declaration.

Josh

Yes, it is valid and it will occupy exactly one PMAP slot.

/David

1. Is this a valid declaration? 2) Will this occupy 1 PMAP
   slot or 2 PMAP slots (exponent and mantissa)?

[davidrosenborg30_x]

That’s correct.

/David

I don’t want to imply anything but from your previous reply…

<decimal name="price"><copy/></decimal>

will be encoded using the twin method, correct? And stored in one
dictionary entry?

josh