So, in my endeavors to finish up TIGHT (shameless plug is shameless), I've come across some interesting quirks involving the binomcdf( command most famously used in BASIC to generate certain lists (e.g., the integers in ascending order). This entire investigation began and is still ongoing in the #ti-basic channel on the Discord server.

Basically, binomcdf( is broken, at least since 1.03 and until 5.6.0. Most testing so far has been undertaken on 5.3.0 or 5.4.0/1. Now, we expect binomcdf( to be unable to generate lists of size 256 or greater, returning an ERR:DATATYPE (or ERR:UNDEFINED pre-5.0.0), and this is indeed what we see most of the time.

However, there are some oddities. The following snippets have produced their specified outputs at different times, and, more strikingly, differently on the same OS, seemingly dependent on which commands have been run before it:

5.3.0.0037

Code:
:binomcdf(300,0
ERR:UNDEFINED
:binomcdf(301,0
ERR:UNDEFINED

5.3.0.0037

Code:
:binompdf(300,0
Returns
:binomcdf(300,0
Hangs, then RAM Reset

5.3.0.0037

Code:
:binomcdf(298,0
ERR:DATATYPE
:binomcdf(299,0
ERR:DATATYPE
:binomcdf(300,0
ERR:DATATYPE
:binomcdf(301,0
ERR:DATATYPE

5.3.0037

Code:
:binomcdf(998,0
Returns

5.4.0.0034

Code:
:binomcdf(998,0
Returns

5.4.1.0052

Code:
:binomcdf(998,0
Returns

5.4.0.0034

Code:
:binomcdf(998,0
ERR:DATATYPE

5.4.0.0034

Code:
:binomcdf(998,0.5
Returns
:binomcdf(998,0
ERR:DATATYPE
:binomcdf(998,0.75
Returns
:binomcdf(998,0
ERR:DATATYPE
:binomcdf(998,|E~7
Returns
:binomcdf(998,0
Returns


I am absolutely dumbfounded by this instability, and myself and LogicalJoe have yet to identify any kind of root cause or vague explanation. In the mean time, you can contribute to this investigation by spamming lots of different binomcdf( commands and seeing what you get. I'm sure it won't make sense either.
I remember coming across some weirdness with these commands when trying to create larger lists. It only gets weird with larger lists so for most cases this isn't a problem. I also don't know why it acts in strange ways though.
Some updates from my CE running 5.4.0.0034 (I might not have been clear in the first post, but any multi-line code blocks are run in the order they are given). These were run after some of the earlier testing, so the trigger for the initial error is unknown (GarbageCollect and Clear Entries could not resolve it):


Code:
:binomcdf(998,0
ERR:MEMORY
:binomcdf(307,0
ERR:MEMORY
:binomcdf(300,0
Returns
:binomcdf(307,0
ERR:INVALID
:binomcdf(301,0
Returns
:binomcdf(307,0
ERR:MEMORY


There has been some indication that these phenomena have been partially investigated by others already; Weregoose gave mention of DarkerLine taking a look at some point. At any rate, I should probably devise a much more systematic way of looking into this.
Well, with MateoC, KryptonicDragon, and jacobly quickly hopping aboard this mystery train, a resolution may already be in sight. We've determined that binomcdf( is just performing cumSum(binompdf( under the hood, so one of those two is the culprit. While cumSum( is the operation that "fails", it fails because binompdf( is throwing it some questionable input.

You expect binompdf(N,0 to return a list of N zeroes preceded by a single 1; however, for large enough N, something ends up being a bit "off":






Details about why binompdf( breaks down are (hopefully) forthcoming.
This is the bug, in OS 5.3.0.0037:


Code:
07F896     C1            pop bc
07F897     0B            dec bc
07F898     79            ld a,c
07F899     B1            or a,c
07F89A     C8            ret z


The "or a,c" should be "or a,b". Making this patch resolves the weirdness you've been seeing, and allows for large trial sizes everywhere. Reported to TI.
I checked on a physical TI-84+, and a TI-83+ in jstified. The bug with binomcdf() occurs there as well, so it looks like this has been a bug since TI initially implemented it.
As a side note, this means that if the number of trials is > 255, incorrect binomcdf/binompdf values may be returned. Use at your own risk.
I thought you use seq() to generate certain lists.
MateoConLechuga wrote:
Reported to TI.


Well, there's no use in fixing old bugs in later OSes, as no one will update their OS to remove ASM functionality. We have to figure out a way to download patched OSes with bug fixes of our own, but I'm not sure that's fully legal.
ShinyGardevoir wrote:
I thought you use seq() to generate certain lists.
MateoConLechuga wrote:
Reported to TI.


Well, there's no use in fixing old bugs in later OSes, as no one will update their OS to remove ASM functionality. We have to figure out a way to download patched OSes with bug fixes of our own, but I'm not sure that's fully legal.

binomcdf/binompdf are slightly more efficient if you're generating certain common types of list.

TI is still making calculators(citation needed), so people will buy calculators with the latest OS and not get the choice of whether to upgrade for themselves.

It's entirely possible (and probably even legal) to install patched OSes, but it's easier to fix this type of this with a hook. I don't think anyone cares enough to create - nobody will use binomcdf/binompdf in their programs if you either need a hook or the latest OS in order to run it when there are other alternatives available, like seq( as you mentioned.
ShinyGardevoir wrote:
I thought you use seq() to generate certain lists.

Yeah if you want your program to be big and slow Evil or Very Mad
commandblockguy wrote:
binomcdf/binompdf are slightly more efficient if you're generating certain common types of list.

You mean WAYYY more efficient for speed and slightly more efficient for size...
MateoConLechuga wrote:
Reported to TI.

This is definitely the best way to go about it, having TI actually fix it rather than trying to make messy workarounds. Although I've personally reported a handful of bugs and have been told that the info would be relayed to the dev team or that I should watch out for the next OS release, only to be disappointed that nothing got fixed, but I still have hope that it might be somewhere at the bottom of their burndown chart. Rolling Eyes (below very important things like removing asm, blocking another version of ndless or perhaps adding more coprocessors)
kg583 wrote:





These "corrupted" floats are potentially really exciting. They could potentially be used to implement bitwise operations in pure BASIC using float arithmetic, which would be 5-10x the speed as the current fastest method. I wrote about this possibility back in 2016 but didn't investigate further since I didn't know of a way to obtain corrupted floats in pure BASIC.
This is wonderful:


I did binompdf(988,0)→L₁, then stored it into L₂. Somehow, trying to access the other lists result in ERROR: MEMORY while doing ClrList actually deletes the variable.
Hello, I need some help. Can everyone run the following commands in sequence on their physical calculator (any model, even 83+, make sure it is reset), and tell me if the output of the last command has corrupted data in it, and what the first few corrupted numbers are?


Code:
binompdf(257,0)
binompdf(2,0)
binompdf(257,0)
sum(Ans)
binompdf(257,0)


I really appreciate it thanks Smile
I got a data type error when I got to the sum(Ans) part, I don't know if that's suppose to happen. Here's the first 2 corrupted numbers for each calculator:

TI-84 Plus CE, OS 5.3.0, Boot 5.3.6, L-0519: {2.9383r3038, -τ.³2²353434E-128} (where r is the superscript r)
TI-84 Plus CE, OS 5.3.0, Boot 5.0.0, L-0315: {2.r480001E-128, 1.3003r0306E-128} (where r is the superscript r)
TI-84 Plus CE, OS 5.4.0, Boot 5.3.6, N/A: {1.40007000²E-128, ⁻¹.τ001r0042E-128} (where r is the superscript r)
I got a data type error on sum(Ans). 84+CE, OS 5.3.0, Boot 5.1.5, L-0316C
The corrupted numbers I get are different on each run.
Yeah same data type error here on several CEs

But I managed to get a stabilized value, even across resets, on my rev M 84+CE (OS 5.5.5) by doing this:
reset => set to classic => binompdf(257,0 => set to MathPrint => binompdf(257,0 four times.

Then the 5th list entry will be 3.3383°°038ᴇ-80.

It's not the same value on my 5.5.2 83PCE.
TI 84+ [1.03] [2.55mp]

Error: Undefined after doing sum(Ans)
Corrupted numbers: 0.600°°1532e-128 (index is around 240)
That's the only corrupted number.
Error on
Code:
sum(Ans)
.

if I run

Code:
binompdf(257, 0)
again, I get 1, nine zeros, and (-=7=√(<7<)-9=9√(7=7))/<7=, then (-;3:√+3;3√(110))/;3;, then -2.2e35, then the string of zeros and weird symbols repeat. plus more weirdness. The division symbols here are thick fraction division symbols.
Storing that into a list and viewing it later gives the same results, except that certain elements of the list corrupt the screen with garbage characters (and they're not even the same characters each time).

I'm running this on a TI-84+CE, OS 5.4.0.0034, date code L-0620O.

edit: formatting
TI 84+CE running 5.4.0.0034; DATATYPE error on the sum(Ans) call. Corrupted value start at index 9 (preceded by a few nonzero but still valid floats):

3.133343plusplus03132E-70
3.2303030310box35E-119
3.plusplus0313238293E-78
2.9³F203plus00³F2TE-80
0

TI-84+CE running 5.3.0.0037; DATATYPE error on the sum(Ans) call. Corrupted values start at index 7:

7.1000070000boxE-78
0.5000000000001E-115
0
3.729303box31303E-78
3.plusplus0313238293E-78

where box and plus are the respective plotting symbols, T is transpose, and F is this guy.
As discussed on IRC I get borked values on CE 5.1.5 and 5.6.0, also on the CSE as well.

On 84+SE 2.41 and regular 83 (non plus) 1.1 I get an error on sum(Ans).
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement