[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/6d0f72c5 - PLEASE DO NOT REPLY BY MAIL.]
OK, thanks. Dimitry > I believe Anders' recommendation stands: -- all the tweaks in the book. > > Best, Rolf > > > 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 -~----------~----~----~----~------~----~------~--~---
