Ratio speed:size |
70:30 |
|
50% |
[ 8 ] |
75:25 |
|
6% |
[ 1 ] |
80:20 |
|
12% |
[ 2 ] |
85:15 |
|
0% |
[ 0 ] |
90:10 |
|
31% |
[ 5 ] |
|
Total Votes : 16 |
|
On my TI83 Premium CE, I imagined an algorithm named SORTA which occupies
97 bytes
and takes
3.80 ± 0.01 seconds (according to PT_'s timer)
Mine is now 53 bytes but 3 minutes long
Good !
I'd like to shorten again the length of my program in order to be less than 90 bytes
Dumb me
I suddenly realized that people can get <0 points for score...
That is why I'm changing the score points. Now it would be like this:
70*best_time/time, and for the size
30*best_size/size
Good luck you all, and don't be frustated if you don't reach a fair time. This is only task 1
Is the list supposed ti contain 256 different numbers?
sting251 wrote:
Is the list supposed ti contain 256 different numbers?
Nope, otherwise you can just output the 256 different numbers.
Do is there an amount if numbers in the list?
sting251 wrote:
Do is there an amount if numbers in the list?
Please take a look at my post in page 2, which explains the competition. There are 256 elements in the list, each with a number random from 1 to 256.
I heard of the fact that some of you are struggling with the ratio speed:size.
That is why I will add a poll, with some other possibilites. After a week, the choice with the most votes becomes the score ranking. I hope you will respect it.
Will the programs be run with a clear VAT? If not, it could make a significant difference in speed. I can save about 4% speed with my new approach if the VAT is mostly cleared.
Whether you reset the calc or not, be sure to be consistent between each entry.
Pieman7373 wrote:
Mine doesn't even finish yet...
Keep trying! I did it; so can you!
PT, do you enter the numers in list or do i
im confused
caleb1997 wrote:
Pieman7373 wrote:
Mine doesn't even finish yet...
Keep trying! I did it; so can you!
But my program derped and turned itself into hundreds of lines of random crap and symbols, when the original prgm was maybe 20 lines max. :,(
Update:
77 bytes with name SORT3
1 minute and 37.62 seconds to do 256 elements once.
Odd... Shouldn't it take less time to do it, since it's smaller? Before, it was 1:36 and 92 bytes; now, it's 77 with 1:37...... ???
EDIT: Now 76 bytes (with the same name) and 1 minute and 37.3 seconds. 9 lines of code.
EDIT #2: Now 68 bytes and 1 minute and 37.13 seconds. 9 lines of code.
Might be random fluctuations, if you're sorting different lists. Or it might be that your algorithm is less efficient for some other reason, even though it takes fewer bytes to write out.
Caleb, the number of bytes although generally bearing a slight correlation to speed does not really affect it much when it comes to these things, for small programs like this, what the code actually does has a much larger impact of the speed especially because your program (probably) runs the code through a loop 256 times. For example, my program is only 48 bytes long, I could theoretically bring it down to 47, however this would cause about a 25% decrease in speed, which is why I don't do it. On the other hand, StarTrek's initial code was in the 90 bytes range and took over 20 minutes on a ti-84 + SE (that's what he claimed) while Lirto's code, who was similar in size at first, took in the 10 seconds range so we can see at this point that the size of the program is not what is making it slower or faster (however, when coding larger things, the correlation can usually be observed more clearly.)
Many, many thanks to @grosged, I've made a very accurate timer. It uses the
Watchdog Timer, if you're interested. The usage is *simple*: at the beginning of your program, call
Asm(prgmSTART, and at the end
Asm(prgmSTOP. That last program will display 2 numbers of about 10^8, this should be right. Now, after running, calculate your time with the following formula:
To be more clear, I've made a test program with the following code:
Code: Asm(prgmSTART
Asm(prgmSTOP
I cleared the homescreen, and ran the program. The result is this:
This is right!
Now I have the following formula:
I will post soon the programs!
Ooh, how are your sorting algorithms going?
EDIT: here you are:
https://drive.google.com/folderview?id=0B04k6sSJXdpIMjhFNFFfS2hLY0E&usp=sharing
I didn't change the names of the programs, but EXAMPLE starts the timer, and EXAMPLE2 reads it. The formula is still the same.
Oh, and another thing: that timer is a bit limited... according to the calculations of @grosged, you can go upto 8.5 minuts Good luck with the last days before a new task (tuesday)!
EDIT2: I've included the source code, if it doesn't work for you
https://drive.google.com/folderview?id=0B04k6sSJXdpIMjhFNFFfS2hLY0E&usp=sharing
If my calculations are right, you can use this timer for about 36 hours (2^32/32768/60/60), so be trusted
I'm glad to have helped you
I'm eager to use your program
Meanwhile, using mine, I notice that my program (named SORTA) doesn't take 5 but 4.3 seconds
EDIT: now 3.80 ± 0.01 seconds , 97 bytes
Strangely, my 57 bytes beat you all but my time performance is clearely lame
I'm interested to see how fast we can get a sorting algorithm that works for list entries in [1,1000000].
Here are my times (accurate to 0.2 s, average of five) and sizes:
Code: Vsn Time (s) Size (bytes)
B1 38 ~300
B2 32.8 296
B3 28.8 ~300
As in my other post, times were measured with jsTIfied running 2.55MP.