Merge lp://qastaging/~toineo/unity-lens-applications/calculator into lp://qastaging/unity-lens-applications

excellent work, sponsoring, thanks!

opss, wrong window, sorry, was looking at another merge, will look at the one later ;)

Hey toineo,

Thanks for this awesome work!
so some comments on the proposed branch:

+ if ((result = process_easter (ref search_string, ref model)) != 0)
I would just make process_easter returns true or false and don't care about the result (we don't really need to differentiate them)

----------------

549 + string uri;
550 + Icon icon;
551 + uri = "unity-calc";
552 + string result_string = _(format_result_output (search_string, result));
-> can you pease fix the ident?

575 + string uri;
576 + Icon icon;
577 + uri = "unity-calc";
578 + string result_string = _(format_result_output (search_string, result));
-> same remark

Btw, you have this code twice, can you try a while loop with an arg being true as long as the result is invalid and we can still tweak the search by adding ')' and such?

----------------------

63 + private Gee.HashMap<string,DelegateWrapper1> TwoLettersFct;
64 + private Gee.HashMap<string,DelegateWrapper1> ThreeLettersFct;
65 + private Gee.HashMap<string,DelegateWrapper1> FourLettersFct;
66 + private Gee.HashMap<string,DelegateWrapper1> FiveLettersFct;

As we discussed, I would prefer an double HashMap with 2,3,4,5 has a primary index to select the right subhashmap reference

------------------------
256 + /* FIXME : at this time, something like tan7 is evaluated
257 + * as tan(7). Do we accept this behavior ? */

-> it's fine for now ;)

Awesome work! can you please look at those remarks and see how to fix them? The rest looks good :-)

Thanks again for working on that!

Didrocks, fix commited for this. Thank you for reviewing, and for your help !

History should now show with an empty search, as in the trunk version.

The merge request is frozen for now. I have fixed the bug of bad double printing (e.g something like 2.1 that was printed as 2.0999999999998) -- and I should push those changes --, but we still have difficulties to know if the computation was exact or not (and that will be clearly visible to the user, through the equal sign (= or ≈, depending on the case)).

I see 3 way to fix it :
- Add some code to the equation parser that detects approximations. This should work for many simple (or not so simple) cases, but would probably still fail on more difficult ones.
- Use an external binding for a bignum (including bigfloat) library. With a good library, we should make almost no error telling if the computation was exact or not. Unfortunately, I found no such binding for vala...
- Write an implementation of bignums directly in the parser. But it would take some time, in particular for some operations/functions. Moreover, it would be like reinventing the wheel...

If anyone had a solution or something that could help, it would be greatly appreciated !

(Sorry for my *bad* English...)

The simpler solution the better I'd say. Pulling in some numeric lib
just to support this seems way out of proportion; writing custom
arbitrary precision math routines or advanced parsers is way out of
scope for something that's definitely never intended as a full fledged
calculator.

If we can just always get a sensible result I think it is good enough
- no need to differentiate = or ≈. If people care about high precision
math I don't think the dash is the place to look for it. - or it would
have to go in a dedicated math lens at the very least (woohoo, i see
symbolic equation solvers coming in ;-))

Thank you for your answer Mikkel !

Well, last time I discussed with Didier, he told me he really prefers a calculator with an accurate differentiation of = and ≈, and that an user who asks to compute something like 10^18 + 2 (but less obvious, of course) will be unhappy with a result of 1×10¹⁸ and nothing indicating it is an approximation. I agree with it -- even if, you are completely right, it is not intended to be a precision calculator. It is just that it is a pity not to be able to warn the user ; but I agree, the means have to be commensurate with the goals.

For a version with no equal/approximate sign (or with the same sign whatever the computation), the last revision of this branch should be almost ready for review (it only needs a fix for the bug of broken function calls), I have not currently found other bugs.

I find the idea of a math lens great ! It would be a killer feature ! It could completely go along with the alt-f2 calculator (which is only for some quick results, and could possibly have a link to the math lens). I want it :D

(Same thing, sorry for my english...)

Now, the branch should be up-to-date with trunk.

(I switch to abstain because I cannot switch to "needs reviews")