Well, you are not doing anything overtly wrong. I would guess the answer is a subtle one, and reflects an error on how the test was written. It should have employed a tolerance, since there are surely different ways to write exactly the same thing. For example ... you MIGHT have done several things, all of which are technically correct. (And given time, I could probably find at least a couple other solutions, all of which would be technically correct, perfectly valid ansers, just not the one the tester was thinking of.)
format long g
a1 = asin(sin(deg2rad(45)))
a2 = asin(sind(45))
a3 = deg2rad(asind(sind(45)))
a1 == a2
a1 == a3
As you can see, what you did yields the same result as the others, but due to floating point trash, they give subtly different results down in the least significant bits.
num2str(a1,55)
num2str(a2,55)
num2str(a3,55)
And as you can see, a1 differs from a2 and a3, by an infinitessimal amount. But since a double is only meant to store roughly 16 decimal digits, they are all pretty much "the same".
In terms of a hex representation, we can see they differ by essentially a bit flip, down in the least significant bits of those numbers.
num2hex(a1)
num2hex(a2)
It seems likely that the test tested to see if you generated exactly the same result as what they wanted to see. But that will not always happen, as you can see. Each of the expressions I wrote are all technically correct. At least a2 and a3 agree down to the least bit.
So your solution, if what you want is to offfer a valid solution to this challenge, is to see if one of the alternate solutions I have offered make it happy. Kind of sad I know, because the problem lies not in you, but in the person who posed the challenge in the first place. My guess is they were looking for the a2 solution, but you never know.
