Is there a way to calculate powers of doubles in GLSL?
The pow function gives me this error when trying to use doubles:
unable to find compatible overloaded function "pow(float64_t, float)"
According to this:
ARB_gpu_shader_fp64
the extension is missing any goniometric,pow,exp,log functions.
So you can not use 64bit pow nor encode it using log,exp approach. You still might be able to implement Power by squaring or your own log,exp functions for this. I think for that exact reason they added these:
genDType frexp(genDType x, out genIType exp);
genDType ldexp(genDType x, in genIType exp);
However I never used them I just found them while searching the doc for log/exp/pow functions. Also implementing pow in GLSL will be a hard work due to lack of breakpoints, stepping/tracing ... This might help a lot:
GLSL debug prints
But still I suggest to implement this on CPU side first and once working then port to GLSL.
pow requires both arguments to be the same. You can take a look at the documentation here. You could probably cast the variable before using pow:
pow(float(your_variable), the_power);
or
pow(your_variable, float64_t(the_power));
As I have never worked with float64_t before, I am not sure this will work. I am pretty sure the first one will, though.
Related
I'm browsing the swift tensorflow code, and stumbled upon instances of
var result = #tfop("Mul", a, b)
#tfop is well explained in the doc here, in the sense of 'what it does' but I'm also interested in what is actually is from a language standpoint, or as a function implementation.
What does #tfop represent, beside a handle to the computation graph? why the '#'? Where can I find tfop implementation if I want to? (I browsed the code, but no luck, although I can't guarantee that I didn't miss anything).
per Chris Lattner:
#tfop is a “well known” representation used for tensor operations.
It is an internal implementation detail of our stack that isn’t meant
to be user visible, and is likely to change over time.
In Swift, "#foo(bar: 42)” is the general syntax used for “macro like”
and “compiler magic” operations. For example C things like FILE
are spelled as #file in swift:
https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md
And the “#line 42” syntax used by the C preprocesser is represented
with arguments like this: #sourceLocation(file: "foo", line: 42)
In the case of #tfop specifically, this is represented in the Swift
AST as an ObjectLiteralExpr, which is the normal AST node for this
sort of thing:
https://github.com/google/swift/blob/tensorflow/include/swift/AST/Expr.h#L1097
We use special lowering magic to turn it into a SIL builtin
instruction in SILGen, which are prefixed with "__tfop_"
https://github.com/google/swift/blob/tensorflow/lib/SILGen/SILGenExpr.cpp#L3009
I’d like to move away from using builtin instructions for this, and
introduce a first-class sil instruction instead, that’s tracked by:
https://github.com/google/swift/issues/16
These instructions are specially recognized by the partitioning pass
of GPE:
https://github.com/google/swift/blob/tensorflow/lib/SILOptimizer/Mandatory/TFUtilities.cpp#L715
source here
According to the official GTK documentation, gdouble, gchar, etc are just typedef of the normal C types.
What's the point of it ? Why not simply use the traditional name, int, char; why take the trouble to typedef them all and as far as I can see, add nothing to them ?
The real reason is lost in time, and has since passed into legend. The types were introduced by the original authors of The GIMP in order to get consistent syntax highlighting in Emacs.
You are absolutely free to use C89, C99, and C11 types in your own code for the types that are simple typedefs. For some other, platform-specific types, like gsize or gint64, it's best to be consistent with what the API you are using expects.
I made a code that solve a Mixed Integer Linear Problem (MILP). In order to be as fast as possible, my code is using Cplex functions to solve the MILP, cplexmilp and cplexoptimset.
The only thing I set on cplexoptimset is:
options =cplexoptimset ('Display','off');
And than I run:
x = cplexmilp(var1,var2,var3,var4,var5,var6,var7,var8,var9,var10,var11,var12,options)
When I run the code, I receive the warning:
Warning: The function 'cplexlink1261' returned an mxArray with non-temporary scope
In cplexoptimset/secCplexOptions
In cplexoptimset /setCplexOptions
In cplexoptimset
In cplexoptimset
In myfunction
Nevertheless, after this warning, the code keep running, and it provides me results that seems reasonable.
I surfed the internet looking for an answer, and I found that the reason may be that my Matlab version, 2015b, is not supported for cplex.
Therefore, my question is: can I still trust the results I get from the function? My solution is a binary vector of thousands of variables, so I cannot actually check. Nevertheless, I noticed that other results derived from the code are similar to results I recorded before using the cplexmilpfunction.
I surfed the internet looking for an answer, and I found that the reason may be that my Matlab version, 2015b, is not supported for cplex.
Yes, that is correct; your version of MATLAB is not supported. See the Detailed system requirements for your version of CPLEX (presumably 12.6.1).
Therefore, my question is: can I still trust the results I get from the function?
It's not supported, so it's not tested. Use it at your own risk. If you want to be sure of your results, then use a supported version of MATLAB. I know that is not a very satisfying answer, but it is probably the best you'll get.
It looks like it may be possible to disable the warning (as shown here), but that doesn't change anything.
I need to rewrite the linkage function in matlab. Now, as I examine it, I realized there is a method called linkagemex inside of it. But I simply cannot step into this method to see its code. Can anyone help me out with this strange situastion?
function Z= linkage (Y, method, pdistArg, varargin)
Z=linkagemex(Y,method);
PS. I think I am pretty good at learning, but matlab is not so easy to learn. If you have good references to learn it well, feel free to let me know. Thanks very much for your time and attention.
As #m.s. mentions, you've found a call to a MEX function. MEX functions are implemented as C code that is compiled into a function callable by MATLAB.
As you've found, you can't step into this method (as it is compiled C code, not MATLAB code), and you don't have access to the C source code, as it's not supplied with MATLAB.
Normally, you would be at kind of a dead end here. Fortunately, that's not quite the case with linkagemex. You'll notice on line 240 of linkage.m that it actually does a test to see whether linkagemex is present. If it isn't, it instead calls a local subfunction linkageold.
I think you can assume that linkageold does at least roughly the same thing as linkagemex. You may like to test them out with a few suitable input arguments to see if they give the same results. If so, then you should be able to rewrite linkage using the code from linkageold rather than linkagemex.
I'm going to comment more generally, related to your PS. Over the last few days I've been answering a few of your questions - and you do seem like a fast learner. But it's not really that MATLAB is hard to learn - you should realize that what you're attempting (rewriting the clustering behaviour of phytree) is not an easy thing to do for even a very advanced user.
MathWorks write their stuff in a way that makes it (hopefully) easy to use - but not necessarily in a way that makes it easy for users to extend or modify. Sometimes they do things for performance reasons that make it impossible for you to modify, as you've found with linkagemex. In addition, phytree is implemented using an old style of OO programming that is no longer properly documented, so even if you have the code, it's difficult to work out what it even does, unless you happen to have been working with MATLAB for years and remember how the old style worked.
My advice would be that you might find it easier to just implement your own clustering method from scratch, rather than trying to build on top of phytree. There will be a lot of further headaches for you down the road you're on, and mostly what you'll learn is that phytree is implemented in an obscure old-fashioned way. If you take the opportunity to implement your own from scratch, you could instead be learning how to implement things using more modern OO methods, which would be more useful for you in the future.
Your call though, that's just my thoughts. Happy to continue trying to answer questions when I can, if you choose to continue with the phytree route.
You came across a MEX function, which "are dynamically linked subroutines that the MATLAB interpreter loads and executes". Since these subroutines are natively compiled, you cannot step into them. See also the MATLAB documentation about MEX functions.
I've tracked down this code: http://www.yorku.ca/marko/ComPhys/NoncomProduct/NoncomProduct.html . However, I suspect it's ancient. It dates, apparently, from 2005. It requires an army of definemore's to work, and requires this code:
Ut:=subs((A+B)^2=(A+B)&*(A+B),(A+B)^3=(A+B)&*(A+B)&*(A+B),(A+B)^4=(A+B)&*(A+B)&*(A+B)&*(A+B),Ut);
to get the non-commuting operators to evaluate properly. clearly, this gets worse as you go to higher order. I'm quite convinced there should be something that works to arbitrary order, though perhaps not for the maple versions this code was writen for.
So, the question: I'm currently using maple 13. Is there a better way to do this in maple 13, or in the latest versions of maple? This might be a good reason to invest in a newer version.
thanks..
Edit: Thank's for the response #acer; I wasn't all that explicit about this, but If there is a much better way to implement this algorithm in the newest versions of maple, please say so. I might actually invest in a new version.. thank's!
I haven't looked at those definemore definitions, but as far as the initial substitutions of powers go you could even in Maple 13 try something like either of these (instead of that hard-coded sequence of substitutions).
subsindets( Ut, `^`, z->`if`(type(op(2,z),posint) and op(1,z)=A+B,
foldr(`&*`,seq(op(1,z),i=1..op(2,z))),
z) );
subsindets( Ut, `^`, z->`if`(type(op(2,z),posint) and op(1,z)<>h,
foldr(`&*`,seq(op(1,z),i=1..op(2,z))),
z) );