ARTICLE 6: Staffing
Competitions organized by TI-Planet will feature several awards. All lots, specified below
below, will be shared between the events of the competition.
● 5x (five) TI-Nspire CX CAS (unit value: 150 €)
● 3x (three) TI-Nspire CX (unit value: € 13 0)
● 2x (two) TI-84 Pocket.fr (unit value: 100 €)
● 3x (three) TI-83 Plus.fr (unit value: € 90)
● 3x (three) TI-82 Stats.fr (unit value: € 70)
● 3x (three) TI-Collège Plus (unit value: € 18)
The website reserves the right to add additional lots.
Ok I'm confused. The PDF lists the prizes as:Quote from: The rules translatedARTICLE 6: Staffing
Competitions organized by TI-Planet will feature several awards. All lots, specified below
below, will be shared between the events of the competition.
● 5x (five) TI-Nspire CX CAS (unit value: 150 €)
● 3x (three) TI-Nspire CX (unit value: € 13 0)
● 2x (two) TI-84 Pocket.fr (unit value: 100 €)
● 3x (three) TI-83 Plus.fr (unit value: € 90)
● 3x (three) TI-82 Stats.fr (unit value: € 70)
● 3x (three) TI-Collège Plus (unit value: € 18)
The website reserves the right to add additional lots.
Your post however only lists two prizes. Which is correct?
I also want a clarification, are there only two categories? One being Nspire and one being Z80? It looks as though all Z80 regardless of language is being judged together. If someone who's judging could answer, that'd be great.
What size numbers should we be expected to handle? 16-bit?Well, we'll test against several numbers, from low to mid to big ones, so ... :P
Are we allowed to ask how big the biggest numbers are? ;DWhat size numbers should we be expected to handle? 16-bit?Well, we'll test against several numbers, from low to mid to big ones, so ... :P
mathematics
How large of numbers do we have to handle?[/li][/list]We did not specify a specific range. We'll test against a number of values (positive integers), from small to bigger ones.
How will speed be measured? Does our algorithm need to be fast for small numbers, large numbers, or both? If both, does one matter more than the other?[/li][/list]I guess we'll be measuring speed among the same kind of programs, by launching them with the same number, and measuring with a chronometer each one, from the "enter" key pressed to the end of the program. We'll do that, as said, for multiple numbers ranging from small to bigger ones.
Is there some limit on program size, or does size somehow factor into judging?[/li][/list]We did not specify any program size, since we'll mainly test against speed. However, a 1k (<- I just invented this size) program will probably have a better grade than a 10k one...
Can we use pre-calculated data that isn't a list of prime palindromes? And if so, is there a limit to what/how much we can use?[/li][/list]There was discussion too about this on TI-Planet, what got out of that was that as long as it's mainly not a list of "things" (palindromes, directly, primes directly, or RLE-encoded things) that would be used to search through ( / parse / decode ) to directly give the answer for the requested number.
And a non-technical question, can we submit entries for multiple platforms/languages?[/li][/list]Nope, sorry.
EDIT: One more question, can we store some prime palindromes as long as it's not just a straightforward list of them? If so, are there restrictions?See my previous answer, I guess ?
Hello,
We have disccused yesterday evening about the issue [of asm/basic being judged the same way]
In the z80 category :So, we are ready to actually make it so there are 3 categories ((TI-Basic z80, Asm z80, TI-Nspire)), and so we add another TI-84 Pocket.fr to win.
- we receive valid ASM and Basic entries
- the majority of ASM entries would yield faster results than Basic ones
That should appease your fear, and you should't worry any more about a possible unfairness, of course if we receive quality ASM entries.
A hybrid program (asm + basic) will be considered ASM.
For now, we only have received one entry, and we couldn't really compare anything.
About the size thing again, surely there must be some established limit? For instance, the Ans variable on the 82/83/84 can only store integers up to 14 digits without loss of information, so there has to be at least a hard limit for that. And chances are finding nth palindromes that are that long would take far too long anyways. It would also be helpful for assembly programmers to know a limit; it doesn't seem right to leave us in the dark in a speed competition, encouraging us to gamble on using smaller numbers for faster math. Someone may have an advantage just because they guessed the minimal number size that still works, and someone else's efforts may completely be wasted if they used numbers slightly too small and their program ended up not passing the tests at all.I completely agree with you about the first paragraph, however for the details about notation, I'd let Critor and/or Lionel reply.
Another follow-up question, can we get a bit more information about how scoring will work? I'm especially wondering about things like how speed for varying number sizes will be scored. How will the speed of assembly programs be compared for small values, considering they may complete the computation in a fraction of a second? And if one program uses a heavy but high-end-optimized algorithm that takes, say, 0.7 seconds, 2 seconds, 8 seconds, and 36 seconds on tests while another program that uses a lighter but less high-end-optimized algorithm takes 0.2 seconds, 0.7 seconds, 5 seconds, and 114 seconds for the same tests, which would win?
I guess I have one or two more questions for now... Sorry for the slew of questions but hopefully they'll help clear things up for people besides myself as well.
- I'm assuming that we are allowed to pre-calculate and store the values of the first few prime palindromes, like the ones with 2 or fewer digits (2, 3, 5, 7, 11), correct? Some algorithms can't really find some of these on their own and instead depend upon them being given. Storing these special cases should take less space and running time than modifying the algorithm to find them itself, and in some ways modifying the algorithm to find specific values is more or less the same thing, right?
- Related to the question above, should we agree upon some hard rule about what values can be pre-calculated and stored? I assume this rule would either have to allow a precise set of values or an maximum amount of values.
I guess I have one or two more questions for now... Sorry for the slew of questions but hopefully they'll help clear things up for people besides myself as well.
- I'm assuming that we are allowed to pre-calculate and store the values of the first few prime palindromes, like the ones with 2 or fewer digits (2, 3, 5, 7, 11), correct? Some algorithms can't really find some of these on their own and instead depend upon them being given. Storing these special cases should take less space and running time than modifying the algorithm to find them itself, and in some ways modifying the algorithm to find specific values is more or less the same thing, right?
- Related to the question above, should we agree upon some hard rule about what values can be pre-calculated and stored? I assume this rule would either have to allow a precise set of values or an maximum amount of values.
Dapianokid said his took 11 seconds to compute the 42nd prime palindrome, but from the conversation, he may have a much more efficient algorithm for larger values. I think his was also running at 150MHz, so I am not sure.
Has anybody set any benchmarks for other languages?
Lol I'm currently using the exact same algorithm as in BASIC and now it takes 4.5 secs to find the 1000th prime (15mhz Axe). :PBut palindromic too ? :P
Although I don't see mention of it, the first post list all its examples in decimal. Judging by that, I'd say that they want the output in decimal format.I understand this, what I was asking was if we were allowed to use numbers that are palindromes in binary but that was just a joke. :P
Can we pre-calculate and store answers that aren't the very first values, as long as it's not a straightforward list of all the answers? I had an idea of speeding mine up by storing, say, every 100th prime palindrome and using them as base points for calculations to reduce computation time for large inputs/outputs. If this isn't allowed, I think it should probably be made clear that except for a few starting values, your algorithm must go through all prime palindromes to get up to the target.
EDIT: Also, do we have an official ruling yet on the largest input our programs need to work on? They could certainly be different for different platforms/languages, but establishing some would be really nice.
I have a question: What program do we submit if we're doing Axe? The compiled executable, or the source?You'd have to give both.
I assume this applies to z80 assembly also?I have a question: What program do we submit if we're doing Axe? The compiled executable, or the source?You'd have to give both.
So, my calculation of "300 per second" was off by quite a bit. I forgot to calculate in non-primes and the wasted cycles there :P I only get about 30 primes per second, but my algorithm could be better refined XDAccording to my calculations, this is almost exactly the worst-case speed I am getting (29.78 pps). :o
(And this is at 6MHz)
Edit: Runer suggested that I don't post timings so as not to discourage anyone, so I'll just say that my program can get the 5953rd palprime in under an hour. ;)Lol, that is too late, I got discouraged when I learnt that Runer and you were participating, no need to post your timings :P