I am using a LinearProgressIndicator to visually display a countdown of time and trigger a function at certain intervals. I am doing this by updating the LinearProgressIndicator's value prop using a state variable _progress that gets decremented by 0.01 each 100 milliseconds.
When I set conditions that were based on two decimal points, or even 0 if (_progress == 0.75), I discovered that the conditions were being skipped because the value of _progress was quickly becoming a much larger fraction that would not match my condition (e.g. 0.7502987777777). I assume this is an inherent issue of working with doubles, but my question then becomes, what is the best way to deal with this if you want to trigger actions based on the value of _progress? My approach is to broaden the conditions - for example if (_progress > 0.75 && _progress < 0.76).
Any tips/advice would be appreciated.
Thanks.
When dealing with floating-point values, you often cannot depend on strict equality. Instead you should check if the floating-point value you have is within a certain tolerance of the desired value. One approach:
bool closeTo(double value1, double value2, [double epsilon = 0.001]) =>
(value1 - value2).abs() <= epsilon;
if (closeTo(_progress, 0.75)) {
// Do something.
}
(package:matcher has a similar closeTo function for matching values in tests.)
Arguably, since floating-point values are floating, your tolerance should depend on the magnitude of the values.
In your case, you alternatively should strongly consider avoiding floating-point values for internal state: use fixed-point values by multiplying everything by 100 and using ints instead. That is, let _progress be an int, decrement it by 1 every 100 ms, and then you can compare against 75 or other values directly and exactly. This additionally would have the advantage of not accumulating floating-point error when you repeatedly decrement _progress. If you need to present _progress to the user or pass it to LinearProgressIndicator, use _progress / 100 instead.
Related
I am trying to get remainder using swift's truncatingRemainder(dividingBy:) method.
But I am getting a non zero remainder even if value I am using is completely divisible by deviser. I have tried number of solutions available here but none worked.
P.S. values I am using are Double (Tried Float also).
Here is my code.
let price = 0.5
let tick = 0.05
let remainder = price.truncatingRemainder(dividingBy: tick)
if remainder != 0 {
return "Price should be in multiple of tick"
}
I am getting 0.049999999999999975 as remainder which is clearly not the expected result.
As usual (see https://floating-point-gui.de), this is caused by the way numbers are stored in a computer.
According to the docs, this is what we expect
let price = //
let tick = //
let r = price.truncatingRemainder(dividingBy: tick)
let q = (price/tick).rounded(.towardZero)
tick*q+r == price // should be true
In the case where it looks to your eye as if tick evenly divides price, everything depends on the inner storage system. For example, if price is 0.4 and tick is 0.04, then r is vanishingly close to zero (as you expect) and the last statement is true.
But when price is 0.5 and tick is 0.05, there is a tiny discrepancy due to the way the numbers are stored, and we end up with this odd situation where r, instead of being vanishingly close to zero, is vanishing close to tick! And of course the last statement is then false.
You'll just have to compensate in your code. Clearly the remainder cannot be the divisor, so if the remainder is vanishingly close to the divisor (within some epsilon), you'll just have to disregard it and call it zero.
You could file a bug on this but I doubt that much can be done about it.
Okay, I put in a query about this and got back that it behaves as intended, as I suspected. The reply (from Stephen Canon) was:
That's the correct behavior. 0.05 is a Double with the value 0.05000000000000000277555756156289135105907917022705078125. Dividing 0.5 by that value in exact arithmetic gives 9 with a remainder of 0.04999999999999997501998194593397784046828746795654296875, which is exactly the result you're seeing.
The only rounding error that occurs in your example is in the division price/tick, which rounds up to 10 before your .rounded(.towardZero) has a chance to take effect. We'll add an API to let you do something like price.divided(by: tick, rounding: .towardZero) at some point, which will eliminate this rounding, but the behavior of truncatingRemainder is precisely as intended.
You really want to have either a decimal type (also on the list of things to do) or to scale the problem by a power of ten so that your divisor become exact:
1> let price = 50.0
price: Double = 50
2> let tick = 5.0
tick: Double = 5
3> let r = price.truncatingRemainder(dividingBy: tick)
r: Double = 0
I have 2 real numbers ( e.g. a , b). Is there any way to know whether is their division's result natural number?
I have tried
a mod b {to check if the result is 0}
but "mod" doesn't work for real numbers.
Also
a/b-trunc(a/b) {but sometimes the answer isn't 0}
I'm beginner, please, whether is there any other way, let me know.
Using Frac could be one idea as #Sertac mentions. But since binary floating point does not represent all real numbers, there could be cases where the fraction could end up close to zero (or one for that matter) as well.
Here is a simple routine that avoids testing for both close to one or zero:
function IsNaturalNumber( value : Double) : Boolean;
const
epsilon : Double = 1E-12;
begin
IsNaturalNumber := Abs(value - Round(value)) < epsilon;
end;
var
A,B : Double;
begin
A := 3.3;
B := 1.1;
WriteLn(IsNaturalNumber(A/B)); // Writes TRUE
end.
The function tests if the absolute difference between the value and the value rounded to nearest integer is smaller than a reasonable limit.
Note that there is no absolute certainty. That would require using a decimal floating point arithmetic library.
I will leave it up to the interested reader to implement the exclusion of integer numbers that is outside the range of the natural numbers, whether that is all negative numbers including zero or not.
If the values to test are larger than the upper range of the Round() function, use an equivalent floating point function. In Delphi that is Math.RoundTo(value,0).
Apologies if the question is poorly phrased, I'll do my best.
If I have a sequence of values with times as an Observable[(U,T)] where U is a value and T is a time-like type (or anything difference-able I suppose), how could I write an operator which is an auto-reset one-touch barrier, which is silent when abs(u_n - u_reset) < barrier, but spits out t_n - t_reset if the barrier is touched, at which point it also resets u_reset = u_n.
That is to say, the first value this operator receives becomes the baseline, and it emits nothing. Henceforth it monitors the values of the stream, and as soon as one of them is beyond the baseline value (above or below), it emits the elapsed time (measured by the timestamps of the events), and resets the baseline. These times then will be processed to form a high-frequency estimate of the volatility.
For reference, I am trying to write a volatility estimator outlined in http://www.amazon.com/Volatility-Trading-CD-ROM-Wiley/dp/0470181990 , where rather than measuring the standard deviation (deviations at regular homogeneous times), you repeatedly measure the time taken to breach a barrier for some fixed barrier amount.
Specifically, could this be written using existing operators? I'm a bit stuck on how the state would be reset, though maybe I need to make two nested operators, one which is one-shot and another which keeps creating that one-shot... I know it could be done by writing one by hand, but then I need to write my own publisher etc etc.
Thanks!
I don't fully understand the algorithm and your variables in the example, but you can use flatMap with some heap-state and return empty() or just() as needed:
int[] var1 = { 0 };
source.flatMap(v -> {
var1[0] += v;
if ((var1[0] & 1) == 0) {
return Observable.just(v);
}
return Observable.empty();
});
If you need a per-sequence state because of multiple consumers, you can defer the whole thing:
Observable.defer(() -> {
int[] var1 = { 0 };
return source.flatMap(v -> {
var1[0] += v;
if ((var1[0] & 1) == 0) {
return Observable.just(v);
}
return Observable.empty();
});
}).subscribe(...);
I have some code to convert a time value returned from QueryPerformanceCounter to a double value in milliseconds, as this is more convenient to count with.
The function looks like this:
double timeGetExactTime() {
LARGE_INTEGER timerPerformanceCounter, timerPerformanceFrequency;
QueryPerformanceCounter(&timerPerformanceCounter);
if (QueryPerformanceFrequency(&timerPerformanceFrequency)) {
return (double)timerPerformanceCounter.QuadPart / (((double)timerPerformanceFrequency.QuadPart) / 1000.0);
}
return 0.0;
}
The problem I'm having recently (I don't think I had this problem before, and no changes have been made to the code) is that the result is not very accurate. The result does not contain any decimals, but it is even less accurate than 1 millisecond.
When I enter the expression in the debugger, the result is as accurate as I would expect.
I understand that a double cannot hold the accuracy of a 64-bit integer, but at this time, the PerformanceCounter only required 46 bits (and a double should be able to store 52 bits without loss)
Furthermore it seems odd that the debugger would use a different format to do the division.
Here are some results I got. The program was compiled in Debug mode, Floating Point mode in C++ options was set to the default ( Precise (/fp:precise) )
timerPerformanceCounter.QuadPart: 30270310439445
timerPerformanceFrequency.QuadPart: 14318180
double perfCounter = (double)timerPerformanceCounter.QuadPart;
30270310439445.000
double perfFrequency = (((double)timerPerformanceFrequency.QuadPart) / 1000.0);
14318.179687500000
double result = perfCounter / perfFrequency;
2114117248.0000000
return (double)timerPerformanceCounter.QuadPart / (((double)timerPerformanceFrequency.QuadPart) / 1000.0);
2114117248.0000000
Result with same expression in debugger:
2114117188.0396111
Result of perfTimerCount / perfTimerFreq in debugger:
2114117234.1810646
Result of 30270310439445 / 14318180 in calculator:
2114117188.0396111796331656677036
Does anyone know why the accuracy is different in the debugger's Watch compared to the result in my program?
Update: I tried deducting 30270310439445 from timerPerformanceCounter.QuadPart before doing the conversion and division, and it does appear to be accurate in all cases now.
Maybe the reason why I'm only seeing this behavior now might be because my computer's uptime is now 16 days, so the value is larger than I'm used to?
So it does appear to be a division accuracy issue with large numbers, but that still doesn't explain why the division was still correct in the Watch window.
Does it use a higher-precision type than double for it's results?
Adion,
If you don't mind the performance hit, cast your QuadPart numbers to decimal instead of double before performing the division. Then cast the resulting number back to double.
You are correct about the size of the numbers. It throws off the accuracy of the floating point calculations.
For more about this than you probably ever wanted to know, see:
What Every Computer Scientist Should Know About Floating-Point Arithmetic
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thanks, using decimal would probably be a solution too.
For now I've taken a slightly different approach, which also works well, at least as long as my program doesn't run longer than a week or so without restarting.
I just remember the performance counter of when my program started, and subtract this from the current counter before converting to double and doing the division.
I'm not sure which solution would be fastest, I guess I'd have to benchmark that first.
bool perfTimerInitialized = false;
double timerPerformanceFrequencyDbl;
LARGE_INTEGER timerPerformanceFrequency;
LARGE_INTEGER timerPerformanceCounterStart;
double timeGetExactTime()
{
if (!perfTimerInitialized) {
QueryPerformanceFrequency(&timerPerformanceFrequency);
timerPerformanceFrequencyDbl = ((double)timerPerformanceFrequency.QuadPart) / 1000.0;
QueryPerformanceCounter(&timerPerformanceCounterStart);
perfTimerInitialized = true;
}
LARGE_INTEGER timerPerformanceCounter;
if (QueryPerformanceCounter(&timerPerformanceCounter)) {
timerPerformanceCounter.QuadPart -= timerPerformanceCounterStart.QuadPart;
return ((double)timerPerformanceCounter.QuadPart) / timerPerformanceFrequencyDbl;
}
return (double)timeGetTime();
}
How do I test if two dates are within a certain tolerance in NUnit?
You may want to look at the "Within" method that lives off of the Constraint object.
For example:
Assert.That(DateTime.Now, Is.EqualTo(DateTime.Now.AddMilliseconds(1000)).Within(101));
It's usually used to give a tolerance to doubles and floats, but since in the end a DateTime is a double, it might suit your needs.
TimeSpan tolerance = new TimeSpan(0,1,0); // e.g. 1 minute
Assert.IsTrue((firstDateTime-SecondDateTime).Duration() > tolerance);
Convert your tolerance to Ticks and then use an And constraint. Something like;
long ticks = mydate.Ticks;
long tolerance = 1000;
Assert.That( ticks, Is.LessThan( ticks + tolerance ) & Is.GreaterThan( ticks - tolerance ) );
I would create an extension method or your own Assert to do this though.
Subtract one from the other, which gives you a TimeSpan value, use the TotalXYZ properties (like TotalMilliseconds) to get a value, use Math.Abs on it to convert it to a always-positive value, and check against your tolerance value.
For instance, if they need to be within 10 milliseconds of each other:
if (Math.Abs((dt1 - dt2).TotalMilliseconds) <= 10)
{
CloseEnough();
}