For the dragon fractal challenge, this is 69 bytes, though I don't take credit since I started with Weregoose's 81-byte program. Still not jacobly's 66, but I think there's something in the fourth line to cut down.

Code:

Setup to roughly match jacobly's first pic is AxesOff:ZStandard:ZInteger:9->I:2->S:1->D:-12->X:-16->Y.

Counting the number of carries in an addition is 19 bytes if the addends are positive integers in A and B:

Code:


EDIT: I'm probably missing something obvious, but I still can't get 66. I concede.

This sort of code is way beyond me...
I guess the participants can figure out who has the smallest one on their own. It looks like lirtosiast's is the smallest but he said that Weregoose's was smaller. Which post is that code in (the one that's 66 bytes)?

Also, it seems that lirtosiast said that his was solution was indeed smaller, but he'd grant Weregoose the win as he used Weregoose's original code.

uhmmm Jacobly had the 66 bytes, Weregoose had the 81 bytes and Lirto had the 69 bytes...
Lirto's solution was not smaller than Jacobly's (however Jacobly has not posted it and has decided since he created the challenge, that his code wouldn't count)


As for the routines, they do seem a little obfuscated and convoluted, but I guess this is to be expected from a golfing competition with rather complicated challenges. And from what I've seen in the past, both Lirto and Weregoose are very good at creating very nice ti-basic routines

Here's the 66 byte program:

Code:

Note that I abused my own rules and had D be ±1 or ±i for the various directions.

Lirtosiast had the next smallest so can choose the next challenge.

Ah, I see. Compared to my revision of Weregoose's, you have
* +2 bytes for storing Y+Xi→Z
* -2 bytes for 2^I instead of 2^I-1
* -2 bytes for Z+SD instead of Z+Si^D
* -1 byte for the rest of the removal of powers of two
which of course adds up to -3.

The next challenge is a minor revision of this, which hadn't enough attention the first time.

Given a list in L1, output in L2 the list with all distinct elements, whose elements are in order of their first occurrence in L1. For example, {3,1,4,1,5,9,2,6,5,3,5} becomes {3,1,4,5,9,2,6}.

L1 has 256 elements, each an integer in [1,10^6]. L1 is generated thusly:


Code:


You needn't generate L1, only uniquify it placing the result in L2. Fastest program in the average case wins. Testing will be on OS 2.55MP, since I don't have a color calc.

Welcome to Cemetech, CodertheBarbarian! The rules for this thread dictate that only the winner of the previous challenge can post challenges, though, and we're still deciding who that even is. So be patient.

EDIT: My solution to lirtosiast's challenge:

Code:

Lets see if we can kind of start this over. I like CodertheBarbarian's idea from earlier but changed up a bit:


Code:

I'm assuming you mean "Ties".


This is a formidiable challenge, so I shall start ASAP!

hmmm, so I did the long division challenge in 70 bytes, but it's hard to tell if it is exactly what you wanted. Basically, it displays the answer and the remainders along the way. It can support arbitrary precision (so long as none of the remainders are bigger than whatever the limit of a float is). So I guess the limit to the amount of decimal places it can support is the maximal length of a string, which is limited by the amount of free RAM. I will post my code in small text on the next line to not spoil it for others if they want to have a go:
toString(int(A/B))+".→Str1:For(D,1,C:10(A-Bint(A/B→A:Str1+toString(int(A/B→Str1:Disp A,Ans:End
Input is as follows:

A: Dividend
B: Divisor
C: Number of decimal places of accuracy

The answer is stored in Str1, so calling Output(1,1,Ans) at the end of the program would display it fully, but this is not necessary since the answer is displayed at every iteration, except that if the length of the precision chosen is greater than 26 decimal places of accuracy, then only the 25 first decimal places will be displayed followed by an ellipsis, because that's how the Disp command works.

I can't test it because I don't have a CE, but it looks good. With the output (minus the final parentheses ), it's 76 bytes.
Can anyone do better? Find out next post in...TI-BASIC Challenges!

I did it in ~150 bytes... I thought it was compact XD

My program draws the long division problem out, but it only adds ~20 bytes.

I'll put my code if requested. I can also give hints about how it can be done, if Kydapoot is ok w/ it.

> You can go about it however you want as long as it is correct for any numbers (except dividing by 0 of course) and you can follow each step of the long division as it is performed.

I don't understand what this means:

* What are "any numbers"? Is dealing with positive integers sufficient? Integers? Positive reals? Complex numbers?
* What's the minimum a program must display? If requirements aren't clearly defined, the most troll program that technically satisfies them will win. Are we to display all the remainders and the answer as mrwompwomp did? Is this enough for (42,31337.0000)?


Code:

I apologize for being so unclear.

Positive integers are the only requirement, and I am looking for displaying the remainders AND what you multiply by each step.


Posting the code (or a link to it/small text/whatever) is required. You don't have to draw it out for the challenge, but it would be cool to post that code so we can see it though.

Code:


Displays the answer, then below it, {remainder, next digit of quotient} on each line. C is the total number of digits of the quotient to generate, not decimal places. Works for A < 10^11 and C < 10^12; 39 bytes.

Well, it has been a week, and it seems that no one else has figured one out. Lirtosiast wins with 31 bytes, and can post the next challenge at will.