Cannot find overload for '/', '*', Failure when running an app on anything but iPhone 5s simulator - ios-simulator

My game builds and runs successfully on the iPhone 5s simulator, but when I try on any other version I get the following two errors:
`Could not find an overload for '*' that accepts the supplied arguments`
`Could not find an overload for '/' that accepts the supplied arguments`
I'm writing my game entirely in Swift, and the deployment target is iOS 7.1
The die rolls in the picture are defined as
let lengthDiceroll = Double(arc4random()) / 0x100000000
let sideDiceroll = Int(arc4random_uniform(UInt32(4)))

Your problem is a difference between 32- and 64-bit architecture. Note that the target architecture you're compiling your target for is determined by the selected deviceā€”if you've got the iPhone 4S simulator selected as your target in Xcode, for example, you'll be building for 32 bit; if you've got the iPhone 5S simulator selected, you'll be building for 64-bit.
You haven't included enough code to help us figure out what exactly is going on (we'd need to know the types of the variable you're assigning to) but here's my theory. In your first error, sprite.speed is probably a CGFloat. CGFloat is 32-bit ("float") on 32-bit targets, 64-bit ("double") on 64-bit targets. So this, for example:
var x:CGFloat = Double(arc4random()) / 0x100000000
...will compile fine on a 64-bit target, because you're putting a double into a double. But when compiling for a 32-bit target, it'll give you the error that you're getting, because you're losing precision by trying to stuff a double into a float.
This will work on both:
var x:CGFloat = CGFloat(arc4random()) / 0x100000000
Your other errors are caused by the same issue (though again, I can't reproduce them accurately without knowing what type you've declared width and height as.) For example, this will fail to compile for a 32-bit architecture:
let lengthDiceroll = Double(arc4random()) / 0x100000000
let width:CGFloat = 5
var y:CGPoint = CGPointMake(width * lengthDiceroll, 0)
...because lengthDiceroll is a Double, so width * lengthDiceroll is a Double. CGPointMake takes CGFloat arguments, so you're trying to stuff a Double (64-bit) into a float (32-bit.)
This will compile on both architectures:
let lengthDiceroll = Double(arc4random()) / 0x100000000
let width:CGFloat = 5
var y:CGPoint = CGPointMake(width * CGFloat(lengthDiceroll), 0)
...or possibly better, declare lengthDiceroll as CGFloat in the first place. It won't be as accurate on 32-bit architectures, but that's sort of the point of CGFloat:
let lengthDiceroll = CGFloat(arc4random()) / 0x100000000
let width:CGFloat = 5
var y:CGPoint = CGPointMake(width * lengthDiceroll, 0)

I've experienced similar errors where debug builds work and release builds fail for example. My advice would be make all your types explicit:
let lengthDiceroll = Double(arc4random()) / Double(0x100000000)
I've also had similar problems with CGFloat and CGPoint, make sure you explicitly use CGFloat, e.g. CGFloat(2.0)

Related

Can a parameter be used to set the unit attribute for a component?

