| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
should be an easy fix.
|
|
I had the wrong path for the target, so it could never find the output file and it tried to create it every single time.
|
|
Added new ones for a recently discovered bug, brought back others for bugs that
were already fixed.
|
|
Discovered arithmetic bug in the Number class, -4 + 5 is coming back as -1, not 1. It's getting the sign wrong somehow. I'll have to hunt that down.
|
|
The command structures will be changed, I think. I want the lexer to actually
lex the command names into tokens, then the parser and the engine can both use
them to update their state when necesarry. It will be less ambiguous and easier
for both sides to stay synchronized.
|
|
At least...those issues are behind us. We'll see what happens next.
Also, added some macros to make debugging easily optional.
|
|
I believe this is because I'm using right tail recursion, but I'm not really
sure how I could change it for this program.
order of operations is being observed perfectly, but then operations are being
performed from right to left, not left to right. I think I may be reducing
too frequently, honestly.
|
|
The main interactive interface doesn't work, and there's a lot left to do with
the unit tests, other command line options, etc. but it's pretty exciting.
I also still have to figure out how commands will work. I'm thinking they'll
be stored in an Expression and executed by the engine as normal.
|
|
That was actually really cool. Now to clean up the debugging code and write
the execution engine.
|
|
There's still more to do, however. It doesn't do math anymore, it produces
a script that can then be executed. Now we have to capture that script and
execute it.
|
|
These will have to be updated later.
|
|
|
|
I'm doing some reading up on LR(n) parsers, I just sort of started without
thinking about it this time, not a great approach. I feel like it can't hurt
to have an update on how this works anyway. I think the idea was solid, but
I was trying to do too much at once.
One question is what my goal should be for this. I could just solve the
equation as we go, or I could generate code that will let us solve the equation.
The later is obviously attractive in that it will let us run an expression
more than once, and maybe even define functions. I like that.
|
|
|
|
|
|
|
|
Also updated the gitignore to ignore the dep files.
|
|
|
|
|
|
|
|
It turned out to be a really simple solution, but man, that was
embarassing. I forgot to include the fractional portion of a number
when fixing my radix+1 compliment numbers.
|
|
There was an issue with order of operations outside of parenthesies,
easily solved.
|
|
Reads in a list of numbers on standard in, one per line, and sums them.
|
|
Other minor fixes and options such as --version being added.
|
|
Added a little bit of help, too.
|
|
I think that's a better practice, it'll be a lot easier to expand it and
format it in general, plus it could be compressed if it got too much
bigger.
|
|
|
|
|
|
I have to decide how to handle special values like that, but for now
it's better that it doesn't go into an infinite loop.
|
|
|
|
No more known division issues.
|
|
I'm not sure what part is broken yet though.
|
|
|
|
|
|
|
|
It looks great, and works with everything I can think of so far.
|
|
|
|
Other minor bug fixes including scale issues, digit() access stopped a
digit before the final possible digit in the scale, >, >=, <, <= all
work correctly with mixed scale numbers now, probably other fixes.
|
|
We need a new division routine.
|
|
|
|
It was bailing on very small numbers with only one decimal point of
precision, which is silly. This has been fixed.
|
|
|
|
|
|
|
|
|
|
Should probably include that extra header.
|
|
You can tell it where to start now.
|
|
|
