0 Members and 2 Guests are viewing this topic.
How large of numbers do we have to handle?[/li][/list]
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]
Is there some limit on program size, or does size somehow factor into judging?[/li][/list]
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]
And a non-technical question, can we submit entries for multiple platforms/languages?[/li][/list]
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?
Hello,We have disccused yesterday evening about the issue [of asm/basic being judged the same way]In the z80 category :we receive valid ASM and Basic entriesthe majority of ASM entries would yield faster results than Basic onesSo, 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.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.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.