Imported from previous forum
Is it possible to use int8 datatype for 1-byte field (regardless whether a field an int8 or a 1-byte character). The advantage would be efficiency - for example, defining MDEntryType as an “int8” allows to use it an array index (with the “string” there is an additional conversion that needs to be performed; and 1-byte vector sounds too verbose and confusing).
Thanks,
Dimitry
Dimitry,
yes you can do this but you’ll have an int7 at your disposal:)
this is fine as long as you have 1 character US ASCII fields as these valus would fit into a one byte (7-bit) field.
(You can obviously treat a two char string as a 14-bit number as well)
/Rolf
Is it possible to use int8 datatype for 1-byte field (regardless whether
a field an int8 or a 1-byte character). The advantage would be
efficiency - for example, defining MDEntryType as an “int8” allows to
use it an array index (with the “string” there is an additional
conversion that needs to be performed; and 1-byte vector sounds too
verbose and confusing).Thanks, Dimitry
Rolf, thanks very much. I realize that I deal with 7-bit field, so the maximum possible value would be “128” which should still be enough to cover 0-9 and most letters of the alphabet. I just have to make sure that I don’t use any letters with numeric ASCII value greater than 128.
Dimitry
Dimitry,
yes you can do this but you’ll have an int7 at your disposal:) this is
fine as long as you have 1 character US ASCII fields as these valus
would fit into a one byte (7-bit) field.(You can obviously treat a two char string as a 14-bit number as well)
/Rolf
Is it possible to use int8 datatype for 1-byte field (regardless
whether a field an int8 or a 1-byte character). The advantage would be
efficiency - for example, defining MDEntryType as an “int8” allows to
use it an array index (with the “string” there is an additional
conversion that needs to be performed; and 1-byte vector sounds too
verbose and confusing).Thanks, Dimitry
You will find that all US ASCII characters are in the range 0-127 and that they can be represented as a 7 bit quantity. This fact was one of the considerations in the original design of FAST.
Other character sets require more than seven bits and are therefore better represented using byte vectors.
/Rolf
Rolf, thanks very much. I realize that I deal with 7-bit field, so the
maximum possible value would be “128” which should still be enough to
cover 0-9 and most letters of the alphabet. I just have to make sure
that I don’t use any letters with numeric ASCII value greater than 128.Dimitry
Great, thanks very much.
Dimitry
You will find that all US ASCII characters are in the range 0-127 and
that they can be represented as a 7 bit quantity. This fact was one of
the considerations in the original design of FAST.Other character sets require more than seven bits and are therefore
better represented using byte vectors./Rolf
Rolf, thanks very much. I realize that I deal with 7-bit field, so
the maximum possible value would be “128” which should still be
enough to cover 0-9 and most letters of the alphabet. I just have to
make sure that I don’t use any letters with numeric ASCII value
greater than 128.Dimitry
The most interoperable way of sending non-ASCII strings is by using Unicode strings. You specify this in the template as
/David
Great, thanks very much.
Dimitry
You will find that all US ASCII characters are in the range 0-127 and
that they can be represented as a 7 bit quantity. This fact was one of
the considerations in the original design of FAST.Other character sets require more than seven bits and are therefore
better represented using byte vectors./Rolf
Rolf, thanks very much. I realize that I deal with 7-bit field, so
the maximum possible value would be “128” which should still be
enough to cover 0-9 and most letters of the alphabet. I just have to
make sure that I don’t use any letters with numeric ASCII value
greater than 128.Dimitry
Rolf/David,
how would I specify int8 type in FAST XML template? I don’t think there is an official “int8” type, so my FAST template would violate FAST compliance, no?
thanks,
Dimitry
The most interoperable way of sending non-ASCII strings is by using
Unicode strings. You specify this in the template as/David
Great, thanks very much.
Dimitry
You will find that all US ASCII characters are in the range 0-127
and that they can be represented as a 7 bit quantity. This fact was
one of the considerations in the original design of FAST.Other character sets require more than seven bits and are therefore
better represented using byte vectors./Rolf
Rolf, thanks very much. I realize that I deal with 7-bit field, so
the maximum possible value would be “128” which should still be
enough to cover 0-9 and most letters of the alphabet. I just have
to make sure that I don’t use any letters with numeric ASCII value
greater than 128.Dimitry
Dimitry,
there is currently no way to specify an int8 field.
I would suggest that you use int32 in order to comply with the FAST spec and then handle any range checking above the FAST layer.
As a sidenote for the rest of our readers: If you go back and read the earlier entries in this thread, it seems (from Dimitry’s post of October 5, 2007) that he wants to process a one byte field efficiently. As I noted in my response to that post, you can obviously view a one byte representation on the wire as a 7-bit integer. This is what will happen if you use int32 and you make sure you only send values in the range [-64,63] ([-2^6,2^6-1]).
Values in the range [-128,-65] ([-2^7,-2^6-1]) and [64,127] ([2^6,2^7-1]) will be represented using two bytes on the wire where the full range of the two byte representation is [-8192,8191] ([-2^13,2^13-1]).
If you don’t need a signed quantity then your range for each of the one and two byte representations will be [0,127] ([0,2^7-1]) and [0,16383] ([0,2^14-1]) respectively.
As you can see the distances between the min and max values are the same, but in the signed case half of the range is below zero.
HTH,
Rolf
Rolf/David,
how would I specify int8 type in FAST XML template?
I don’t think there is an official “int8” type, so my FAST
template would violate FAST compliance, no?thanks, Dimitry
Thanks, Rolf. But in this case, int32 will be rather confusing as the data is really more accurately defined as 1-byte character format. For example, for “BID=A” using int32 is really confusing.
I think I will most likely use string for this implementation for clarity purposes (Although the performance for int8 fields is really pretty good for my current C++ implementation).
Perhaps, 1-byte character should another data type in future FAST protocol versions.
thanks a lot for the info,
Dimitry
Dimitry,
there is currently no way to specify an int8 field.
I would suggest that you use int32 in order to comply with the FAST spec
and then handle any range checking above the FAST layer.As a sidenote for the rest of our readers: If you go back and read the
earlier entries in this thread, it seems (from Dimitry’s post of October
5, 2007) that he wants to process a one byte field efficiently. As I
noted in my response to that post, you can obviously view a one byte
representation on the wire as a 7-bit integer. This is what will happen
if you use int32 and you make sure you only send values in the range [-
64,63] ([-2^6,2^6-1]).Values in the range [-128,-65] ([-2^7,-2^6-1]) and [64,127] ([2^6,2^7-
1]) will be represented using two bytes on the wire where the full range
of the two byte representation is [-8192,8191] ([-2^13,2^13-1]).If you don’t need a signed quantity then your range for each of the one
and two byte representations will be [0,127] ([0,2^7-1]) and [0,16383]
([0,2^14-1]) respectively.As you can see the distances between the min and max values are the
same, but in the signed case half of the range is below zero.HTH, Rolf
Rolf/David,
how would I specify int8 type in FAST XML template? I don’t think
there is an official “int8” type, so my FAST template would violate
FAST compliance, no?thanks, Dimitry
Dimitry,
I’m not sure I agree with you that an int8 type is needed in FAST.
The wire representation allows for unlimited size integers.
The reason for offering both 32 and 64 bit types is efficiency
(or rather inefficiency of 64-bit types in some environments),
but I don’t see a reason for more integer types.
I would guess that your int32 impl needs tuning if you have
more than marginally better performance on your int8 impl.
You can specify your own types on top of those defined in the
standard spec if you would like to handle range checking etc.
Best,
Rolf
Thanks, Rolf. But in this case, int32 will be rather confusing as
the data is really more accurately defined as 1-byte character
format. For example, for “BID=A” using int32 is really confusing.I think I will most likely use string for this implementation for
clarity purposes (Although the performance for int8 fields is
really pretty good for my current C++ implementation).Perhaps, 1-byte character should another data type in future
FAST protocol versions.thanks a lot for the info, Dimitry
Dimitry,
Converting to and from int32 is certainly a viable option, but if the content of the field is indeed an ASCII-character, the most interoperable way would be to use the string type in FAST:
The wire representation would be as compact as if using int32 to represent the single character.
Depending on your implementation strings may be less efficient to handle within the application than for example an int32. However, an implementation is free to make use of ancillary information, like that the string will always have exactly the length 1, and optimize this field further and for example handle it as an char-type internally.
So I’d recommend that you use the string type and provide the extra length constraint by other means. You can do this in plain prose in the documentation of your protocol. You also have the option to devote a foreign attribute to carry such information, for example like this:
.../David
Thanks, Rolf. But in this case, int32 will be rather confusing as the
data is really more accurately defined as 1-byte character format. For
example, for “BID=A” using int32 is really confusing.I think I will most likely use string for this implementation for
clarity purposes (Although the performance for int8 fields is really
pretty good for my current C++ implementation).Perhaps, 1-byte character should another data type in future FAST
protocol versions.thanks a lot for the info, Dimitry
Dimitry,
there is currently no way to specify an int8 field.
I would suggest that you use int32 in order to comply with the FAST
spec and then handle any range checking above the FAST layer.As a sidenote for the rest of our readers: If you go back and read the
earlier entries in this thread, it seems (from Dimitry’s post of
October 5, 2007) that he wants to process a one byte field
efficiently. As I noted in my response to that post, you can obviously
view a one byte representation on the wire as a 7-bit integer. This is
what will happen if you use int32 and you make sure you only send
values in the range [- 64,63] ([-2^6,2^6-1]).Values in the range [-128,-65] ([-2^7,-2^6-1]) and [64,127] ([2^6,2^7-
1]) will be represented using two bytes on the wire where the full
range of the two byte representation is [-8192,8191] ([-2^13,2^13-
1]).If you don’t need a signed quantity then your range for each of the
one and two byte representations will be [0,127] ([0,2^7-1]) and
[0,16383] ([0,2^14-1]) respectively.As you can see the distances between the min and max values are the
same, but in the signed case half of the range is below zero.HTH, Rolf
Rolf/David,
how would I specify int8 type in FAST XML template? I don’t think
there is an official “int8” type, so my FAST template would violate
FAST compliance, no?thanks, Dimitry
Thanks a lot David, this is sounds like a very viable option.
Dimitry
Dimitry,
Converting to and from int32 is certainly a viable option, but if the
content of the field is indeed an ASCII-character, the most
interoperable way would be to use the string type in FAST:The wire representation would be as compact as if using int32 to
represent the single character.Depending on your implementation strings may be less efficient to handle
within the application than for example an int32. However, an
implementation is free to make use of ancillary information, like that
the string will always have exactly the length 1, and optimize this
field further and for example handle it as an char-type internally.So I’d recommend that you use the string type and provide the extra
length constraint by other means. You can do this in plain prose in the
documentation of your protocol. You also have the option to devote a
foreign attribute to carry such information, for example like this:…
/David
Thanks, Rolf. But in this case, int32 will be rather confusing as the
data is really more accurately defined as 1-byte character format. For
example, for “BID=A” using int32 is really confusing.I think I will most likely use string for this implementation for
clarity purposes (Although the performance for int8 fields is really
pretty good for my current C++ implementation).Perhaps, 1-byte character should another data type in future FAST
protocol versions.thanks a lot for the info, Dimitry
Dimitry,
there is currently no way to specify an int8 field.
I would suggest that you use int32 in order to comply with the FAST
spec and then handle any range checking above the FAST layer.As a sidenote for the rest of our readers: If you go back and read
the earlier entries in this thread, it seems (from Dimitry’s post of
October 5, 2007) that he wants to process a one byte field
efficiently. As I noted in my response to that post, you can
obviously view a one byte representation on the wire as a 7-bit
integer. This is what will happen if you use int32 and you make sure
you only send values in the range [- 64,63] ([-2^6,2^6-1]).Values in the range [-128,-65] ([-2^7,-2^6-1]) and [64,127] ([2^6,2^7-
1]) will be represented using two bytes on the wire where the full
range of the two byte representation is [-8192,8191] ([-2^13,2^13-
1]).If you don’t need a signed quantity then your range for each of the
one and two byte representations will be [0,127] ([0,2^7-1]) and
[,16383] ([0,2^14-1]) respectively.As you can see the distances between the min and max values are the
same, but in the signed case half of the range is below zero.HTH, Rolf
Rolf/David,
how would I specify int8 type in FAST XML template? I don’t think
there is an official “int8” type, so my FAST template would
violate FAST compliance, no?thanks, Dimitry