baboomerang / graphing-calculator-project Goto Github PK

The hardest thing to do without recursive addition to get the number.

Tokenizing part of a char array and initializing it as a big number does not work under any easy or simple conventional method in C.
char buf[50]; //holds serial input of chars

We cannot do BigNumber i = buf; despite the initializer syntax in the library supporting that.
It would only work if it was BigNumber i = ("<string-constructor>");

Using toINT() truncates the input prior to conversion.
char array to long by strtol() then long to big number seems possible, but convoluted and still truncates higher-than-long inputs.

The solution that I have used before was a recursive input stacked addition:
psuedocode
for(loop till delimiter(end of string)) {
get the char from the string
convert to int then - 48 (ASCII to decimal conversion)
multiply by that number by 10
then add the next calculated integer
keep doing that till you get your integer part of the number.

625868235 would be processed as
'6' first char then convert to int which is 54
54 - 48 to get int (6)
add 6 to the collector and multiply by 10

the collector is now 60
'2' second char then convert to int which is 50
50 - 48 to get int (2)
add 2 to the collector ( 60 ) to get 62
multiply by 10 again to get 620
...
...
..
.
do this till the last int but don't multiply by 10 to get your big number
inefficient I guess, and quite problematic, but is a necessary evil.

60 + 2 620 + 5 6520 + 8 65280 +6 652860 + 8 6528680 +2 65286820 + 3 ---> 652868235 entirely as a bignumber with no conversion problems.

Once a left parenthesis closes and saves the number if there's an operator immediately left to it it will duplicate a ghost "saved number" which will interfere with the reference stack.

given this infix expression (3+4*2/(1-5)*9)
given the infix REFERENCE stack 613141561217417 (1's being #'s 2 - 3+ 4 * 5/ 6rightparenth 7leftparenth

we get the postfix REFERENCE stack as 1114112**1**5143 that extra one isn't supposed to be there
this would be an extra copy of the 5th term in this case actually being 5

Final, Incorrect POSTFIX notation would be 3 4 2 * 1 5 - 5 / 9 *+
Correct, Final POSTFIX should be 3 4 2 * 1 5 - / 9 * +

3 + 4 * 2 / ( 1 - 5 ) ^ 2 ^ 3 : Input infixstring

3 4 2 * 1 5 - 2 3 ^ ^ / + : output postfixstring (what it's supposed to be)

3 4 2 * 1 5 - 2 3 ^ / + : current output postfixstring (what my code does)

The more exponent operators we add, they get ignored. only the first exponent immediately after the closing parenthesis ' ) ' gets copied to the stack, otherwise nothing happens. But everything else works.

3 + 4 * 2 / ( 1 - 5 ) ^ 2 ^ 3 ^ 6 ^ 99 ^ 13 ^ 5 ^ 2: Input infixstring

3 4 2 * 1 5 - 2 3 6 99 13 5 2 ^^^^^^^ / + : Proper Output postfixstring (Correct Form)

3 4 2 * 1 5 - 2 3 6 99 13 5 2 ^ / + : Current postfixstring ( What my code does #obviously wrong )

Something tells me that exponents are copied to the postfix_opstack, but the logic inside of that whole stack is funky. The fix has to be implemented inside of the pushtostack() function.

any value that reaches out of the upper Y or lower Y limit presents a minor aesthetical issue.
The solution is either stop tracking at that point or cap the plotting value to the upper limit of the display if it ever reaches past the limits.

Printing will stop if input has any zero whatsoever regardless of position (ONLY IN DECIMAL PORTION)

Parenthetical processing works, but only partly. Given infix expression 455*(923/123-7564+72), it is wrapped with a start and terminating characters. This works fine.

455*(923/123-7564+72) becomes (455*(923/123-7564+72)) which does get processed.
however, if you do this:
455*(923/123-7564)+72 it will halt when processing the save_num function of 7564 and the last number it will save correctly would have been 123.

# EDIT: cutHere == numX and when any operator is juxtaposed with a left terminating parenthesis, this bug occurs.

IRRELEVANTAnalysis: Since the closing parenthesis does make changes to the cutHere and other various elements, it is possible that save_num ends up cutting nothing or an invalid distance, thus halting the program.IRRELEVANT

3 ^ 3.00012324 if inputted into the calculator will be internally handled as a 3 ^ 3.
In essence, there will be a truncation of the decimal portion for some absurd reason.

I need modified exponentiation functions specifically written for the Big_Number.h C++ library.
This may the biggest non-correctable problem with the project.