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

[pixelpedant]

Yes, I believe the answer, on whether numeric constants or variables are faster is "it depends". 

 

Given that the integer constant is just a string containing a textual representation of a decimal number, this isn't directly machine-readable numeric data either, and that will presumably have its own cost. 

 

In my testing, the speed with which an equation containing a numeric constant is evaluated is proportional to the textual length of decimal constant. 

 

While the speed with which an equation containing a numeric variable is evaluated is, as one would expect, independent of any decimal representation or the value's scale. 

 

So while "Z=1+X" is evaluated faster than "Z=Q+X" when Q=1, the tables are turned if we set Q to -32343252. 

 

With this much larger value, Z=Q+X is just as fast as it ever was.  But now, "Z=-32343252+X" is substantially slower. 

 

So in my testing

 

Z=1+X (6.33ms)

Z=Q+X (where Q=1) (7ms)

Z=Q+X (where Q=-32343252) (7ms)

Z=-32343252+X (9ms)

 

Such are the oddities of a BASIC where nothing is really ever an integer, I suppose. 

 

[RXB]

2 hours ago, senior_falcon said:

I see the opposite. Looping 4000 times:

Z=A  32 seconds

Z=1  37 seconds

 

Bottom line is that it is pretty close either way.

 

Of course, I don't trust the times that my computer gives, and after seeing the results you posted in "BYTE MAGAZINE SIEVE BENCHMARK" or in "BENCHMARKING LANGUAGES", I definitely would not trust your times. Unless you have determined what was causing the anomalous results in the video and are getting results that agree with a real TI99. (As I noted in my post #219 in benchmarking languages "Here's the thing. As far as I can tell, your video shows a test that should yield valid results." Yet the video in your post #216 clearly shows that it does not.)

So you think you using a stop watch is more accurate then using the clock access times it is tied to the hardware?

You can test this with Classic99 vs real iron and it will be very very close.

I really doubt your human reactions times would provide much of a contest, besides my test was 6000 times more loops.

[senior_falcon]

3 hours ago, RXB said:

So you think you using a stop watch is more accurate then using the clock access times it is tied to the hardware?

You can test this with Classic99 vs real iron and it will be very very close.

I really doubt your human reactions times would provide much of a contest, besides my test was 6000 times more loops.

Do you really have that short a memory? Go back and re-read the threads "BYTE MAGAZINE SIEVE BENCHMARK" and "BENCHMARKING LANGUAGES".

In "Byte Magazine Sieve Benchmark", post #43 you give results for looping 10,000 times. The very next post you run the same program 100,000 times. That is 10x more loops, yet it only takes 3x longer. Does that seem right to you?

In the video you post in "Benchmarking Languages", post #216, you show a detailed video that yields results that bear no resemblance to the results obtained on a real TI99 and posted by Rasmus and Reciprocating Bill (his post is #45 in Sieve Benchmark)

So for some reason Classic99 running on your computer gives inaccurate results. This is an observation, not a criticism.

The bottom line is that, until you can run the test programs shown in post #216 and get results that match a real TI99, any speed tests you post are probably not accurate. (That goes for me too. My tests on Classic99 are somewhat closer to a real TI99, but not accurate enough to be reliable.)

[Reciprocating Bill]

On real hardware* and RXB 2022, 10000 iterations, I get 1' 12" for Z=1 and 1' 14" for Z=A. Stopwatch timing, which is likely to introduce about 1/4 second of measurement error. 

 

For 4000 iterations, I get 29 seconds for Z=1 and 30.1 seconds for the Z=A. (It is worth nothing that as iterations increase, measurement error from the use of a stopwatch becomes proportionately less significant.)

 

Also, this is an instance in which TI BASIC is faster than Extended Basic. For 10,000 iterations TI BASIC required 56.7 seconds for Z=1 and 56.9 for Z=A (i.e. no difference).

 

*16-bit RAM in console.

 

 

[RXB]

13 hours ago, senior_falcon said:

