I don't understand why the following does not work:
Main> 2.1 + 2.3
Error: Can't find an implementation for FromDouble Integer.
(Interactive):1:1--1:4
1 | 2.1 + 2.3
^^^
It works with integers, and if I understand the docs correctly, it should work with doubles too!
I get the same error with 2.1 * 2.3, but 2.1 - 2.3 and abs 2.1 work fine, which gives me the impression that there is a problem with the Num interface. However I'm a total beginner in Idris, so maybe I'm missing something very silly! I could not find any example of summing doubles on the web…
(I compiled Idris2 from the latest commit on github — 69f680e10a336c4f33414cfd55c13d41b68d735b.)
Edited to add: 2.1 + 2.3 actually works in a file (defining a constant), the problem only occurs in the REPL. I guess I'll have to file a bug.
Related
I am programming an application in Kotlin that converts radians to degrees and vise-versa. I was testing it with JUnit and received this error.
// The code I ran
assertEquals(60.0, radians.toDegrees())
// The stacktrace
org.opentest4j.AssertionFailedError:
Expected :60.0
Actual :59.99999999999999
There is nothing I can do about this, as the program was dividing by PI and then multiplying by PI later on. I was wondering if there was a way I could run a comparison that would count this as a success because the values are close enough. In Python, you can use assertAlmostEqual() with a couple of parameters. What is the equivalent of doing this with JUnit.
I am using JDK 11, Java 8, Kotlin 1.3(whatever the latest version is)
In JUnit 4 and JUnit 5 you can specify a delta in the method when comparing doubles, specifying how much variance you are willing to tolerate.
assertEquals(60.0, myValue, 0.005);
There's also the Hamcrest IsCloseTo matcher, which sounds more like what you're used to.
I'm writing this post in case anyone else is having the same issue I've been having with the lack of documentation for the CVDisplayLink API.
Intro:
In my CVDisplayLink code I've been using the following code to obtain the deltaSeconds value between calls to its callback:
float deltaTime = 1.0 / (outputTime->rateScalar * (float)outputTime->videoTimeScale / (float)outputTime->videoRefreshPeriod);
It seems like this line of code is widely used across different apps & engines.
The issue:
While running my OpenGL app I've noticed that this value is now constant (0.016669 to be precise). I haven't made any big changes to account for this change of behaviour, other than using Mavericks and the new development tools.
Finding the cause has been a lost cause so far.
I've found what I believe is a good way to calculate the deltaSeconds between frames by using the following alternative code:
double deltaSeconds = (outputTime->videoTime - self.previousOutputVideoTime) / (double)outputTime->videoTimeScale;
self.previousOutputVideoTime = outputTime->videoTime;
"foo": "~0.2.1"
"foo": ">= 0.2.1"
What's the difference?
>= means any version equal or bigger to the mentioned release. For example 42.42.42 would be fine with >= 0.2.1 requirement (no matter how incompatible it would be in practice). Also, it means that 0.2.1-beta is not fine, as beta was before final release.
~ means reasonably close to the specified version (as in, compatible). It takes the semantic versioning definition, so any major version jumps aren't considered to be compatible (higher than the last number in specified version). For example, 42.42.42 or 0.3.0 is not fine with ~0.2.1 requirement. However, 0.2.1-beta or 0.2.42 is allowed, as it's reasonably close to the final version.
Tilde means next significant release. In your case, it is equivalent to >= 2.0, < 3.0.
A simple rule-of-thumb way is that the ~ allows the last digit to go up. e.g. ~2.2 means 2.2 and any 2.x where x is 2 or above. ~2.1.3 on the is also any 2.1.x where x is 3 or above.
http://getcomposer.org/doc/01-basic-usage.md#package-versions
I am trying to solve the following equation in my program:
7.7^2 x 0.012^2/(0.2145 x 1.67^(16/3))
That should equal : 0.002582 (this is verified w/ google & scientific calculator)
This is the code that I am using
CGFloat eX1 = pow(7.7, 2) * pow(0.012, 2)/(0.2145 * pow(1.67, (16/3)));
NSLog(#"%f",eX1);
And even though, I believe my code should give me the same results, it's actually giving me:0.002679
What am I doing wrong? What can I do to obtain the correct answer?
Change (16/3) to (16.0/3.0). Otherwise 16/3 results in 5, not 5.33333349.
And you have 7.2 instead of 7.7 at the start.
This is, at least for me, most bizzare Visual Studio 2010 behaviour ever. I'm working on MVC3 project, I copied a line of code from another project (VS2010 also, MVC1 if it matters) which looks like this:
target_height = height * 1.1
when I paste it into MVC3 project, it gets expanded to
target_height = height * 1.1000000000000001
Now, if I type 1.2, it's fine, nothing happens, but if I type 1.12 it is expanded to 1.1200000000000001.
Both target_height and height are integers. Why does one Visual Studio display 1.1 while other expands it to 1.1000000000000001?
What is going on???
I think it is autocomplete went crazy and started fixing floating points constant into "allowed" values. As written in http://accessmvp.com/Strive4Peace/VBA/VBA_L1_02_Crystal.pdf , VB autocomplete really tries to offer only "things that apply specifically to that data type". int * double is understandably not truncated into int * int (automatic conversions always happen only as needed) and what you see is double representation of 1.1 or 1.12 (epsilon = 1.11e-16).
I think it would still need some further checking or verification to learn exact conditions when this happens, but as I am not using VB.NET or MVCx this is not something I am willing to do.
The numerical literal 1.1 does not actually represent the quantity 11/10, but instead represents the quantity round[(2^53*11)/10]/(2^53), which is a tiny bit larger than 11/10. Although that value could be written out precisely as a decimal number with 53 significant figures, doing so would be about as useful as using an inch-denominated measuring tape to determine that something is 1 3/16" long and recording the measurement as 30.1625mm. If one wouldn't be able to distinguish a measurement that was longer or shorter or shorter by less than 1/64", the measurement would be 30.1625mm +/- 0.396875mm, which is functionally the same as 30.2mm +/- 0.4mm.
The fact that Visual Studio would choose to represent the numeric quantity closest to 1.1 as 1.1000000000000001 is curious. On the one hand, the literal 1.1 would be a more concise representation of the same value. On the other hand, even if the aforementioned literal would be indistinguishable from 1.1, the more verbose representation is not without advantage. In some cases, it may be helpful to know whether a quantity is slightly larger or slightly smaller than what it "appears" to be. Even though the difference between the numeric literal 1.1 and the mathematical value 11/10 is numerically insignificant (multiplying the numeric literal by ten yields precisely 11), the difference between (1.1-1.0) and (1/10) is noticeable (multiplying the numeric expression by 10 yields a value greater than one).
1.1 and 1.12 must not have an exact binary representation.
see this : https://stackoverflow.com/questions/634206/what-every-programmer-should-know-about