So far, using Wolfram System Modeler 4.3 and 5.1 the following minimal example would compile without errors:
model UnitErrorModel
MyComponent c( hasUnit = "myUnit" );
block MyComponent
parameter String hasUnit = "1";
output Real y( unit = hasUnit );
equation
y = 10;
end MyComponent;
end UnitErrorModel;
But with the new release of WSM 12.0 (the jump in version is due to an alignment with the current release of Wolfram's flagship Mathematica) I am getting an error message:
Internal error: Codegen.getValueString: Non-constant expression:c.hasUnit
(Note: The error is given by WSMLink'WSMSimulate in Mathematica 12.0 which is running System Modeler 12.0 internally; here asking for the "InternalValues" property of the above model since I have not installed WSM 12.0 right now).
Trying to simulate the above model in OpenModelica [OMEdit v. 1.13.2 (64-bit)] reveals:
SimCodeUtil.mo: 8492:9-8492:218]: Internal error Unexpected expression (should have been handled earlier, probably in the front-end. Unit/displayUnit expression is not a string literal: c.hasUnit
So it seems that to set the unit attribute I cannot make use of a variable that has parameter variability? Why is this - after all shouldn't it suffice that the compiler can hard-wire the unit when compiling for runtime (after all the given model will run without any error in WSM 4.3 and 5.1)?
EDIT: From the answer to an older question of mine I had believed that at least final parameters might be used to set the unit-attribute. Making the modification final (e.g. c( final hasUnit = "myUnit" ) does not resolve the issue.
I have been given feedback on Wolfram Community by someone from Wolfram MathCore regarding this issue:
You are correct in that it's not in violation with the specification,
although making it a constant makes more sense since you would
invalidate all your static unit checking if you are allowed to change
the unit after building the simulation. We filed an issue on the
specification regarding this (Modelica Specification Issue # 2362).
So, MatheCore is a bit ahead of the game in proposing a Modelica specification change that they have already implemented. ;-)
Note: That in Wolfram System Modeler (12.0) using the annotation Evaluate = true will not cure the problem (cf. the comment above by #matth).
As a workaround variables used to set the unit attribute should have constant variability, but can nevertheless by included in user dialogs to be interactively changed using annotation(Dialog(group = "GroupName")).

OpenCL double precision not working

So I have a project that I created on Mac Pro using double data type and it works perfect. Now I moved my project to MacBook Air and it started giving me
Exception
ERROR: clBuildProgram(-11)
error. Now the reason for this is that my MacBook Air does not support the double precision type with OpenCL. But on the contrary, I found this: OpenCL kernel error on Mac OSx. I applied the method in the answer like this:
cl_device_fp_config cfg;
clGetDeviceInfo(devicesIds[0], CL_DEVICE_DOUBLE_FP_CONFIG, sizeof(cfg), &cfg, NULL); // 0 is for the device number I guess?
printf("Double FP config = %llu\n", cfg);
And he explained that if the result is 0, then it means that double precision is not supported. But I get this result:
Double FP config = 63
I also tried this method:
if (!cfg) {
printf("Double precision not supported \n\n");
} else {
printf("Following double precision features supported:\n");
if(cfg & CL_FP_INF_NAN)
printf(" INF and NaN values\n");
if(cfg & CL_FP_DENORM)
printf(" Denormalized numbers\n");
if(cfg & CL_FP_ROUND_TO_NEAREST)
printf(" Round To Nearest Even mode\n");
if(cfg & CL_FP_ROUND_TO_INF)
printf(" Round To Infinity mode\n");
if(cfg & CL_FP_ROUND_TO_ZERO)
printf(" Round To Zero mode\n");
if(cfg & CL_FP_FMA)
printf(" Floating-point multiply-and-add operation\n\n");
}
And I got the following results:
Double FP config = 63
Following double precision features supported:
INF and NaN values
Denormalized numbers
Round To Nearest Even mode
Round To Infinity mode
Round To Zero mode
Floating-point multiply-and-add operation
What is going on here? Does my system support double precision with OpenCL or not? If yes, how do I enable and use it? If not, what are my alternatives?
Now I am very confused. First of all, I don't know if my MacBook Air supports double precision or not? Apparently it doesn't. But with the output, it seems like it does.
If it doesn't support double precision, then what should I do? Should I change everything in my project to float values? OR if it does, then how do I enable it? Because I followed a lot of tutorials and examples and none of them work. e.g. https://streamcomputing.eu/blog/2013-10-17/writing-opencl-code-single-double-precision/ but none of them seem to work.
EDIT:
Unfortunately double support is "optional" in OpenCL, some devices support it and some don't...
If a device supports double then the device extensions (CL_DEVICE_EXTENSIONS) will contain cl_khr_fp64 or cl_khr_fp64.
There is some example kernel code here to use floats when doubles aren't available.

Bug in IMFSinkWriter?

I implemented an encoder in 2 ways.
1) based on the SDK Transcoder example, which uses topology and transcoding profile
2) based on IMFSourceReader and IMFSinkWriter, where the Sinkwriter delivers the samples to the Sourcewriter for transcoding
I tested both implementations on Windows 8.1 with Nvidia (Quadro K2200) and Intel GPU (P4600/P4700)
But bizarrly only the topology implementation uses GPU (on both).
In 2) I both I set "MF_READWRITE_ENABLE_HARDWARE_TRANSFORMS", which has not to be set I guess, because 1) works with GPU with and without this flag set for the container type.
Is there a trick to enable GPU with IMFSinkWriter or is this a bug in the media foundation?
I had initially ran into the same issue. You don't mention how you configured the output type of the source reader (and the input type of the sink), but I found that if you allow the system to handle it (by selecting the output type of the reader to be RGB32), the performance will be horrible and all CPU bound. (error checking omitted for brevity)
hr = videoMediaType->SetGUID(MF_MT_MAJOR_TYPE, MFMediaType_Video);
hr = videoMediaType->SetGUID(MF_MT_SUBTYPE, MFVideoFormat_RGB32);
hr = reader->SetCurrentMediaType((DWORD)MF_SOURCE_READER_FIRST_VIDEO_STREAM, nullptr, videoMediaType);
reader->SetStreamSelection((DWORD)MF_SOURCE_READER_FIRST_VIDEO_STREAM, true);
And the documentation agrees, indicating that this configuration is useful for getting a single snapshot from the video. As a result, if you configure the reader to deliver the native media type, performance is excellent, but you now have to transform the format yourself.
reader->GetNativeMediaType((DWORD)MF_SOURCE_READER_FIRST_VIDEO_STREAM, videoMode->GetIndex(), videoMediaType);
From here, if you are dealing with simple color conversion (like YUY2 or YUV from a webcam) then there are a few options. I originally tried writing my own converter, and pushing that off to the GPU using HLSL with DirectCompute. This works very well, but in your case, the format isn't as trivial.
Ultimately, creating and configuring an instance of the color converter (as an IMFTransform) works perfectly.
Microsoft::WRL::ComPtr<IMFMediaType> mediaTransform;
hr = ::CoCreateInstance(CLSID_CColorConvertDMO, nullptr, CLSCTX_INPROC_SERVER, __uuidof(IMFTransform), reinterpret_cast<void**>(mediaTransform.GetAddressOf());
// set the input type of the transform to the NATIVE output type of the reader
hr = mediaTransform->SetInputType(0u, videoMediaType.Get(), 0u);
Create and configure a separate sample and buffer.
IMFSample* transformSample;
hr = ::MFCreateSample(&transformSample);
hr = ::MFCreateMemoryBuffer(RGB_MFT_OUTPUT_BUFFER_SIZE, &_transformBuffer);
hr = transformSample->AddBuffer(transformBuffer);
MFT_OUTPUT_DATA_BUFFER* transformDataBuffer;
transformDataBuffer = new MFT_OUTPUT_DATA_BUFFER();
transformDataBuffer->pSample = _transformSample;
transformDataBuffer->dwStreamID = 0u;
transformDataBuffer->dwStatus = 0u;
transformDataBuffer->pEvents = nullptr;
When receiving samples from the source, hand them off to the transform to be converted.
hr = mediaTransform->ProcessInput(0u, sample, 0u));
hr = mediaTransform->ProcessOutput(0u, 1u, transformDataBuffer, &outStatus));
hr = transformDataBuffer->pSample->GetBufferByIndex(0, &mediaBuffer);
Then of course, finally hand off the transformed sample to the sink just as you do today. I am confident that this will work, and you will be a very happy person. For me, I went from 20% CPU utilization (originally implementation) down to 2% (I am concurrently displaying the video). Good luck. I hope you enjoy your project.