Do you really have that short a memory? Go back and re-read the threads "BYTE MAGAZINE SIEVE BENCHMARK" and "BENCHMARKING LANGUAGES".

In "Byte Magazine Sieve Benchmark", post #43 you give results for looping 10,000 times. The very next post you run the same program 100,000 times. That is 10x more loops, yet it only takes 3x longer. Does that seem right to you?

In the video you post in "Benchmarking Languages", post #216, you show a detailed video that yields results that bear no resemblance to the results obtained on a real TI99 and posted by Rasmus and Reciprocating Bill (his post is #45 in Sieve Benchmark)

So for some reason Classic99 running on your computer gives inaccurate results. This is an observation, not a criticism.

The bottom line is that, until you can run the test programs shown in post #216 and get results that match a real TI99, any speed tests you post are probably not accurate. (That goes for me too. My tests on Classic99 are somewhat closer to a real TI99, but not accurate enough to be reliable.)

This is YOUR OPINION not based on any testing.

Show me how off Classic99 is please.

Many of us want to see this proof you might have that no one else seems to know about?

[RXB]

1 hour ago, Reciprocating Bill said:

On real hardware* and RXB 2022, 10000 iterations, I get 1' 12" for Z=1 and 1' 14" for Z=A. Stopwatch timing, which is likely to introduce about 1/4 second of measurement error. 

 

For 4000 iterations, I get 29 seconds for Z=1 and 30.1 seconds for the Z=A. (It is worth nothing that as iterations increase, measurement error from the use of a stopwatch becomes proportionately less significant.)

 

Also, this is an instance in which TI BASIC is faster than Extended Basic. For 10,000 iterations TI BASIC required 56.7 seconds for Z=1 and 56.9 for Z=A (i.e. no difference).

 

*16-bit RAM in console.

 

 

Classic99 is based on Clock cycles and the CPU speed is very very accurate as you can set your computer clock on it

and will be very accurate. Matter of fact trying to make a working accurate clock on the TI99/4A was a fools errand

for many and why we got a clock card that did not suck.

It sounds like you think 40 year old tech is magically more accurate with a stop watch then actual hardware designed for the task?

 

Now as for number of loops the more loops you do the more vast you see the numbers between routines.

Doing a loop of 100 with a stop watch vs a hard ware clock is laughable.

Really 1/4 of a second do you think that as scientific vs hardware designed around CPU clock and accessed by it before and after a routine?

[RXB]

If I remove the SAMS card in my TI99/4A and only use the timing routine as I used above do you think when I use TIPI clock it will be wrong?

But standing next to my Console with a Stop Watch will be much more accurate?

 

I am sorry but you sound like the argument for a Divining Rod Saleman.

[Reciprocating Bill]

29 minutes ago, RXB said:

It sounds like you think 40 year old tech is magically more accurate with a stop watch then actual hardware designed for the task?

Vis timing methods, the measurement error resulting from the use of a stopwatch isn't significant.  The numbers I got are accurrate to about +- 1/4 second, as that is reaction time. When measuring a process that takes more than a 70+ seconds, that amounts to less than 1% error. Accurate enough for the purpose.

 

Of course, running the benchmarks on 40 year old hardware is the best way to determine how it runs on 40 year old hardware. I don't know about you, but that's what I want to know. 

[RXB]

2 hours ago, Reciprocating Bill said:

Vis timing methods, the measurement error resulting from the use of a stopwatch isn't significant.  The numbers I got are accurrate to about +- 1/4 second, as that is reaction time. When measuring a process that takes more than a 70+ seconds, that amounts to less than 1% error. Accurate enough for the purpose.

 

Of course, running the benchmarks on 40 year old hardware is the best way to determine how it runs on 40 year old hardware. I don't know about you, but that's what I want to know. 

So you really think your reaction time is not a factor vs hardware designed for it?

 

I am sorry but you sound like the argument for a Divining Rod Saleman.

 

And if you have proof of this anti science view please post proof!

