[Cfp-interest] terms DPD and BID

[Jim Thomas]

Ok, back to this issue. In email on 2/19/2013 I made an attempt at using the IEC 60559 terminology:

> … we might say in (Part 2) 12.3 something like:
> 
> "The types
> …
> represent values of decimal floating types in one of the two alternative encodings allowed for decimal formats by the IEC 60559 standard: the encoding based on decimal encoding of the significand or the encoding based on binary encoding of the significand, "
> 
> and in 12.4.2:
> 
> "The encodedpd functions convert the argument into the encoding based on decimal encoding of the significand. …"
> 
> and similarly for the other re-encoding functions
> 
> and add something about our use of the acronyms dpd and bid in type and function names, or else change the names.



Mike and Marius, is this what you have in mind? We might change the function names to encodedecd32, encodebind32, etc. 

-Jim 


On Feb 20, 2013, at 1:45 AM, Mike Cowlishaw <mfc at speleotrove.com> wrote:

> Jim & Marius,
> While I agree with Mike that it should be better to use the IEC 60559 terminology, the reality is that DPD and BID were easier to identify the two encodings and are spread widely in various publications.
> So unless Mike feels very strongly about avoiding DPD and BID I would leave them in, properly qualified as you suggested.
>  
> I don't have an opinion on the use of BID (although it has some slang meanings in the UK, so I would avoid it).   I do feel very strongly about the use of DPD to refer to the encoding as a whole, however.  It was a useful abbreviation/jargon for committee use, but it does not do justice to the very neat encoding of the exponent, etc., devised by Dan Zuras and others.   It's not even the case that the whole coefficient is encoded using DPD.
>  
> I don't quite see the difficulty in using the  IEC 60559  terminology (perhaps abbreviated).  Anyone implementing or using this level of detail will surely have to be aware of that terminology anyway, and introducing a second way of saying the same thing is best avoided if possible.
>  
> Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130301/d1a91051/attachment.html