I'm going to rework the code I had for the "TI-Basic Library" into a DIY-Library maker! Got some code that repeats over-and-over, and you want to save space? Easy! You can create your own customly-named AppVar, holding all the information, from the name of the function, to the subroutines they execute!
Unfortunately, there are some drawbacks so far:
*Can only handle one input after the (. You can technically have more than one input, you just have to make sure it isn't destroyed by any variable used by prgmDIYLIB
*Can only handle number inputs
*Only technically works on the CSE. It would be pretty easy to port to monochrome calcs (and possibly the CE), so if you're interested, contact me!
*Running it is most likely slower than just typing out the equation normally
(note: This is not a serious project. I finished this in like 4 hours and felt like it was cool to mess around with)
(http://i.imgur.com/KidvRiw.gif)
[spoiler=Old Message]Just for kicks, I felt like making a Basic Library. It's incredibly inefficient for most tasks. As a proof-of-concept I whipped up a fucntion to find the digits of a real integer and a function to square a number. Just an example, the calling the squaring function takes ~12 bytes more than just doing X2. The interpreter is 102 bytes large as of now, and uses a database AppVar to store all function names, function equates, etc. This is so the AppVar can be archived, saving RAM (in theory). Right now, it's only technically compatible with the +CSE because I'm only familiar with Celtic II functions, however it would be as simple as replacing 2 commands to port it over to monochrome calcs. For calculators which have no way of accessing AppVars, the interpreter would be significantly larger, and it'd be a little more work. Also it can't really handle more than one argument or outputting anything other than a string. Yeah.
Post suggestions here, and I'll post what I've implemented.
[spoiler=Commands]
*DIGITS( - finds the digits of a real integer
*SQUARE( - squares the number
[/spoiler][/spoiler]
If you downloaded the previous version, please redownload. The previous version could only handle 2 commands, where as this one has been fixed to handle as many as possible.
can you just type in the command?
If so, that sounds really cool! Post some more details on how it works? ;)
Quote from: E37 on January 16, 2017, 12:37:55 AM
can you just type in the command?
If so, that sounds really cool! Post some more details on how it works? ;)
Unfortunately, no. You have to type something like:
:"DIGIT(100
:prgmLIBRARY
// bytes: 19
Just for reference, the code it runs takes up only 15 bytes (including protecting against nonreal numbers or a mix of real/nonreal), plus the 102-byte interpreter, means that this is for right now, really inefficient. I assume that if I use this to create subroutines (which actually sounds better than using this as a library), there would actually be space to gain from this.
Will you make it so the user can make their own?
I can't tell, is it written in basic or assembly? Appvars suggest assembly, but it is called like basic. (no Asm() command)
Quote from: E37 on January 16, 2017, 12:49:16 AM
Will you make it so the user can make their own?
I can't tell, is it written in basic or assembly? Appvars suggest assembly, but it is called like basic. (no Asm() command)
Users can make their own if they open the AppVar (on a computer, of course), but there's no way to make one on-calc as of yet. That might actually be something interesting to consider.
It's a Hybrid-BASIC program, accessing the pre-created AppVar using Celtic II CSE.
It would definitely be more useful if you added the ability to create the appvars on the calc.
It would be really useful then, and could even be used for making really large games or games that share large chunks of the same code.
Quote from: E37 on January 16, 2017, 12:56:38 AM
It would definitely be more useful if you added the ability to create the appvars on the calc.
It would be really useful then, and could even be used for making really large games or games that share large chunks of the same code.
Yeah, I think so too. I'll probably make an on-calc editor that has the names of the functions listed. When you select one, you'll be able to edit its name and the function it performs.
A port to the b/w calcs would be nice when you have finished the color version. With a little work, you could make something really great from this!
Quote from: E37 on January 16, 2017, 01:08:40 AM
A port to the b/w calcs would be nice when you have finished the color version. With a little work, you could make something really great from this!
That actually wouldn't take long at all, I just have to know; is Doors a staple in the community for monochrome calcs, as it is for the CSE? Or will I have to (get someone to) do it in Axe?
Update: Screenshot! Also download if anyone wants it. This download is for the TI-84+CSE only, requiring Doors CSE. It is fairly easy to port, so if you're interested in porting it to monochrome calcs/the CE, contact me!
(http://i.imgur.com/KidvRiw.gif)
I'M not too sure if I really understand the concept, no matter how much I try to read, but is it kinda like some sort of programming language maker?
Quote from: DJ Omnimaga on January 16, 2017, 05:27:35 AM
I'M not too sure if I really understand the concept, no matter how much I try to read, but is it kinda like some sort of programming language maker?
In a way, yes! It's more like doing this in ASM (lifted straight from Learn Asm in 28 Days):
#define move(src, dest) LD dest, src
except it doesn't handle more than one input inside the parentheses at a time (though by customizing the algorithm you can still make it process more than one input, since it uses expr() to function)
Ah ok. I remember in 2006 when someone made a new programming language in pure BASIC. It was supposedly slower but up to 3 times smaller O.O
http://www.omnimaga.org/ti-z80-calculator-projects/stupidlydidledtupidlydidledidledidly/
so this thing lets you write some code that will then be packed into a userdefined command and executed even faster than regular code?
Well that's really nice! O.O
But how far is it possible to include those commands into a project?
Forexample if you have 2 games using this, but each using commands with similar names but different mechanics, will that even be possible?
Quote from: p2 on January 16, 2017, 11:48:13 AM
so this thing lets you write some code that will then be packed into a userdefined command and executed even faster than regular code?
Well that's really nice! O.O
But how far is it possible to include those commands into a project?
Forexample if you have 2 games using this, but each using commands with similar names but different mechanics, will that even be possible?
It's actually a bit slower than regular code, since it needs to interpret the command you're sending and still execute the code.
The answer to your other question is pretty simple: On creating an AppVar, you define its name. Just change a name that won't be called by any other game. Then, when you go to run the commands, make sure the name of your AppVar (prefixed by "rowSwap(" ) is in Str0. It will search through ONLY your AppVar to find the command.
if you have the appvar OIRAM and the appvar NOMEKOP and both have the command DRAWSTUFF(
how does the game decide which one to use? :)
Quote from: p2 on January 16, 2017, 02:26:48 PM
if you have the appvar OIRAM and the appvar NOMEKOP and both have the command DRAWSTUFF(
how does the game decide which one to use? :)
In your program, you will define which AppVar to use. You can technically use both, but there's no point since you can add as many subroutines as you want.
This is about how it is done:
:"OIRAM->Str0 // If you want the other AppVar, just change it to "NOMEKOP->Str0
:"DRAWSTUFF(20
:prgmDIYILB
What prgmDIYLIB does exactly, is it reads the string of commands in your DIYLIB, then it decides which one you've inputted (no matter the command string length) and executes the code stored under line [command number] +1, where [command number] is the order in which your CALL( appears. Another example, this time of the AppVar:
1 :DIGIT(CALL(EXECUTE(A(
2 :code for DIGIT(
3 :code for CALL(
4 :code for EXECUTE(
etc.
So for CALL(, it looks in the string for CALL(. It's the second command in the list, so it adds 2 (the listing) + 1 (offset since call names are stored in line 1)
Also, if you downloaded the original, please redownload. I made an error, so it could only handle 2 functions. Now it can handle as many as possible.
really nice, might be a great help for on-calc programmers (dont have to type the same super song formula a thousand times again) xD
how big exactly is the slowdown? :)
could you do two counters, one using the external command thingy, one directly counting, and tell us the results (speed comparison)? :)
I'm really interested in how fast it is ^^
Quote from: p2 on January 16, 2017, 03:03:30 PM
really nice, might be a great help for on-calc programmers (dont have to type the same super song formula a thousand times again) xD
how big exactly is the slowdown? :)
could you do two counters, one using the external command thingy, one directly counting, and tell us the results (speed comparison)? :)
I'm really interested in how fast it is ^^
Yeah, I was actually planning on doing that now. I'll edit with the results.
Edit:
Running this set of code to determine speed. Here you can see how many times the loop repeats and the command/equates I used.
"rowSwap(LIBNEW00→Str0
startTmr→T
For(F,1,150
"DIGIT(F
prgmDIYLIB
End
checkTmr(T-I
Ans/150→G
startTmr→T
For(F,1,150
int(1+log(real(F+(0=real(F
End
checkTmr(T)→J
Ans150→H
Disp G,H," ",I,J
Pause
Now here's the results.
[loops] = 150: DIYLIB took an average of .16 seconds to process each request, and the straight command took .013333.... seconds.
DIYLIB, in 150 loops, took ~24 seconds, while the straight command only took ~2.
ouch those numbers hurt... :ninja:
can you maybe determine where the slowdown comes from?
try a loop INSIDE the external thingy (the userdefined command).
maybe it just takes time to lookup what should be executed, while the execution itself is at regular speed again, which means the slowduwn would be much smaller for real day-to-day usage.
Quote from: p2 on January 16, 2017, 03:25:21 PM
ouch those numbers hurt... :ninja:
can you maybe determine where the slowdown comes from?
try a loop INSIDE the external thingy (the userdefined command).
maybe it just takes time to lookup what should be executed, while the execution itself is at regular speed again, which means the slowduwn would be much smaller for real day-to-day usage.
I'm almost positive the issue is finding the command to be used. It basically runs a whole While loop to find the command. That, jumping between programs, and the simple fact that any code that does more than just the equation will inevitably be slower; I'm running all this code to find the equation, then the equation itself.
shouldn't you store each command's lookup address before you start? idk never programmed a emulator or anything like that b4
Quote from: kotu on January 16, 2017, 03:29:00 PM
shouldn't you store each command's lookup address before you start? idk never programmed a emulator or anything like that b4
Because each command can be a variable number of letters, I have to find where each opening parentheses are. There's no way to do this other than a loop. It basically checks the if the command you're attempting to call is anywhere in the system, and what expression/algorithm it goes to.
I'm kinda curious if some sort of game can be made out of this, such as a turn based text based fighting game
Quote from: DJ Omnimaga on February 05, 2017, 04:39:53 PM
I'm kinda curious if some sort of game can be made out of this, such as a turn based text based fighting game
It's possible. I think I want to update this though, so I can improve speed. This is the pseudo-code for what this already does:
Get the input string
Read the DIYLIB appvar to determine which command is being called; repeats through the "master string" holding every command name
Execute the code on one on the corresponding line
and this is the pseudo-code for what I'd want it to do, should I update it:
Get the input string
Read every other line of the appvar until you find the command being called
Execute the code, which appears on the next line
I don't have an exact estimate for the speed increase, it really depends on how many commands it'd have to read before finding the one you want. On the other hand, the current version has a constant speed (12x slower than just writing out the command). The DIY Library is, in my eyes, more suitable for saving bytes than anything. I would recommend it just to use it for setting up variables at the beginning of a program that require a really large algorithm to be executed. I'm guessing the fastest the second method I shared would be at its fastest, probably 4x slower than just writing out the command. At its slowest, it's probably unusable (again, if it has to search through a lot of commands to find what you want).
Ah ok. I guess it can still be handy if the program size + this lib size is worth it or if it makes development much more simple without making the program unuseable speed-wise. In any case, good luck if you ever update this.