In UnitConvert::shallowBeautify, an orphan expression would be reduced
without reaffecting the reduction's result. The reduction not being
taken into account would cause problem when handling undef values.
ex : Try to calculate i->_min
Change-Id: I4e53afa40ba838fed8c2fba9944c9c9ed1dc95b4
Implemented std::nextafter to replace hand made one.
Methods next and previous are no longer making the difference between -0
and +0
Change-Id: I42e1a073623b70656d9df954694803840cf3088c
Method characteristicXHalfRange was used to compute the range on which
to display cartesian function in Graph. With the new zoom algorithm,
this method is deprecated.
Change-Id: Ic681fab8d58d0f5628a94302a7b49dacaaa1a6a3
In Graph, the weak ReductionTarget would cause _X^0 to not be simplified
to 1, and would break an assertion in
Unit::chooseBestRepresentativeAndPrefix.
Change-Id: I8167a472802baf0a73bf48513f492e78517107ef
When factoring 1^inf * 1^-inf with Multiplication::factorizeBase, an
Undef factor would appear an be carried into the reduced multiplication.
We escape early in this situation by returning Undef.
Change-Id: Id826ad3cc131349e5bb460f7a8c82fe606294b97
The addSibling method sometimes did not take into account the offset
introduced by adding parentheses, leading to some issues :
- Type 2 SQUARE RIGHTPARENTHESIS LEFT SQUARE. Parentheses are added
but the new square should be outside, between the two right
parentheses.
Change-Id: Ifbc49cee2cd03c4511fc5a678d6d5d42243f4a22
When typing Square in 2D Edition mode, the cursor would not be
repositionned correctly, leading to some issues :
- Typing 2 POW 3, pressing RIGHT to return to the baseline, then
typing POW again adds parentheses around 2^3, as is mathematically
correct. Typing 2 SQUARE, then POW, would show 2^2^_, while
the user really typed (2^2)^_.
Change-Id: I29c01d964924907a1866490189ea56e40771521d
With the imperial system selected, volumes are expressed as volume in
Calculation's results, instead of cubic lengths.
Change-Id: Ib6c0a1a595dce8ae8db6371b41af818b3fdc6236
In additional outputs, a volume is now splitted as :
_gal+_qt+_pt+_cup
instead of :
_gal+_cup+_floz
Change-Id: I5020afbab23be6331d8a8742fd6295db178f0b37
1. Information about a unit's dimension now uses inheritance.
_m is an instance of DistanceAlias, which is derived from Alias.
A UnitNode now keeps a pointer to an Alias and one to a Prefix.
All aliases are still defined as constexpr.
This cleans up a lot of the code used namely for computing the
additional outputs in Calculation.
2. Instead of being defined with a string, each unit is described by its
ratio with the base SI unit (ex: _L is 0.001 instead of "0.001_m^3").
This greatly speeds up the calculations using units, as the algorithm
to find the best unit used to parse the definition.
Change-Id: I4d6ed6ad4cb967026a3f01a335aec270066e2b9f
The symbol for pint (_pt) conflicts with the symbol for pico-tonne. To
solve that, prefixes for tonnes are now restricted to the positive
prefixes : k, M, G, T.
Change-Id: Ie968374bbb5e0ebd2c0f08e4b1bdc1708eb6a041
The additional results on units now include conversions into both unit
systems (metric and imperial).
Change-Id: Ie0f12eb3735e775560b66c2cbd78bc9a659145bb
Added methods to return the standard format for each dimension,
depending on the chosen unit system.
Change-Id: I3591a806beca315674cc09093b57e8753db5db6a
A split (such as _h+_min+_s) can now be generated for distances, volumes
and masses using imperial units.
Change-Id: Ib3ad63614979eddd02fbe0e99f16cf09dcf7c1fc
BuildTimesplit (used to create expressions of the form h+min+s) is now
based on the more general BuildSplit.
Change-Id: I3e55359cc6b9735269140942b29bd1d364fc35e7
When the country is USA, the units will be simplified to common imperial
units rather than metric.
Change-Id: Ia533527a429ac26526380e324b9543b359f3b400
The new units are :
distance mile, yard, foot, inch
mass pound, ounce
volume gallon, quart, pint, cup, fluid ounce
table spoon, tea spoon
Change-Id: I6864067a1822a077764ed3b61fc46004732e9447
Multiplication::privateShallowReduce can create an Undef node by
multiplying 0 and inf. In this case, we set the whole multiplication to
undef, to avoid things such as undef*π.
This fixes the following bug :
- In Graph, enter i*inf*π as one of the bounds. An assertion fails in
Multiplication::removeUnit.
Change-Id: Ie9d0d561d6e310f52220b98541f22a4b5e56762c
Changed previousNestedIntegral method to prevent integrals located in
integral bounds to be considered as nested.
Change-Id: Id8cc4369f53c278ac59039fde1c2818af2ccacab
Float<float> and Float<double> used to share the same expression type
(Float), and the distinction was made by comparing their size. However,
due to padding, their size could be the same, leading to some issues :
- On the simulator, in Calculation, type 1_mm^3 and go to the
additional outputs. One of the results would be -0.0003081979_µm^3.
Change-Id: Ic8f9328bf462104776fbab636c34d0d152cd7e58
This fixes issues #1541. Formulas as asin(sin(X)) with X a large number
were failling to simplify themselves into the image interval of asin
ex : previous version asin(sin(6)) = 6
new version asin(sin(6)) = -2pi+6
Change-Id: Ia6200b67914224cecd2cd943bcf9bc2ff6e0447a
To prevent incorrect approximations, such as cos(1.5707963267949) = 0, we lowered the precision value. This way,
the approximation is more selective. However, when ploting functions such as e^(i.pi+x), the float approximation fails
and therefore, the function appears "undef".
As a result we created two functions Epsilon that behave differently according to the number's type. When it is a double,
we want a maximal precision -> epsilon_double = 1x10^(-15), and when it is a float, we accept more agressive approximations
-> epsilon_float = 10 x 1x10^(-7).
Change-Id: I844ac52ade665f51fe6888db38f4485c193286d9
