Does it have equation solving capabilities yet?
souvik1997 wrote:
Does it have equation solving capabilities yet?
I seriously doubt it; as I understand it's fully numerical at the moment, and can't perform symbolic manipulation. Although I guess you could still solve simple equations with a fully numeric parser...
I need to redo the nodes as I was doing it so badly before (a number had a number node and a operator or number had an operator node that links to either other nodes or other number nodes, which go too confusing now). In addition, I plan to write my own VM/Kernel for the OS to do this with less code. That will take a while. But since this project is to be run on a computer, no worries - the kernel can run on a PC.
Err, you totally lost me there; could you clarify a bit? You're planning on writing a different math kernel from the original GLaDos kernel to support your gCAS program? And by node do you mean parser state-machine states?
Sorry about that. The new kernel would be a VM (like Java is a VM) and would run with the OS. The kernel is not to provide better math functionality, just to make much larger calls than z80 asm (making the final program much smaller) and would manage the memory in a very sane way.

The nodes I am referring to are declared as such:

Code:
typedef enum
{
    FUNCTION = 7,
    POWER = 6,
    FACTORIAL = 5,
    MULTIPLICATION = 4,
    DIVISION = 3,
    ADDITION = 2,
    SUBTRACTION = 1,
    NONE = 0 // used to make the tree
} cas_node_type;
typedef struct
{
  float f;
  char b,p;
} cas_number;
typedef struct _cas_node cas_node;
struct _cas_node
{
    cas_node_type type;
    cas_number *f1,*f2;
    cas_node *n1,*n2;
};


As you can see, the n1 and f1 are way to messed up and can be combined as such:

Code:
typedef struct _cas_node cas_node;
struct
{
  cas_number number; // not a pointer, included
  cas_node *n1, *n2;
  cas_node_type type;
} _cas_node;


When doing 2+3, the tree has 1 cas_node and 2 cas_numbe'rs, but using the sane method would only have 3 cas_node's, one for the op, and 2 for numbers.

This will allow me to easily display answers with and without undefined variables as the answers will always be returned in the sane type, a cas_node. Currently, they return either the node or the number, which is stupid. This also means that the cas would allow stuff like

Code:
x=y+2
and
Code:
x^2+x
>>x^2+x
ans/x
>>x+1
Maybe functions would come into play soon using this idea...
That makes perfect sense! Thanks for the long and very well thought-out explanation. Smile
I will also try to work out the expression parser. Right now, I rely on a string to do everything. Before, I would split the string into a 2D array/struct so that I can step through the expression and parse it. I use a struct so that I store a pointer to the node created. If you have parentheses, then o.o.o. says to do stuff in parenth. first, which the parser does. I now see that this isn't a good idea because it uses ~1-2K of memory. It's mainly the unsigned ints (pointers) for the strings and the nodes. I wanted to just modify the string, but it will not work well... I was thinking about replacing the evaluated expression with a pointer to the node (as characters), but this needs the string to be resized and the parsing will be crazy.

Any ideas on how to handle this stuff?
I saw you posted in my topic here, did the algorithm not appeal to you? It uses a crazy-small amount of memory.
SirCmpwn wrote:
I saw you posted in my topic here, did the algorithm not appeal to you? It uses a crazy-small amount of memory.


The parser, as you just posted over in your topic (just after I wrote this) calculates it differently, it looks. It doesn't seem that your routine creates a tree and that it will calculate it as the routine runs. Other than that, your parser does that same thing as mine. The rules for parenth. are the same and handling numbers, too. Again, making nodes and handling variables are the only variation
In order to avoid having the same conversation across two threads, I'll merely direct you to my reply here.
Yeah, my head was spinning a tad Razz
AHelper wrote:
I will also try to work out the expression parser. Right now, I rely on a string to do everything. Before, I would split the string into a 2D array/struct so that I can step through the expression and parse it. I use a struct so that I store a pointer to the node created. If you have parentheses, then o.o.o. says to do stuff in parenth. first, which the parser does. I now see that this isn't a good idea because it uses ~1-2K of memory. It's mainly the unsigned ints (pointers) for the strings and the nodes. I wanted to just modify the string, but it will not work well... I was thinking about replacing the evaluated expression with a pointer to the node (as characters), but this needs the string to be resized and the parsing will be crazy.

Any ideas on how to handle this stuff?
I don't think I'd try to do in-place string stuff if I were you; it seems to me that a tree would be a much saner way to deal with things. What do you think?
Well, right now I have a string tree used to create the node tree...

(I have 2 parsing functions, one to take "1+2+2" to break it up into 1, plus, 2, plus, 2 (as structs that hold their nodes) and then take the nodes and make a tree from them) I don't know of a better way...


Code:
typedef struct _cas_node cas_node;

typedef struct
{
  void *ptr;  //initially the string, but then is used to hold the node ptr.  Text is freed from here
  cas_node_type type; // are we a +-*^!()/, etc.
} cas_parse_node;


I don't know of a way to go right from a string to a tree without loosing track of the node pointers... -_-
I'm not sure I fully understand the tree system, could you make some sort of graphical tree and explain the algorithm a bit?
This was the document that I learned about the tree format:
http://www.math.wpi.edu/IQP/BVCalcHist/calc5.html
Thanks, that did a great job of explaining it. I'm thinking the best way to approach math is the best of both worlds. My algorithm is good because of the small amount of memory used, and yours is good because it is great for complex expressions and simplification of expressions, etc, but it takes a ton of memory. Perhaps both could be offered, and the CAS can be turned on by the user (with a warning on memory usage)?
SirC, please note that on an x86 the RAM usage is 7KB. This will be smaller since the z80 uses smaller datatypes. I can't measure it (more like I don't want to). But yeah, maybe the TI84 can step up to the ti89's level (somewhat)

Also, note that gCAS is an external project not included in the OS. The end-user would be able to pick the calculator that they would want to install.
On x86, a double is only 8 bytes. How good of precision are you getting on z80 with less?
SirCmpwn wrote:
On x86, a double is only 8 bytes. How good of precision are you getting on z80 with less?
How did you determine that he's using 64-bit doubles instead of 32-bit floats, or even 24-bit floats? (although those would have horrible precision).
I think he means the pointers, and structs will be smaller. The actual float types I'm sure are of adequate precision.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, ... 10, 11, 12  Next
» View previous topic :: View next topic  
Page 2 of 12
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement