Does it have equation solving capabilities yet?
» Forum
> Your Projects
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:
As you can see, the n1 and f1 are way to messed up and can be combined as such:
Code:
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:
and
Code:
Maybe functions would come into play soon using this idea...
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
Code:
x^2+x
>>x^2+x
ans/x
>>x+1
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?
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.
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? Any ideas on how to handle this stuff?
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:
I don't know of a way to go right from a string to a tree without loosing track of the node pointers... -_-
(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
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.
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.
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.
"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown
"If you've done something right no one will know that you've done anything at all" -Futurama
<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.
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
» Go to Registration page
» Goto page Previous 1, 2, 3, ... 10, 11, 12 Next
» View previous topic :: View next topic
» 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
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