OpenCL compiler white-space problems

I'm trying to get started with OpenCL but came across weird behavior of the OpenCL compiler with respect to white-space and can't seem to find any documentation about that.
C-style single-line comments (// foo) immediately cause a meaningless build error: At end of source: error: expected a "}". Multi-line comments (/* bar */) seem to work fine.
Line breaks seem to get stripped without adding whitespace which can cause errors. This example will not compile because of that:
__kernel
void TestKernel() {}
line 1: error: identifier "__kernelvoid" is undefined
This may totally depend on my machine and/or configuration but can somebody confirm that these things should not be this way?
I am using OpenCL via Cloo from .net/C#. The driver is from AMD OpenCL 2.0 AMD-APP (1642.5)
I think I figured it out. I was doing this:
var program = new ComputeProgram(context, File.ReadAllLines(filename));
File.ReadAllLines() returns an array of strings without the line-break characters which is the root of the errors I was getting.
Using File.ReadAllTest() instead fixed all the problems:
var program = new ComputeProgram(context, File.ReadAllText(filename));
But in my opinion some of the blame goes to either Cloo or the OpenCL API for accepting a string array but just concatenating it together..

ActionScript 3.0 integer overflow?

I have an old AIR file that works fine. I tried to recompile it but the resulting airfile is buggy.
After digging in the code, i found that at some place strings are parsed to ints, and that the resulting int does not correspond to the string.
So i made a simple Actionscript file and executed the code:
var test:int = parseInt("3710835714");
and the variable will have the value
-584131582
So this looks like an overflow. But i'm surprised that the air file i have (which i didn't compile myself) runs just fine. So I wonder - does the internal representation of int somehow depend on what version of the Flex or AIR sdk libraries one is using for compiling?
//edit: it seems it boils down to this test:
var obj:Object = new Object();
obj.val="3710835714";
var test1:Boolean = (obj.val==-584131582);
var test2:Boolean = (int(obj.val)==-584131582);
this evaluates for me to
test1=false;
test2=true;
however - the this old AIR file seems to evaluate both cases to true. How can that be?
It is happening due to Give number exceeds ActionsScript Int limit
The int data type is stored internally as a 32-bit integer and comprises the set of integers from -2,147,483,648 (-231) to 2,147,483,647 (231 - 1),
and number 3,710,835,714 exceeds it by 1563352067
but your parse result shows compiler is considering it as Uint, whose Max limit is 4,294,967,295 i.e
-584131581 = 3,710,835,714 - 4,294,967,295
You should use Uint or Number for big whole-numbers/integers
this blog may helps you
ActionScript 3 Number data type problem with long integer values
Hopes that works

Resources