| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
Both very handy. I'll add other numeric setters later, it was very
easy.
|
|
The command line options let you set the initial radix/scale, and
there's a function te test if any number is prime, that's fun.
|
|
...But primes in base 36 and it skips all numbers with digits in the
range 0-9
|
|
This doesn't really matter for this project right now. I keep
forgetting because other ones auto-generate the code from 'git describe'
|
|
You no longer need to set the radix in the current radix.
|
|
|
|
|
