The one above optimized.


Code:


I prefer the built in menu's myself, doesn't waste space for flashiness.

Oooh, that's a nice one. We should include these in the next issue () of the newsletter.

Thanks for the optimization
I didn't really know how to use max and min, but that makes it much nicer.

Also, about the built in menus. I think the built in menus are a pain because you have to have lots of labels. The labels make the code more difficult to read and can slow it down (though looping with two labels is the fastest way to loop). Besides, using lots of labels can be very messy, and the built-in menus aren't custumizable and it takes a lot of menus to for a lot of commands. My dad told me that for professional programmers, they try to write their programs without using any label/goto commands. Also, with custom menus, you know the exact amount of RAM you need to run your program, normally only about 1000-2000 bytes, but you can need several thousand with many labels (take for example the game HoboHunt 3, where it is only 18,000 bytes, but still has memory errors).

Modulo division
Input:
A=Dividend
B=Divisor

Code:

The Round( is in there in case of an infinitely repeating decimal (like 1/3).[/b]

Check out this topic over on TI-Freakware, it has a fairly good explanation of max, its advantages, and how it works. http://tifreakware.ath.cx/index.php?showtopic=391

It is best to have as few lbl/goto's as possible but I find that customizable ones use just as many and take up more space. Just a personal preference. Hobohunt has memory error because it has at least 30 (I know there are more than thirty but I lost count there, I think it is 37) memory leaks, could use A LOT of optimization, has quite a few goto's that don't have to be there, and is a text RPG. Little to do with the amount of menu's, and the part that does has to do with the fact that it's a text RPG which people should avoid playing and making. Never do If-Then-Code-goto-End, it's a very common memory leak.

BTW The Tari, there's no need for a multiplication sign between B and fpart.Also, do you mean to be rounding zero or rounding Bfpart(A)?

When's the last time you put out a newsletter?

BTW I have a newer version of B-Flat's routine that saves five more bytes.

That is definitely wrong. (Based on what I have learned from the topics here) for a goto-label, it seaches through the entire program until it finds it, with a loop like a while loop, it stores the location of it and when it encounters an end goes back to it.

You could do:

Code:

Actually, it should be:

Code:

Unless you want to round 0 to Bfpart(A/B) decimal places.

There's actually a new template just waiting for articles. Anyone feel like writing one?

Hey, why don't we make a separate topic for talking about the different code snippets so this can just be a reference topic? Whens omeone optimizes code just update the original here.

OK, I haven't used round( much, and I made it B*fPart( to avoid confusion.
Edit: I forgot to mention that outputs are A=quotient and B=remainder.

lbl/goto speed in standard timings can be misleading because it doesn't have to look through that long of a program. When the program gets larger, doesn't even have to be that large, is when you notice the enormous speed difference.

I would be willing to write an article, though I'm not sure what I would do or if I have the time.

About the label/Goto thing, I was talking about if you only had a short loop, like

:Label 1
:Output(1,1,I
:I+1->I
:Goto 1

Not a long program (never use those loops in long programs).

Yeah, I agree that we need to have a separate topic for the discussion of the code than the topic with the actual code.

Much Faster Shading Routine

This version is only for linear functions. The sample is 2x and x.
Also note that it uses ZStandard graphing mode



Code:


The only difference for non linear functions is that you must plot each point on the outline (it is still several seconds faster for sin(x),cos(x.

I have a shading routine that beats that one. I'll post it when I find it.

Matrix to List
Input: Matrix A
Output: Lsave
Converts any size matrix to a list


Code:

...doesn't Matrix->List do basically that?

yes but with matrix->list you have to use a seperate list for each column. and mine takes every matrix element and stores it into one list

It doesn't matter how long the loop is, it matters how much code is before the loop. If there's 2k of code in front of the Lbl, it's going to run MUCH slower because the TI-OS has to search through 2k of code on each iteration.

List to Matrix
Inputs: Lsave
output:Matrix [A]
Takes any size list and stores it into a matrix

Code:

Even if it was at the very beginning of the code wouldn't a while loops work faster? Doesn't it store a value to go back to instead of searcing?