Are you sure what they're doing is legal? They go beyond lack of attribution, and actually claim the programs are their own:
Quote
Make math and science easier (and more fun) with free graphing calculator programs and games from calculatorti.com. You can make the process of transfering the application to your calculator sweet and simple with Texas Instrument's handy TI connect software. Install it on your computer and grab your GraphLink Connection cable (USB cable) to plug in your calculator. Then you can start downloading any of our programs and games (Wow! There's a lot!) from our libraries to transfer and install them to your calculator. Have fun!
PT_: I'm impressed! My own solution using ΔList(cumSum( was 44 bytes because I forgot to take the ΔList(cumSum( out of the augment(. Combining my solution and yours, we have this in 42 bytes, which seems to be optimal:
Input N int(10fPart(.1N10^(iPart(seq(A,A,~log(N),0 While N≠max(Ans ∆List(cumSum(augment(Ans,{sum(Ans End N=max(Ans
It's actually funny how slow my solution is. I'm testing it out now, and it's taken 30 minutes for two-thirds of a frame. It also runs in O(n2) time where n is the number of pixels on the screen, so if you try it on a CSE while changing the numbers around so it takes up the whole graph screen, it'll take about two days per frame-- if it even works, which I suspect it won't for a different reason.
EDIT: Two things.
First, the spec should add that every possible combination of cells should be supported (to disallow TI-BASIC answers that store all live points in a list and thus won't work with more than 999).
Second, my solution seems to work. I've been testing it for about six hours, and I'm starting to get blocks and blinkers, and even one LWSS!
I saved one byte by halving the speed of the program, so now it's an hour and a half per frame (at 15 MHz), or about one pixel per second. This is ridiculous.
I think I know what my approach (in Ti-BASIC) will be. It will be very slow when golfed completely, and I don't think we should expect any of these to be of practical speed.
Do you mean CSE BASIC for the screen limitations?
I think you should specify a minimum screen size, because on any machine without a screen the solution is trivial: since there are no pixels, do nothing.
Here are some of my attempts at this contest, in chronological order, along with explanations.
Spoiler For 40 byte solution:
While 1 getKey If Ans Y-i^sum(cumSum(Ans={85,41,81→Y Pxl-On(imag(Y),real(Y End
This was my first real (after working for an hour or so) solution once I fixed key repeat by using WASD instead of arrow keys. I had tried using two separate variables, but it seemed that using the complex plane would be smaller, even considering the two-byte cost of the real( and imag( tokens, because raising i to a power eliminates the cost of looking up the cursor change corresponding to a particular key. You can see that up, left, down, and right correspond to W, A, S, and D keys, which are key codes 85, 41, 81, and 51 respectively.
Spoiler For 33 byte solution:
While 1 getKey If Ans Y-i^int(4fPart(Ans/7→Y Pxl-On(real(Y),-imag(Y End
I began thinking about the fact that we could assume WASD are the only pressed keys, and found I could abuse it here. The WASD key codes are all different modulo 7, so taking i to that power would give 1, i, -1, and -i; luckily, they came in the right order.
Spoiler For 31 byte solution:
While 1 getKey If Ans Y-i^int(4cos(8Ans→Y Pxl-On(real(Y),imag(Y End
Same sort of idea as the previous solution, but I used a "randomizer" function, because I knew the cosines of large interger numbers would be unpredictable. I basically searched through every token and every multiplier in the book, and finally found one that worked. These changes saved one byte in the Y-modifying line, and one from not needing to negate the imag(.
I started to think I was done golfing, but then I saw that, with a mathematical way to ignore a getKey value of zero, I could eliminate the If Ans line, and if I only used one getKey, I could include it in the algorithm and also store the cursor position in Ans instead of Y, saving five bytes.
Spoiler For 27 byte solution:
While 1 Ans-iPart(i^int(48ln(getKey-1 Pxl-On(real(Ans),imag(Ans End
This one is honestly just magic.
Spoiler For 26 byte "solution":
If it weren't for rounding errors causing the cursor to move to the side every trillion keypresses, I would be able to eliminate the iPart(:
26 bytes: While 1 Ans+i^int(28ln(getKey-1 Pt-On(real(Ans),imag(Ans End
And of course replacing the While 1 with recursion would save another two bytes, but crash after a few seconds.
The 1070 57-byte solutions I had in mind were all the 26-byte one (before I knew it was invalid), but with the 1 in While 1 replaced with length("[some 30-byte string], of which there are about 245^30 because there are about 245 printable one-byte tokens.
Show Posts
