I had a crazy idea. Builder boy wrote portal X to run at 9fps on a z80 running at 15mhz and with 24kB of ram. Well the N-spire has 90mhz processor, 32MB of ram and an OS that is a million times more intelligent than the TI 84's. (nucleus itself not the TI front end) to put things in perspective the N-spires processor it clocked 18 times faster then the 84 and is a better architecture plus its 32 bit as opposed to 8 bit we are talking around 50 times the computational power of the 84 and over 1186 times the memory. with this kind of memory it should be possible to write a full 3d portal running at 30 fps interlaced. (because the screen is fine enough that it can be gotten away with) To give a comparison the Nintendo DS has about the same if not less processor power, spread across to processors so there is extra overhead of coordination, then the N-spire and one 4mb of ram + 656k of video ram to the N-spires 32MB (including OS space). 3d rendering a physics are completely possible on the N-spire and portal is only a tiny bit of a strech
I say the CAS OS and Non CAS OS are identical they are just configured slightly differently look at the file sizes of the OSes anyone notice that the NON CAS OS is bigger despite having a less complicated task a CAS is big an i doubt its smaller then the 84 emulator packaged with the Non CAS Nspires OS case and point the non cas nspire is the same os only crippled all we have to do is figure out how to un-cripple it which likely comes down to either a configuration file change or the modification of a few pointer and we have everything. If i had an unencrypted version of both OSes I'd find the parser and find the array of function pointers that point to the code executing the commands and start there. But that's just me.
I thank you for your help and support in my endeavors in optimizing this library. This is nothing against your code or your talent but I think I'm going to replace your entire algebraic simplification with one of my own design. This is not because I think your design is poor it is just that I have my own simplifier halfway finished from before I started work on your library so I think that it will be easier for me to finish my simplifier then it will be for me to optimize yours because I understand mine better. additionally I don't want all the time I spent designing my CAS structure to go to waste although I do think I will be using your postfix notation generator because it make building my rather complicated structure far easier.
In other news what does libexpr\collect() do? And how often do you factor numbers outside of the algebraic simplifier because I was wondering if it would be worth my time to replace my\factorsmatrix() with my own version that I don't currently have typed up but is faster and deals with fractions by expressing the denominator as primes to negative exponents but is about twice the size (needed it for my own polynomial tools and wrote it totally independently of ti
I'ce been playing with it but I don't understand the structure of your tree if you remember how the trees work that would be a big help because I have not been able to make heads or tails out of the out put of pf2tree() if you could explain what the 2 numbers preceding each token mean it would be greatly appreciated. Because not understanding that has been my biggest problem and has caused me to think about rewriting the whole simplifier from scratch something I was not looking foward to. I do realize that you may not remember though cause this Library is huge and I don't think i have even lookedat half of it yet.
unfortunately I was wrong as to why the differentiation function is slow it turns out that it's because the algebraic reduction portion that it is slow. This posses a significant challenge to optimize. although I'm working hard to figure out this portion of the library but progress is slow and i have unfortunately some how broke something in it and I don't know what so that has set me back almost a week. I'm going to have to start doing nightly backups.
ASM is fun I toke a class and learn MIPS asm. Working with it taught me how much overhead there is to common operations. I think every programmer at one time or another should write a call stack with frame pointer, a dynamic memory manager and some simple programs just to understand the costs of the operations you do all the time.
I'm really embarrassed the library I posted doesn't work It just explodes anyway heres a working version of the library. and good news I think I've figured out why the differentiation function is so slow and am working to fix it I think It will be a very small modification to the pf2tree function or the pf2tree function and it will be crazy much faster. I forget which at the moment. still happy day.
not sure haven't really looked into it none the less: A) it would be kick ass B) the price will eventually come down. C) student supplies calculator school supplies cradle internet in class problem solved
#ifndef Z80_LIB_COMMON_H #define Z80_LIB_COMMON_H //all the libraries you normally need
//functions to do common tasks with inline directive on each.
#endif and your done write it once and it works every time no needless complexity. At the beginning of every file put #include "z80 lib common.h" and your done it all works. I'm honestly surprised it doesn't already exist. and you don't have to worry too much about making really efficient code cause any decent optimizing compiler will rewrite your code in to something more efficient then you could ever possibly come up with anyway so all that matters is the algorithm you use for the most part.
someone make it weeks project I would do it but I don't have the time with other stuff.
Show Posts
additionally I don't want all the time I spent designing my CAS structure to go to waste although I do think I will be using your postfix notation generator because it make building my rather complicated structure far easier.
I'm going to have to start doing nightly backups.
