section 3.8.1.2 needs to define get_rac

[mcr]

As per Barry Lieba review, the section 3.8.1.2 says:

 "get_rac" returns a boolean, computed from the bytestream as
 described in Section 3.8.1.1. 

but it is not defined, and likely relates to the decode process.

[mcr]

https://github.com/dwbuiten/go-ffv1/blob/master/ffv1/rangecoder/range.go
also change reference from 3.8.1.1 to cite figure 9.

[mcr]

@dericed

[dwbuiten]

Worth noting here that when I implemented go-ffv1, it was with an older revision of the spec, and it seems the figure numbers have since changed... I'll update the comments.

(Also worth noting that go-ffv1 is not an official reference decoder.)

[dericed]

Hi @dwbuiten, you could contextualize your comments to the version of the draft such as "draft-ietf-cellar-ffv1-17", although as the document is in "IESG Evaluation" status the RFC number may be soon.

[dwbuiten]

Yes, I'll do that when I update them.

[dericed]

@dwbuiten, @michaelni, are you able to assist with the get_rac piece of Barry's review. The quote from the review is

— Section 3.8.1.2 —

   "get_rac" returns a boolean, computed from the bytestream as
   described in Section 3.8.1.1.

I see nothing in Section 3.8.1.1 that describes get_rac.

I understand that get_rac refers to figure 9; however a narrative could help. For instance does rac mean RAnge Coded binary value? If figure 9 is read as the i-th range coded binary value equals, then what is the R_i of the formula mean?

[michaelni]

I understand that get_rac refers to figure 9; however a narrative could help. For instance does rac mean RAnge Coded binary value?

IIRC get_rac() was named for consistancy with get_cabac(), it returns a single bit coded using the range coder. Not sure if the 3 letters can be matched to grammatically 100% fitting words

[JeromeMartinez]

It looks like this issue can be closed (#230 and #241 are merged).