Strategy for efficiently storing and checking sets of boolean values in TI BASIC

[+FarmerPotato]

REM TEST 40 BITS PACKED INTO A FLOAT
AA=65535
B=65536
REM HEX VALUE: FF FFFF FFFF
A=(255*B+AA)*B+AA
REM 2^40-1 = 1099511627775
PRINT A
FOR I=1 TO 10
N=1
FOR J=1 TO 40
D=N+N
F=INT((A+N)/D)>INT(A/D)
PRINT CHR$(48-F);
N=D
NEXT J
PRINT
NEXT I

I tested bit values. This should be good to store 40 bits per float, right? That's 13 decimal digits. 

REM TEST 40 BITS PACKED INTO A FLOAT
AA=65535
B=65536
REM HEX VALUE: FF FFFF FFFF
A=(255*B+AA)*B+AA
REM 2^40-1 = 1099511627775
PRINT A
FOR I=1 TO 10
FOR J=1 TO 40
D=N+N
F=INT((A+N)/D)>INT(A/D)
PRINT CHR$(48-F);
N=D
NEXT J
PRINT
NEXT I

Remove PRINT and it takes 27 seconds. Since this is doing 400 bit tests, that's 67 ms each.  If it were only doing 80 tests like the above, it would be about 5.5 seconds. (confirmed with I=1 TO 2)

 

That's about the same time as F$=SEG$(A$,I,1)

 

But it's not as fast as @pixelpedant method of primes where the test is F=A/17=INT(A/17). I clocked 400 bit tests of that at 12.5 seconds - call it twice as fast as my power of 2 bit tests. 

 

 

My bit test is twice as slow, but packs 40 bits into a float, where the prime factors method packs 10 bits.

 

I found the limits to the precision of TI RADIX-100...

TLDR;

Spoiler

 

Without loss of precision, you can develop the bit flags in chunks of 16 bits, like so:

REM 2^40-1 = 1099511627775
REM HEX VALUE: FF FFFF FFFF
AA=65535
B=65536
A=(255*B+AA)*B+AA

Curiously, 2^41-1, a 41-bit number with ones, has a 0 at 2^0 and 2^20.  Same if it is typed as 2199023255551.

 

My intuition was that you could pack 47 bits into 15 decimal digits. But though I tried this:

 

PRINT (2^46+1)-(2^46)
1
PRINT (2^47+1)-(2^47)
0

You might think you're getting away with 46 bits max, but despite that tiny 1 being preserved, not all other bits can be reliably tested. Hmm.

 

 

 

 

[RXB]

15 hours ago, InsaneMultitasker said:

 

Proof you refuse to ever admit you are wrong about anything, continue to push a lie that you are better at timing a computer then a computer.

The arrogance is astounding.

 

I created EA cart in open space of TI Basic GROMs and Tursi helped which includes CALL CHARPAT and other features like CALL PEEK and CALL LOAD(address,value)

Would also allow 8K RAM in Cart space. Of course a GRAM device (like GRAMKRACKER) or MESS or Classic99 is required.

So CALL CHARPAT is available to TI BASIC, but more then a Console is required.

TI BASIC in Console only is just so underpowered and badly thought out.

 

 

[+InsaneMultitasker]

4 minutes ago, RXB said:

Proof you refuse to ever admit you are wrong about anything, continue to push a lie that you are better at timing a computer then a computer.

The arrogance is astounding

Huh?  I have no idea what you are trying to pin on me here.   I do not represent everyone else who responded to this thread, and my input certainly did not rise to the level of "refusing to ever admit I am wrong about anything".   I shared one response related to accuracy/precision that you appear to not believe, similar to your apparent refusal to address certain questions about your testing methods.

 

I agree, a computer can be better at timing an event, however, the TI clock as presented by you is NOT as accurate as stopwatch. Does it matter much with 100s or 1,000s of iterations? Not really, as others have so eloquently explained.

 

The impudence is astounding.  I am done here.

[GDMike]

Sorry to laugh. This really appeared to be sent to the wrong person. I'm rolling... yes, we should ignore this one. Oh my.

This is turning into a computer internet bar fight, everything goes, get out my chair ?

 

That means, "get out OF my chair" in the Philippines. Trust me, I know.

Edited May 23, 2022 by GDMike

[RXB]

100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 Z=1
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

56 minutes ago, InsaneMultitasker said:

Huh?  I have no idea what you are trying to pin on me here.   I do not represent everyone else who responded to this thread, and my input certainly did not rise to the level of "refusing to ever admit I am wrong about anything".   I shared one response related to accuracy/precision that you appear to not believe, similar to your apparent refusal to address certain questions about your testing methods.

 

I agree, a computer can be better at timing an event, however, the TI clock as presented by you is NOT as accurate as stopwatch. Does it matter much with 100s or 1,000s of iterations? Not really, as others have so eloquently explained.

 

The impudence is astounding.  I am done here.

How is my shown test method flawed?

Please explain why it would not work or be less accurate then a stop watch and your finger?

 

 

[pixelpedant]

My Contribution to the Bickering Old Men Bonanza:

 

Using RTC values to compute command speed is better because I am lazy and easily distracted, and don't feel like sitting around with a stopwatch

 

Ipso facto

 

Quod erat demonstrandum

[RXB]

Right I am a Tech nerd and when someone uses Race horse tech in place of computer it kind of ruffles me up.

[oddemann]

I am astounded that people find ways to "fight" again and again, about trying to learn and get better at TI BASIC. It is boring trying to sort stuff, to keep learning!

I am thinking that there might have to be active moderation when it ends up like this, again and again. So much garb to read! I get bored and "why bother!"

 

This is now, "Another tread not worth using time on!"

[Reciprocating Bill]

And it's always wise to avoid barking up a dead horse.

[GDMike]

We need a filter in place then a response can be made. Lol