> For example, how would you write the > python code to get the 4 bytes of a 32bit float given that the language only > has 64bit floats? The same way we get the doubles: using the struct module. :)
The sentiment is right, though. Poor language support and marginal performance gain reduce the value of adding the extra type. If you're doing HPC, you're probably better off with MPI than Thrift anyway. --David On 01/13/2011 08:22 PM, Jeffrey DeCew wrote: > From the whitepaper... > >> The type system rests upon a few base types. In considering which types to >> support, we aimed for clarity and simplicity over abundance, focusing on the >> key types available in all programming languages, ommitting any niche types >> available only in speciļ¬c languages. ... Of particular note is the absence >> of unsigned integer types. Because these types have no direct translation to >> native primitive types in many languages, the advantages they afford are >> lost. > > > Reading between the lines, it looks like 32bit floats also did not seem to > represent a significant performance advantage. Also, since they are > unavailable in many languages, there may have been significant concern > about feasibility of implementation. For example, how would you write the > python code to get the 4 bytes of a 32bit float given that the language only > has 64bit floats? > > I hope this helps. > -- > Jeff DeCew > > > On Thu, Jan 13, 2011 at 5:27 PM, Max Hodak <[email protected]> wrote: > >> Is there a reason there's no 32-bit floating point type in Thrift? The >> difference between floats and doubles can be significant if an RPC is >> returning a lot of data. >> >