Personally I think computers and clocks are much more scientifically accurate then you and your stop watch.

[Reciprocating Bill]

56 minutes ago, RXB said:

So you really thing your reaction time is not a factor vs hardware designed for it?

Not a significant factor relative to my current purposes. And when large discrepancies arise between measurements, certainly not sufficient to explain those discrepancies. For that we have to look elsewhere. 

Edited May 22, 2022 by Reciprocating Bill

[RXB]

28 minutes ago, Reciprocating Bill said:

Not a significant factor relative to my current purposes. And when large discrepancies arise between measurements, certainly not sufficient to explain those discrepancies. For that we have to look elsewhere. 

What discrepancies?

You have provided no proof?

I at least show my test and not one single time have you done so?

I have to take your word for it using a stop watch? 

Yet I provide a example you can do yourself and you can use 5 other PC of different makes and get same results from them using Classic99!

 

Honestly your opinion is not very valid or useful, let alone provides any factual proof of your results.

Unlike my presentations.

[+OLD CS1]

A measurement can be precise and lack accuracy.  A 1/4 second reaction time may throw off the accuracy of a measurement, but so long as your measurements are consistently inaccurate, they can be considered precise.  For instance, whether a run of 10,000 iterations takes 1.17s or 1.42s, so long as this remains over several samples and relativity to various controls remains within a margin of error, whatever method you choose may be considered to produce usable results.

 

So if the measurements run-time relative differences between string manipulation and numeric literal manipulation is consistently 1.4% irrespective of the method of measurement, we can reasonably assume the difference is 1.4%.  Obviously, my numbers are arbitrary and for demonstration and do not reflect any of the measurements previously reported.

[+InsaneMultitasker]

A few thoughts and/or questions came to mind as I read through the posts.

 

Regarding tight space, do all of the boolean variables need to be "active" at any given time?   Or is a subset sufficient based on the current 'level'?   If the level flags can be compressed (into a string or a prime numeric) during level changes, and decompressed to say 10 simpler numeric variables (or simple strings) as the level changes, that might give you some wiggle room and best speed/space ratio.

 

Along these same lines of thought, for boolean testing, SGN is an option though I think it is probably faster to use the numeric variable itself, i.e., "IF X THEN 200", provided the value is 0 or 1, to get a result. 

[Reciprocating Bill]

I'm not sure what you're going on about, Rich, or for what you want proof. 

 

On my console, 10,000 iterations of your benchmark run in ~72 seconds for Z=1 and ~74 seconds for Z=A. Not very different. A stopwatch is required to measure performance on my real iron, and that's what I'm interested in. 

 

Do you suspect that I am (for some reason) deliberately reporting incorrect numbers, or that I'm not competent to time a process with a stopwatch? 

[RXB]

1 hour ago, Reciprocating Bill said:

I'm not sure what you're going on about, Rich, or for what you want proof. 

 

On my console, 10,000 iterations of your benchmark run in ~72 seconds for Z=1 and ~74 seconds for Z=A. Not very different. A stopwatch is required to measure performance on my real iron, and that's what I'm interested in. 

 

Do you suspect that I am (for some reason) deliberately reporting incorrect numbers, or that I'm not competent to time a process with a stopwatch? 

Your report is based on many erroneous assumptions not on any factual science first your own opinion and who else can check this?

You seem to hate hardware clocks for checking your accuracy and prefer your own reaction time as if all of science world wide should adopt your view.

A hardware clock can be accessed with the Triple Tech card or a TIPI has one, both of which are 1000 times more accurate then you and a stop watch.

[+InsaneMultitasker]

The hardware clock reports HH:MM:SS.  There is a possible 2s variance between starting and stopping an event.  Even with a 1/2 second human reaction time,a stopwatch may still be more precise than the hardware clock output.  Perhaps we should return to the topic's topic.

 

 

[+FarmerPotato]

Since POS and SEG$ have been covered, I’m thinking of others:

