binompdf( is broken on the TI-83 (tested ROM 1.0200) and TI-86 as well.

On the TI-83 I tested, binompdf(300,0) gives three nonzero elements; element 47 shows 3.4ᴇ-49 but shows more garbage in the stats editor if stored to L1, element 49 shows 4.857494³ᴇ-123, and element 301 shows 1. sum(Ans) fails with ERR:DATA TYPE, and L1(47) fails with ERR:SYNTAX.

The Inferential Statistics add-on for the TI-86 is also broken in pretty much the same way. The corrupted list elements (comprising most of the output of binompdf(300,0)) contain base-hex characters and very large negative exponents. Fortunately this should be easily patchable since it's not part of the ROM.

TI-84 Plus OS 2.43 throws ERR:MEMORY, then hangs, on binompdf(300,0) \ binomcdf(300,0). The TI-83 does not freeze (ERR:UNDEFINED immediately), and the TI-86 throws an ERR:MEMORY with a sluggishly-loading options menu. I have not tested my 83+, but at this point I don't think we need to.

Are the superscript "3"s, "o"s, and "r"s supposed to be a displayed digit that's greater than 9?

Also, it's not normal that some numbers are displayed with "e-127", "e-128", etc.; I thought it just goes to 0 after 1e-99.

I see glitched numbers like these after configuring the Start-up TI-84+ App. After loading the app, do [Stat] {Tests} [7] {Stats}.

The exponent limit imposed by the OS in usual calculation is +/-99, but internally the exponent is stored as an 8-bit signed integer, so -128 to 127 is possible if the float is corrupted. Although, it is possible to store such a large/small float to a regular real variable using a For( loop.

You can also use the Transfrm app on the TI-84+ to go to 1e+100 and beyond.


On address $07f899, what hexidecimal value should you modify and modify it to in order for the binompdf() bug to be fixed?

TI-84+CE with 5.3.0.0037, not recently reset. binomcdf(257,0) was put into L1:

So now you can access corrupted floats via binomcdf() or binompdf(). But you'd have to do something like list 1(241) − Ans(246) or whatever to do some manipulation, not to mention you'd probably have to some division to get the digit in the 1s place. I'm not sure if all the steps required to set up a bitwise operator would save enough bytes/time compared to other methods.