[This message was posted by Dimitry London of Morgan Stanley <[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/61761e94 - PLEASE DO NOT REPLY BY MAIL.]
Thanks, Rolf. I think this should be added to a list of FAST extensions. I think spec should provide an ability to specify the base. In the meantime, what would your recommend as the most efficient approach to send a scaled number whose original representation is a double without breaking the spec? (I am actually using the C++ implementation which we plan to open-source). Thanks again, Dimitry > Dimitry, > > your interpretation is correct. The current definition of scaled numbers > require that you use a base 10 exponent. Using base 2 would be a > transgression. > > Maybe we should put this up for discussion along with the other > extension proposals? > > /Rolf > > > > Thanks, Anders. > > > > Yes, the source value is represented as a native double (on a Linux > > host). How do I create a FAST representation of this field then? Using > > a scaled number with a base of 10 (as the Fast spec requires) will > > certainly make it a performance bottleneck, as you say. So, should I > > simply split it into base 2 exponent and mantissa (via frexp()) and > > assume base 2? Does it not break compliance with FAST? > > > > Thanks, Dimitry > > > > > > Hi, > > > > > > > > What is the most efficient way to encode a given double value into > > > > a scaled number? > > > > > > > > For example, assuming that I have 2.5555 represented as a double > > > > on Linux, and want to create a FAST wired representation of this > > > > this field? > > > > > > > > Thanks, Dimitry > > > > > > Dimitry, > > > > > > at Pantor (Pantor Presto and ORDO), we avoid shifting between base 2 > > > and base 10 representations in our processing chain as a conversion > > > may become part of the bottleneck at extreme rates. Also, we hand > > > scaled numbers to users of our Presto API to avoid a conversion > > > unless / until it turns out to be necessary. If doubles are what you > > > have to work with, there is not much to do but to create an > > > optimized converter with all the tweaks in the book. > > > > > > Kind regards, Anders [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 FIX-Protocol@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
