I'm writing my first test in unity3d. My objective is to assert that as the player runs, the Z axis remains consistent and the height doesn't change. In other terms, the Character's z position is consistently a 1 value.
This test continuously fails with the output of:
AssertionException: FloatComparer assertion failed.
Character.Transform.up.z CompareToConstantValue 1 failed. Expected: 1 Actual: 1
Created in
UnityEngine.Debug:LogException(Exception, Object)
UnityTest.ActionBase:Fail(AssertionComponent) (at Assets/UnityTestTools/Assertions/Comparers/ActionBase.cs:93)
UnityTest.Assertions:CheckAssertions(AssertionComponent[]) (at Assets/UnityTestTools/Assertions/Assertions.cs:37)
UnityTest.Assertions:CheckAssertions(AssertionComponent) (at Assets/UnityTestTools/Assertions/Assertions.cs:18)
UnityTest.AssertionComponent:CheckAssertionFor(CheckMethod) (at Assets/UnityTestTools/Assertions/AssertionComponent.cs:251)
UnityTest.AssertionComponent:Update() (at Assets/UnityTestTools/Assertions/AssertionComponent.cs:148)
The expected/actual values are the same so I'm struggling to see what the problem is. Any insight would be appreciated.
Because it's a float, I tried using 1.0 as the constant value with no luck.
The value might not be exactly 1, but your assertion tells the test to expect it as EXACTLY 1.
But floating points variable are not to safe to test to exact values.
So you could try allow a minimum difference of your wanted value using the "Floating Point Error" field in the inspector.
For example if your value is expected to be 1
But in reality your floating point (can be) 0.99998...
Then you can set Floating Point error to 0.0001
So the assertion will pass with values between 0.999900000... and 1.000100000...
And your value of 0.99998 woule be in between and pass.
This issues ocure with all floating point numbers so also with the values of vector pistions for example
EDIT:
So the exception you see is also having this issue thinking that actual is 1 but it isn't, it's... nearly almoast 1^^
Related
What function that depends by following variablesc (First Operand's sign[0/1], Second Operand's sign[0/1], Result's sign[0/1] and Operation sign[0/1]) can identify an overflow in the 4-bit ripple-carry adder/substractor?
P.S.
An overflow occurs only if:
the sum of two positive numbers yields a negative result, the sum has overflowed.
the sum of two negative numbers yields a positive result, the sum has overflowed.
I only know the method with checking the 2 last carries but it seems that there's another method.
Your PS already contains the correct logic formula written in prose (for addition). Remember that a number is "positive" if its sign bit is zero and the number is negative if its sign bit is one.1 This means you can translate "yields a negative result" to "the operation sign is 1". You can translate the other statements about operands or results to logic conditions in the same way, to finally derive a general boolean formula.
1: I know that zero is neither positive nor negative, but treating zero as positive does no harm in this case.
When I run an app where an icon, wrapped in a Positioned is drawn on a container, I get an error stating that the offset, (Positioned's left) uses a NaN value. I took a look online and I found that NaN means Not a Number, but I couldn't find what causes it. I mean, If I divide a number by Zero I'll get an error saying that I cannot divide a number by zero, but NaN is a constant for what I understood, and if I was multiplying a number let's say for a string I'd get incompatible types error, instead of NaN. I'm not asking for an answer specific for my code as I couldn't provide it, but rather a more general explanation.
NaN could be caused by dividing by a variable which cannot be cast to a numbe as #JoSSte stated.
But as I found out empirically, Flutter does not throw an error while dividing by 0, as opposed to python for example where ZeroDivisionError is thrown. Flutter sees the output of a division by zero as infinity or -infinity, when dividing respectively a positive and a negative number by zero.
So this makes sense, but in instances when infinity cannot be accepted as a value (as it isn't) it throws an error stating there was an error in the framework itself.
I'm trying to determine what tie-breaking rounding rule Oracle Forms uses to round decimal numbers fetched from the database for display in a shorter-length field. Specifically, when a number is equidistant from its neighbors (e.g. 0.5 is equidistant from 0 and 1), what rule is used to determine whether it's rounded up or down (see this for a reference on standard rounding rules)? The Forms online help documentation addresses rounding, but does not specify which rounding rule is used (e.g. half away from zero, half even or "Banker's rounding", etc). I couldn't find a thread on OTN that addresses this, either.
I tried to figure this out by trial and error, but am getting inconsistent results. Here are my test cases...
For both test cases:
Database field is NUMBER(20,4)
Form field is of type Number, length 30
Form field format mask, set programmatically, is FM999G999G999G999G999G999G999G999G999G999G999G990D90PR (that is, round to 2 decimal places)
The Form field displays the value of the database field directly
Test 1:
Database field value is 1.4445
Result: The field in the form displays the value as 1.44
Test 2:
Database field value is 1.445
Result: The field in the form displays the value as 1.45
This is totally inconsistent. If "half away from zero" or "half to odd" rounding were used, then the Test 1 value should be displayed as 1.45 (because the last 5 will round the previous 4 up to 5, and repeat). On the other hand, if "half to zero" or "half to even" rounding were used, the Test 2 value should be displayed as 1.44.
I understand that the stored values in the form are not rounded (as per Oracle's documentation), and that this will not necessarily result in calculation errors. However, it is necessary for documentation purposes that I determine what is the actual rule used for displaying rounded values.
I am using Forms 11gR2.
I imagine the rules Forms follows are the same as those the Oracle database follows as documented here:
ROUND is implemented using the following rules:
If n is 0, then ROUND always returns 0 regardless of integer.
If n is negative, then ROUND(n, integer) returns -ROUND(-n, integer).
If n is positive, then
ROUND(n, integer) = FLOOR(n * POWER(10, integer) + 0.5) * POWER(10,
-integer)
However I can't see why you think its behaviour is "totally inconsistent":
1.4445 is "nearer to" 1.44 than 1.45 so it certainly makes sense that ROUND(1.4445,2) returns 1.44. A result of 1.45 would simply be wrong.
1.445 is equidistant between 1.44 and 1.45, so either 1.44 or 1.45 could be correct, and apparently Oracle's rule goes for 1.45.
When I try to do the following command I get an error.
err = sqrt(mean((xi256-xc256).^2))
I am aware that the matrix sizes are different.
whos xi256 xc256` gives:
Name Size Bytes Class Attributes
xc256 27x1 216 double
xi256 513x1 4104 double
I am supposed to negate find the difference of these two matrices. In fact the command given at the top was in the course notes and the course has been running for several years! I have tried googling ways to resolve this error to perform this subtraction regardless but have found no solution. Maybe one of the matrices can be scaled to match the dimensions of the other? However, I have not been able to find any such functions that would let me do this.
I need to find the RMS error in a given set of data. xc256 was calculated through a numerical method, xi256 gives the true value.
Edit: I was able to use another set of results.
First check that xc256 is correctly computed and that you do not have a matrix transposition gone wrong or something like that. Computing the RMS between two vector of different sizes does not make sense, and padding or replicating will get you rid of the error, but is most probably not what you actually want.
There are just two situations that I can think of, I will list them here:
The line is wrong (not likely as it looks pretty normal, but make sure to check the book!)
The input of the line is wrong
Assuming it is in point 2, again there are two possibilities:
xi256 is of incorrect size (likelyhood of this depends on how you got it)
xc256 is of incorrect size
Assuming it is again point 2, there are yet again 2 likely possibilities:
xc256 should be a scalar
xc256 should be a vector with the same size as xi256
From here on there is insufficient information to continue, but check whether you accidentally made it 27 times as long, or 19 times too short somewhere. Just use some breakpoints throughout the code to see how the size develops.
I am writing a program which goes through FITS files with photometry and looks for stars given in a .dat file.
One of the steps is computing distances between two given stars using ephem.separation()
It works well. However, from time to time separation returns angles like 1389660529:33:00.8
import ephem
import math
star = ['21:45:15.00', '65:49:24.0']
first_coo = ['21:45:15.00', '65:49:24.0']
check = ephem.FixedBody()
check._ra = ephem.hours(star[0])
check._dec = ephem.degrees(star[1])
check.compute()
# star is a list with coordinates, strings in form %s:%s:%s
first = ephem.FixedBody()
first._ra = ephem.hours(first_coo[0])
first._dec = ephem.degrees(first_coo[1])
first.compute()
sep = math.degrees(float(ephem.separation(check,first)))
print sep
It occurs randomly. Have anybody encountered such behaviour?
I search for 18 stars in 212 files, which makes 3816 cycles. Might have something to do with it?
UPDATE: I have released a new PyEphem 3.7.5.2 that fixes this special case of comparing an angle to itself.
Your code sample has two interesting features:
first, it contains a slight bug that I thought at first might be behind the problem;
and, second, I was wrong that your code was the problem because your code
does indeed expose a flaw in the separation() function
when it is asked how far a position is from itself!
The bug in your own code is that calling compute() and asking about .ra and .dec
returns those coordinates in the coordinate system of the very moment that you are
calling compute() for — so your two compute() calls are returning coordinates
in two different coordinate systems that are very slightly different,
and so the resulting positions cannot be meaningfully compared with separation()
because separation() requires two coordinates that are in the same coordinate system.
To fix this problem, chose a single now moment to use as your equinox epoch:
now = ephem.now()
...
check.compute(epoch=now)
...
first.compute(epoch=now)
That will give you coordinates that can be meaningfully compared.
Now, on to the problem in PyEphem itself!
When presented with two copies of the same position are provided to separation() it goes ahead and tries to find a distance between them anyway, and winds up doing a calculation that amounts to:
acos(sin(angle) ** 2.0 + cos(angle) ** 2.0)
which should remind us of the standard Euclidean distance formula but with an acos() around it instead of a sqrt(). The problem is that while in theory the value inside of the parens should always be 1.0, the rounding inside of IEEE floating point math does not always produce squares that sum to exactly 1.0. Instead, it sometimes produces a value that is a bit high or a bit low.
When the result is a bit below 1.0, separation() will return a very slight separation for the coordinates, even though they are actually “the same coordinate.”
When the result exceeds 1.0 by a little bit, separation() will return not-a-number (nan) on my system — and, I will bet, returns that huge return value that you are seeing printed out on yours — because cos() cannot, by definition, return a number greater than 1.0, so there is no answer acos() can return when asked “what angle returns this value that is greater than one?”
I have created a bug report in GitHub and will fix this for the next version of PyEphem:
https://github.com/brandon-rhodes/pyephem/issues/31
Meanwhile, your code will have to avoid calling separation() for two positions that are actually the same position — could you use an if statement with two == comparisons between ra and dec to detect such cases and just use the value 0.0 for the separation instead?