This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Adriweb
Pages: 1 ... 36 37 [38] 39 40 ... 115
556
« on: April 11, 2013, 05:26:00 am »
I imagine some on-calc game programming language for the Nspire coming out some day too (I have stuff lying around, main bottleneck is learning how to access the screen in nspire c) Well, that'd be Lua with an on-calc editor (even though I don't see the Nspire being a device to program directly on, but rather on the computer. The color, large screen makes it possible to create complex things, especially with a bigger power you can do more stuff with, it's largely easier to make programs on the computer)
557
« on: April 11, 2013, 05:22:00 am »
Nice  (I have pimathbrainiac too on my google results) For TI-Planet we have this ^^ 
558
« on: April 10, 2013, 03:29:32 pm »
In a previous news item, you could discover ahead of time on TI-Planet the latest beta of the new TI-Connect 4.0 linking software, adding support for the 84+ C Silver Edition calculator to the existing TI-Z80 and TI-68k support. More precisely, the showcased version was 4.0.0.209. Tonight, the final version, TI-Connect 4.0.0.218 was released. It represents the first update of the TI-Connect software for Windows since 2010! You can now transfer images and install OS upgrades to your 84+ C Silver Edition from Windows! (with the official software, that is - the third-party TILP II 1.17 software, which was recently published, already enabled doing it, provided the .8c? files were renamed to .8x?) One other thing : For a few days already, you were able to download, in exclusivity on TI-Planet, the OS v4.0 for the TI-84 Plus C Silver Edition! Indeed, a little tool by Critor was capable to create installable OS files from a ROM image of the calculator. In the previous news, TI-Connect 4.0 for Windows just came out. And like all the Windows versions of TI-Connect, it comes with a bundle of device-installable OS files, and here with the OS 4.0 for the brand new TI-84 Plus C Silver Edition. After an hexadecimal comparison of the files ignoring the headers, we can see that this OS 4.0's code is 100% identical that the one running on my sample TI-84 Plus C Silver Edition. Consequently, the OS bundled with TI-Connect 4.0 also suffers from all the bugs we noticed in our review some weeks ago.  The same goes for the 4.0 OS file available on TI's site, which is the same as TI-Connect 4.0 's one Enjoy!Links:TI-Connect 4.0.0.218 (English version)OS 4.0 - TI-84 Plus C Silver EditionSource : http://tiplanet.org/forum/viewtopic.php?t=11551&lang=en and http://tiplanet.org/forum/viewtopic.php?t=11550&lang=en
559
« on: April 10, 2013, 03:41:22 am »
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).
But palindromic too ?
560
« on: April 08, 2013, 05:48:00 pm »
So, after thinking a lot about it, I decided to start over with this. I generated a single checker in the top left, and bottom left, to get myself some values to base things on. THEN I wrote out the For( loops.
Should have done this from the beginning, was dumb to think I could simply modify code from Connect4 to immediately work in this.
But, it now drops them checkers on the board exactly where they should be. Thoughts?
Arggg my eyes !! Can you just make the red piecees another color ? It honestly really made my eyes hurt a little. I had to refocus "manually" on the center of the image to "see" the pieces correctly. maybe it's also the image that oes that and it's ok on calc ^^)
561
« on: April 06, 2013, 08:18:00 pm »
4750 : because on some topics, you do : 
562
« on: April 06, 2013, 07:12:35 pm »
third parties are not making Nspire BASIC programs on the computer side. Hmm, you mean other than using TINCS ? Because using the software is by far the most efficient way to create basic programs.
563
« on: April 06, 2013, 01:23:22 pm »
So still no response on how large the largest n-th they will throw at us?
Well, we don't know ourselves... When we try to make our own things, for testing purposes, we are, too, limited by the machine's BASIC limits. But our (critor's) algorithm is valid for any input. We have not coded anything for the z80 but e do know there are limits.... Just try to make something good enough for "relatively large" numbers (even though some small nmuerbs already take time to compute, so...)
564
« on: April 06, 2013, 10:14:49 am »
After discussion, the rule is that simple :
For the Nspire : Pure TI-basic only.
We'll try to be clearer next time, sorry.
565
« on: April 05, 2013, 11:50:25 am »
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 completely agree with you about the first paragraph, however for the details about notation, I'd let Critor and/or Lionel reply.
566
« on: April 05, 2013, 07:15:39 am »
I'm translating critor's post from TI-Planet ( http://tiplanet.org/forum/viewtopic.php?p=137928#p137928 ) 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 entries
- the majority of ASM entries would yield faster results than Basic ones
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.
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.
567
« on: April 05, 2013, 07:15:36 am »
I'm translating critor's post from TI-Planet ( http://tiplanet.org/forum/viewtopic.php?p=137928#p137928 ) 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 entries
- the majority of ASM entries would yield faster results than Basic ones
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.
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.
568
« on: April 05, 2013, 02:25:58 am »
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. About the second question, I guess it would have to work for both in order to have the maximum amount of points. But obviously, if your algorithm is the one (or one of the few) that really works well for big numbers, and relatively fast, well, that'll be good. 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 ?
569
« on: April 04, 2013, 06:58:29 pm »
That's indeed interesting  I love thigns like that happen ^^ (edit lol : }//else - weaponModel is not -1 but don't have a weapon? Oops, somehow G2 model wasn't removed?
//remove it on owner
if ( ent->weaponModel >= 0 ) if ( !deathScript && !(self->svFlags&SVF_KILLED_SELF) )
{
//Should no longer run scripts
//WARNING!!! DO NOT DO THIS WHILE RUNNING A SCRIPT, ICARUS WILL CRASH!!!
//FIXME: shouldn't ICARUS handle this internally?
ICARUS_FreeEnt(self);
}//TEMP HACK FOR PLAYER LOOK AT ENEMY CODE
//FIXME: move this to a player pain func?
)
570
« on: April 04, 2013, 05:08:12 pm »
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 ...
Pages: 1 ... 36 37 [38] 39 40 ... 115
|
Show Posts