Talk:Arithmetic coding/As a generalized change of radix: Difference between revisions

: I am not familiar with J. But the number generated could be different if a different cumulative frequency dictionary is used. One commonality of the Go/Perl/Perl 6/Ruby/Sidef solutions is that they generate the cumulative frequencies by accumulating in ascending order of the character codes (because they check keys from 0 to 255), so they always generate the same cumulative frequency dictionary. However, the order of characters when accumulating is not relevant to the correctness of the algorithm. If you accumulate in a different order, you will get a different cumulative frequency dictionary, but as long as decoding uses the same dictionary, it will produce the correct result. I can't read J, but if the J solution simply iterates through the frequency dictionary in an unspecified (not necessarily ascending) order of the keys, then it could generate a different cumulative frequency dictionary, and hence a different number. I am not sure if this is really what is happening.

: However, I also wanted to change the other solutions so that they can simply create the cumulative frequencies by simply iterating over the frequencies dictionary in any order, to remove the dependence on the range of character codes. However, such a change will also lead to nondeterministic output, so I am not sure if that's a good idea. --[[User:Spoon!|Spoon!]] ([[User talk:Spoon!|talk]]) 10:40, 28 January 2016 (UTC)