* Replacing CalculatorVector usage with std::vector
Assumptions made here are that memory allocations
are not recoverable. If it can be proved that an index
will be in range, then the indexing operation is used.
If not (without manual checks) the std::vector::at function
is used to throw an exception in case of a programmer bug.
* Changes based on PR feedback
Using auto& in CalculatorCollector::UpdateHistoryExpression
so the token.first value is properly updated.
Using range for loop to GenerateExpressions.
Setting isEditable directly to the result of boolean expression.
Using token.second directly instead of creating a
separate tokenCommandIndex variable.
* Fixing issue with generating expressions strings.
A space should not be added before the first item.
Description of the changes:
Adjusted some of the values in .clang-format
Add clang-format-all.ps1
Fix path to .clang-format in Calculator.sln
How changes were validated:
Manual.
Fixes#202
This PR fixes code style for the project files.
The Problem
Different files in the project use different code style. That is not consistent and leads to harder maintenance of the project.
Description of the changes:
Have investigated and determined the most used code style across the given codebase
Have configured IDE and applied code style to all project files.
Have crafted clang-formatter config.
see https://clang.llvm.org/docs/ClangFormat.htmlhttps://clang.llvm.org/docs/ClangFormatStyleOptions.html
Some cases were fixed manually
How changes were validated:
manual/ad-hoc testing, automated testing
All tests pass as before because these are only code style changes.
Additional
Please review, and let me know if I have any mistake in the code style. In case of any mistake, I will change the configuration and re-apply it to the project.
## Fixes#111
> The modulo operator on this calculator gives the result that is different to the most used calculators.
The current `modrate` function is the equivalent of rem(...)/remainder(...), not mod(...)/modulo(...) available in some popular Math apps.
### Description of the changes:
- rename `modrate` in `remrate` to be more accurate.
- add `modrate`, calculating modulo similarly to Matlab, Bing, Google calculator, Maxima, Wolfram Alpha and Microsoft Excel
- Add `RationalMath::Mod` using `modrate` as an alternative to `Rational::operator%` using `remrate`
- Add a helper `SIGN` to retrieve the sign of a `Rational`.
- modify `CalcEngine` to use `modrate` in Normal and Scientific mode and `remrate` in Programmer mode.
### How changes were validated:
- manually and unit tests added
Description of the changes:
Currently Calculator handles strings by defining integers for each type of function that can be performed, this integer will eventually correspond with an index in s_engineStrings which holds the corresponding display string for each function. Some functions such as Sin can have multiple strings (degrees, rads, grads, inverse). Functions like Sin are mapped to another array called "rgUfne" where a new integer is given depending on the output string which will then be given to s_engineStrings. The new integer returned by the "rgUfne" array runs the risk of overlapping with any new functions that may be added in CCommand.h. Furthermore, it is expected that the strings in s_engineStrings and rgUfne are defined in a particular order (not necessarily sequential), otherwise the logic will break. This makes adding new strings for new functions confusing and difficult, since a lot of the logic is not clearly defined.
This PR attempts to make this a bit simpler by changing the s_engineStrings and rgUfne arrays to be unordered_maps instead of arrays. For s_engineStrings the keys will now be strings, allowing the existing logic for indexing to be used by simply converting the number into a string to access the value. This will also allow us to create keys in the future that are not limited to integers but to strings that hold more meaning.
The rgUfne array will also be updated to be a map that will take in an integer and give you the corresponding string that can be passed to s_engineStrings. The UFNE object in the rgUfne array will also be updated to hold all the possible string keys for a function, instead of indexing them on other numbers that may overlap with existing definitions.
Now to add a new string for a new IDC_FOO function, we would just need to add the "FooString" resource keys to the g_sids array and use the updated rgUfne map to link the IDC_FOO value to the corresponding "FooString" resource key. This way the resource key can be a meaningful string, and not an integer that must be in any particular order.
How changes were validated:
Tested each function manually in standard, scientific, and programmer modes.
The conditional m_precedenceOpCount >= 0 was always true because m_precendenceOpCount is an unsigned type. Update the conditional to simply be true and rely on a break statement in the loop. Although this member variable used to be a signed type, in practice, the value was never less than 0.
How changes were validated:
Manual. Unit tests pass locally.
Fixed comments that were inconsistent with the style guidelines described in C++ core guidelines and the modern C++/WinRT language projections and removed trailing whitespace.
Inserted a space after the beginning of the comment so the text wasn't touching the // on all occurrences.
Removed all occurrences of trailing whitespace
* Convert Rational::Negate to an operator override
* Convert Rational::Add to + and += operator overrides.
* Convert Rational::Sub to - and -= operator overrides.
* Convert Rational::Div and ::Mul to use /, /=, *, *= operator overrides.
* Convert Rational::Mod to use %= and % operator overrides
* Convert Rational::Rsh and ::Lsh to use >>=, >>, <<=, << operator overrides
* Convert Rational::And, ::Or, ::Xor to use &=, &, |=, |, ^=, ^ operator overrides
* Convert Rational relational functions to operator overrides
* Remove unnecessary precision arguments from Rational class and remove use of explicit Rational constructors in favor of implicit conversions for value types
* Remove unnecessary precision variable from RationalMath operations
* Replace unnecessary Rational::Not with Xor operation
* Remove unnecessary Rational::IsZero() in favor of == 0 comparisons
* Fix rounding issues in ratpak that result from using large precisions.
* Move assignment stmt out of IsCurrentTooBigForTrig
This change moves the RADIX_TYPE enum into its own header. This resolves a compilation error and reduces the dependency graph by allowing RadixToStringConverter to include just the enum header rather than the entire CalcEngine header.
Change verified by ensuring Calculator build locally.
Before this change, the pchs for CalcViewModel and Calculator project referenced project headers. If those project headers (or any of their dependencies) were to change, then the pch would be recompiled, slowing local build times.
By removing references to project headers, the pch will be compiled once and is resilient to changes in the project. Now that project headers are explicit about their dependencies, when there is a change to a project header only the translation units referencing the modified header will need to be rebuilt.
- Manually tested by ensuring Calculator project builds locally.
@Microsoft/calculator-team