REM INITIAL VALUES PART OF PLAYING FIELD
A$="a a  a   a  aa"
CALL COLOR(9,1,1)
PRINT A$ 
REM TEST
I=3
CALL GCHAR(24,I,F)
IF F>32 THEN ...
REM SET
CALL HCHAR(24,I,97)

This avoids the string stack by doing VDP access to the screen. Could use chars 31 and 32 instead. Bonus side effect if there is a use for visible graphic chars (literal flags or lights!)

 

 

[pixelpedant]

Yeah, given that CALL GCHAR is almost as fast as SEG$ (which doesn't actually get you a numeric value - it just gets you a string from which you can derive one), a CALL GCHAR is often going to be faster than a SEG$+ASC.  CALL GCHAR's performance is also more consistent than SEG$ (inevitably, given the size of the needle and haystack vary, in the latter's case), which may be desirable, when precisely timing a program. 

 

In a program that uses PRINT a lot, you've usually got 96 unused screen locations to spare, so those could be exploited in this sort of context. 

[senior_falcon]

4 hours ago, RXB said:

This is YOUR OPINION not based on any testing.

Show me how off Classic99 is please.

Many of us want to see this proof you might have that no one else seems to know about?

WRONG! It is based on testing, and YOU did the testing.

In post #43 you quote Rasmus:

 

(Rasmus)

These are my results using Classic99 QI399.057:

TI BASIC: 10:24

XB: 3:43

RXB 2022A: 8:39

 

(RXB response)

I ran this test multiple times with same results: (this was looping 10000 times)

TI Basic 13 Minute 44 seconds

XB  13 Minute 9 seconds

XB 2.9 13 Minute 9 seconds

RXB 2022A 13 Minute 8 seconds

 

I trust that even you would have to agree that the results are not even close to being the same.

 

(RXB post #44)

OK RAN A 100000 LOOP TEST SO RESULTS ARE:

XB       = 37 Minutes 5 Seconds

XB 2.9 = 37 Minutes 6 Seconds

RXB     = 26 Minutes 2 Seconds

 

Please explain how looping 10 times as much only takes 3x longer for XB and 2x longer for RXB?

 

The text you wrote in #216 was:

"I wanted to dispute that RXB was slowest in CALL CLEAR so showed a test proving it was not.

This is to show FOR NEXT is very very consistant per any XB variant on the TI99/4A"

 

Naturally I assumed that this test was comparing the speeds of CALL CLEAR. Turns out it only tests the speed of a FOR/NEXT loop. The results here are fairly close to an actual TI running XB and TI BASIC. I apologize for misunderstanding what was being shown, but you have to admit that your text is confusing.

 

You still have to explain the strange results from your post #43 and #44.

 

 

[RXB]

2 hours ago, InsaneMultitasker said:

The hardware clock reports HH:MM:SS.  There is a possible 2s variance between starting and stopping an event.  Even with a 1/2 second human reaction time,a stopwatch may still be more precise than the hardware clock output.  Perhaps we should return to the topic's topic.

 

 

LOL you just to refuse to admit you are wrong?

Like machine are slower then humans, which is not even remotely true.

[RXB]

1 hour ago, pixelpedant said:

Yeah, given that CALL GCHAR is almost as fast as SEG$ (which doesn't actually get you a numeric value - it just gets you a string from which you can derive one), a CALL GCHAR is often going to be faster than a SEG$+ASC.  CALL GCHAR's performance is also more consistent than SEG$ (inevitably, given the size of the needle and haystack vary, in the latter's case), which may be desirable, when precisely timing a program. 

 

In a program that uses PRINT a lot, you've usually got 96 unused screen locations to spare, so those could be exploited in this sort of context. 

Yea true, I converted GCHAR to Assembly and there was just not useable speed difference.

CALL HGET is in assembly for stings from screen, but GCHAR just works fast enough to leave as GPL.

[RXB]

1 hour ago, senior_falcon said:

WRONG! It is based on testing, and YOU did the testing.

In post #43 you quote Rasmus:

 

(Rasmus)

These are my results using Classic99 QI399.057:

TI BASIC: 10:24

XB: 3:43

RXB 2022A: 8:39

 

(RXB response)

I ran this test multiple times with same results: (this was looping 10000 times)

TI Basic 13 Minute 44 seconds

XB  13 Minute 9 seconds

XB 2.9 13 Minute 9 seconds

RXB 2022A 13 Minute 8 seconds

 

I trust that even you would have to agree that the results are not even close to being the same.

 

(RXB post #44)

OK RAN A 100000 LOOP TEST SO RESULTS ARE:

XB       = 37 Minutes 5 Seconds

XB 2.9 = 37 Minutes 6 Seconds

RXB     = 26 Minutes 2 Seconds

 

Please explain how looping 10 times as much only takes 3x longer for XB and 2x longer for RXB?

 

The text you wrote in #216 was:

"I wanted to dispute that RXB was slowest in CALL CLEAR so showed a test proving it was not.

This is to show FOR NEXT is very very consistant per any XB variant on the TI99/4A"

 

Naturally I assumed that this test was comparing the speeds of CALL CLEAR. Turns out it only tests the speed of a FOR/NEXT loop. The results here are fairly close to an actual TI running XB and TI BASIC. I apologize for misunderstanding what was being shown, but you have to admit that your text is confusing.

 

You still have to explain the strange results from your post #43 and #44.

 

 

Yea maybe I made a mistake and I do admit when wrong.

It is true the ALL >80 in GPL was about the same as an Assembly version of it so switched back to GPL version original.

CALL CLEARPRINT on the other hand has to be Assembly instead. (Clears columns 2 to 23 from row 1 to 24

[+InsaneMultitasker]

1 hour ago, RXB said:

LOL you just to refuse to admit you are wrong?

Like machine are slower then humans, which is not even remotely true.

You may have me confused with another poster. Regardless, machine speed and human speed have little to do with my earlier statement.  Whether the machine is faster [than a human] is not relevant to which is presenting the better measurement.  A typical stopwatch is precise to the tenth or hundredth of a second; the TI clock in the above tests is only precise to the total seconds.  Unless the human is greatly distracted, the stopwatch will always be more accurate.

 

4 hours ago, FarmerPotato said:

This avoids the string stack by doing VDP access to the screen. Could use chars 31 and 32 instead. Bonus side effect if there is a use for visible graphic chars (literal flags or lights!)

Neat idea for bypassing the stack.  Call COLOR could mask the characters from being visible.  Too bad call charpat isn't available in basic to retrieve character patterns, so that call char could store compressed info in the patterns.

[+FarmerPotato]

37 minutes ago, InsaneMultitasker said:

 

 

Neat idea for bypassing the stack.  Call COLOR could mask the characters from being visible.  Too bad call charpat isn't available in basic to retrieve character patterns, so that call char could store compressed info in the patterns.

Yeah, CHARPAT would let you retrieve bit flags.  It's available with Mini-Memory plugged in, along with POKEV, PEEKV.  

 

I imagined that under XB you could store flags in sprite patterns - CALL COINC(ALL) would tell you if any of a set of flags were set! Not helpful in a game that uses sprites in general. 

 

Here are some things I tried in MAME:

 

Using SEG$

FOR I=1 TO 10
FOR J=1 TO 8
F = VAL(SEG$(F$,J,1))
NEXT J
NEXT I

10 seconds

 

Without VAL

F$ = SEG$(F$,J,1)

5 seconds 

 

 

GCHAR

CALL GCHAR(23,J,F)

7.5 seconds

 

Unroll the J loop:

CALL GCHAR(23,3,F)
...
CALL GCHAR(23,11,F)

6.5 seconds

 

None of this takes into consideration the time to lookup variable names. (especially the unrolled loop.)

 

 

[HOME AUTOMATION]

I don't need a stop-watch, or another computer, to tell when I've been hood-winked!

 

Spoiler

  

 

...Just my eyeballs, and the button.