I don't know why, but according to my program, 8 + 8 = 14

It passes all the test cases fine but freaks out when it comes to simple (only simple, more complex ones are fine) equations using the number 8, and I don't know why.

This is a good thing, right?

 

(It does crash on 591372 / 98562 though, but only when run from the compiled file in the Release directory, I don't know why, guess I have some special compilation requirements then, heh)

Does your program calculate in base 8?

 

No, its far worse than that. Lets just say it involves rather large strings.

Mine does addition wrong if the 2nd operand is longer than the first one... 3 + 33 = 6.  That's a feature, not a bug...

Mine segfaults if you try to do anything other than "num op num =". If you try "num op num op num =" to try to commit an operation on the result of the last operation, it just violently dies. I could fix it, but I don't want to.

 (EDIT: Oh, no, wait. Actually I think what it does if you try "num1 op1 num2 op2 num3 =" it'll just apply op1 to num1 and num2 and ignore the rest. It violently dies if you just go "num =". That's what I was thinking of.)

Other than that my calculator works fine for all test cases and simple operations, though I won't admit to having tested it intelligently.

This turned out to be caused by a poorly written (read: doesn't actually work) implementation of a basic algorithm.

 I don't think I'll bother fixing it, too much work and the test cases are fine.
 

" I don't think I'll bother fixing it, too much work and the test cases are fine."

 

YOU sir, have captured the real spirit of WTF! I salute you. 

ben_:

" I don't think I'll bother fixing it, too much work and the test cases are fine."

 

YOU sir, have captured the real spirit of WTF! I salute you. 

On the topic of the "True spirit of WTF", I have a question for you.  Imagine you're calculating the division of two 24-bit numbers, i.e. the floating point mantissas.  To divide one by the other, you bitshift the divisor up 8 bits and then do the division.  This, however, gives you only 8 bits of precision.  What do you do to increase your precision without resorting to numbers longer than 32-bit or high-level routines?

 (I've already answered this in my program in a truly WTF way: I want to see what others think ;) )

Dark Shikari:

ben_:

" I don't think I'll bother fixing it, too much work and the test cases are fine."

 

YOU sir, have captured the real spirit of WTF! I salute you. 

On the topic of the "True spirit of WTF", I have a question for you.  Imagine you're calculating the division of two 24-bit numbers, i.e. the floating point mantissas.  To divide one by the other, you bitshift the divisor up 8 bits and then do the division.  This, however, gives you only 8 bits of precision.  What do you do to increase your precision without resorting to numbers longer than 32-bit or high-level routines?

 (I've already answered this in my program in a truly WTF way: I want to see what others think ;) )

 My first response to that is to split everthing into "unsigned char"s, and instead of shifting, just tack an extra 0x00 on the bottom of the divisor.  Then, run it through a custom arbitrary precision math lib in 8 bits. 

 

I have a really cute method for this that gives me full precision, and there's no shifting of the divisor.  It's a successive subtraction method, but it will never go around more than 24 times. 

It's not a general-purpose integer division method, but it works great for these floating point mantissas where some simplifying assumptions can be made.

 

-JCM 

hey guys,

I need more information to guess what's going on.

 

With regards,

Mandar Thosar 

mandar-seo:

hey guys,

I need more information to guess what's going on.

 

http://news.bbc.co.uk 

mandar-seo:

hey guys,

I need more information to guess what's going on.

http://www.vbzoom.com/vz/

Just to be on the safe side, my first submission - PowerCalc version aplha1 has no bugs (or at least, passes all test cases without needing any special). However, PowerCalc version omega13 exhibits the following behaviour: Addition, subtraction or multiplication may randomly crash, if they are the first operation executed. I'm not intimately familiar with the register set-up process, but given random possible values in memory, it is feasible that any of them might try to access unbound memory. Division never crashes. Abbreviation, used below: C/D - Crashes/Doesn't work depending on the mercifulness of the memory state. Addition: C/D, if first operation. Prevents subtraction crashing right after a division. Breaks division, if result not zero. Subtraction: C/D, if first operation. Might not work, if right after a division. Do an addition or multiplication first. Doesn't work after a second multiplication. Breaks division, if result not zero. Multiplication: C/D, if first operation. Doesn't work correctly after a multiplication or a successful (addition or subtraction). Do a division by whole number, beforehand. Prevents subtraction crashing right after a division (but only if issued just once. If done twice or more consecutive times, subtraction breaks). Breaks division, if result not zero. Division: Division does not always work (but never crashes). If you get Err from seemingly normal division operations, do an addition, subtraction or a multiplication with a result, that is a whole number. 0+0= would do fine. Addition is preferred, because the other operations are probably broken. Division, that produces a possibly inexact result, gives an error, except when dividing by 5 (had to add it for the test cases). Possibly breaks multiplication. Divide by zero (or other whole number) to fix multiplication. Above are just instructions if you want correct results; the actual relationships are a bit more complex. Here's an example: Say, you do x*y and it works correctly (after you perform a division, perhaps). If next you do z*w, the result would be z*y, but only for a finite amount of multiplications - memory would run out. z-w, would also return z-y for any subtraction (no memory overflow).

Somebody should have mentioned that paragraphs must be enclosed in <p></p> and newlines noted with <br>. Please, delete my previous post.

Just to be on the safe side, my first submission - PowerCalc version aplha1 has no bugs (or at least, passes all test cases without needing any special).
However, PowerCalc version omega13 exhibits the following behaviour:

Addition, subtraction or multiplication may randomly crash, if they are the first operation executed. I'm not intimately familiar with the register set-up process, but given random possible values in memory, it is feasible that any of them might try to access unbound memory.Division never crashes.

Abbreviation, used below: C/D - Crashes/Doesn't work depending on the mercifulness of the memory state.

Addition:
C/D, if first operation.
Prevents subtraction crashing right after a division.
Breaks division, if result not zero.

Subtraction:
C/D, if first operation.
Might not work, if right after a division. Do an addition or multiplication first.
Doesn't work after a second multiplication.
Breaks division, if result not zero.

Multiplication:
C/D, if first operation.
Doesn't work correctly after a multiplication or a successful (addition or subtraction). Do a division by whole number, beforehand.
Prevents subtraction crashing right after a division (but only if issued just once. If done twice or more consecutive times, subtraction breaks).
Breaks division, if result not zero.

Division:
Division does not always work (but never crashes).
If you get Err from seemingly normal division operations, do an addition, subtraction or a multiplication with a result, that is a whole number. 0+0= would do fine. Addition is preferred, because the other operations are probably broken.
Division, that produces a possibly inexact result, gives an error, except when dividing by 5 (had to add it for the test cases).
Possibly breaks multiplication. Divide by zero (or other whole number) to fix multiplication.

Above are just instructions if you want correct results; the actual relationships are a bit more complex. Here's an example:
Say, you do x*y and it works correctly (after you perform a division, perhaps).
If next you do z*w, the result would be z*y, but only for a finite amount of multiplications - memory would run out.
z-w, would also return z-y for any subtraction (no memory overflow).