I would like to know the kernel that this op is using. I've been looking through the TF source code. The closest I got to was image_ops.cc. Can someone point me to the right place to look?
The python hook is inside:
tensorflow/python/ops/image_ops.py
The compiler system applies a translation to the operation names;
resize_bicubic -> ResizBicubicOP
Finally, you can find the Kernel inside:
tensorflow/core/kernels/resize_bicubic_op.cc#L88
Related
I am trying to install the software Sibaco, but I get an error relative to CGAL class Alpha_shape_cell_base_3.
/usr/local/include/CGAL/Regular_triangulation_3.h:1230:12: error: ‘class CGAL::Alpha_shape_cell_base_3<CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<CGAL::Triangulation_data_structure_3<CGAL::Alpha_shape_vertex_base_3<CGAL::Epick, CGAL::Regular_triangulation_vertex_base_3<CGAL::Epick> >, CGAL::Alpha_shape_cell_base_3<CGAL::Epick> > > >, CGAL::Boolean_tag<false>, CGAL::Boolean_tag<false> >’ has no member named ‘hide_point’
A similar error is reported for the members ‘hidden_points_begin’ and ‘hidden_points_end’.
I am using CGAL-4.11.3, since for later releases of CGAL I get many more errors when I try to install the software.
Any help to address this problem would be really appreciated!
The cell base needs to match the triangulation. Since you're using a regular triangulation, the cell base must be a model of the concept RegularTriangulationCellBase_3, so CGAL::Regular_triangulation_cell_base_3 for example.
As pointed in the comment above, the example ex_weighted_alpha_shapes_3.cpp shows a correct setting of vertex and cell for 3D weighted alpha shapes.
If you need to use some more recent CGAL features and CGAL 4.11 is too old, feel free to post the errors you get and we can maybe help you upgrade the code from that library.
I'm new to halide. Now I have a pointer which points to data on GPU. I want to get a halide buffer from this pointer without copying data. I have searched a lot and found this /halidebuffer-on-gpu . It says using Buffer::device_wrap_native will be helpful. And I have read the docs of itBuffer::device_wrap_nativeBut I'm little confused about what value should I pass to device_interface? docs of device_interface don't help me much.
For device_interface you want to pass either halide_cuda_device_interface(), or halide_opencl_device_interface(), or similar. These methods are all defined in HalideRuntime*.h. Here's the full list:
HalideRuntimeCuda.h: halide_cuda_device_interface();
HalideRuntimeD3D12Compute.h: halide_d3d12compute_device_interface();
HalideRuntimeHexagonDma.h: halide_hexagon_dma_device_interface();
HalideRuntimeHexagonHost.h: halide_hexagon_device_interface();
HalideRuntimeMetal.h: halide_metal_device_interface();
HalideRuntimeOpenCL.h: halide_opencl_device_interface();
HalideRuntimeOpenGL.h: halide_opengl_device_interface();
HalideRuntimeOpenGLCompute.h: halide_openglcompute_device_interface();
I am trying to use the G_LLL_XD function on the NTL library. Whenever I use the function in this format:
G_LLL_XD(B, delta); ,
the program works.
Though, when I want to change the default deep or prune variables and write the function in one of these ways:
G_LLL_XD(B, delta, deep, check, verbose);
G_LLL_XD(B, delta, prune, check, verbose);
during runtime, I get this error:
R610
- abort() has been called
and in the command prompt it says:
"sorry...deep insertions not implemented"
I find this very weird since whenever I use prune as a variable, I get this crash error, which I shouldn't because the function shouldn't be looking for deep insertion but prune, and when I do use deep as a variable and have implemented deep, I still get an error.
Can anybody help me understand what the problem is or how I can fix this? Thank you very much.
I dont found a argument prune for LLL function in NTL. But there is one for BKZ. Since the are both accept positive intergers, its only a naming confusion.
From the documentation:
NOTE: use of "deep" is obsolete, and has been "deprecated". It is
recommended to use BKZ_FP to achieve higher-quality reductions.
Moreover, the Givens versions do not support "deep", and setting
deep != 0 will raise an error in this case.
So you can not use G_LLL_XD with deep != 0 but LLL_XD should work (but it is deprecated).
But as mentioned, you should consider using BKZ_XD instead of LLL_XD.
A BKZ basis of a lattice is also LLL reduced, so there should be no problem. BKZ is slower than LLL but you can choose a small Blocksize, maybe 10 or 20 but also 2 or 4 will work, to speed the reduction up.
We can create a real-time monitor for a variable like this:
CreatePalette#Panel#Row[{"x = ", Dynamic[x]}]
(This is more interesting and useful if x happens to be something like $Assumptions. It's so easy to set a value and then forget about it.)
Unfortunately this stops working if the kernel is re-launched (Quit[], then evaluate something). The palette won't show changes in the value of x any more.
Is there a way to do this so it keeps working even across kernel sessions? I find myself restarting the kernel quite often. (If the resulting palette causes the kernel to be automatically started after Quit that's fine.)
Update: As mentioned in the comments, it turns out that the palette ceases working only if we quit by evaluating Quit[]. When using Evaluation -> Quit Kernel -> Local, it will keep working.
Link to same question on MathGroup.
I can only guess, because on my Ubuntu here the situations seems buggy. The trick with the Quit from the menu like Leonid suggested did not work here. Another one is: on a fresh Mathematica session with only one notebook open:
Dynamic[x]
x = 1
Dynamic[x]
x = 2
gives as expected
2
1
2
2
Typing in the next line Quit, evaluating and typing then x=3 updates only the first of the Dynamic[x].
Nevertheless, have you checked the command
Internal`GetTrackedSymbols[]
This gives not only the tracked symbols but additionally some kind of ID where the dynamic content belongs. If you can find out, what exactly these numbers are and investigate in the other functions you find in the Internal context, you may be able to add your palette Dynamic-content manually after restarting the kernel.
I thought I had something like that with
Internal`SetValueTrackExtra
but I'm currently not able to reproduce the behavior.
#halirutan's answer jarred my memory...
Have you ever come across: Experimental/ref/ValueFunction? (documentation address)
Although the documentation contains no examples, the 'more information' section provides the following tidbit:
The assignment ValueFunction[symb] = f specifies that whenever
symb gets a new value val, the expression f[symb,val] should be
evaluated.
i'm just about to learn inline assembly.the GCC inline assembly cookbook http://www.ethernut.de/en/documents/arm-inline-asm.html
says:
A strict rule is: Never ever write to an input operand.
can someone tell me whether - and if so why - this rule is true?
let's say i get the value of an input operand through some register. Am I not allowed to reuse this register within the same assembly block if i don't inted to declare it also as output operand?
example:
asm volatile("add %[value], %[value], %[value] \n\t"
"mov %[result], %[value] \n\t"
: [result]"=r" (y)
: [value]"r" (x)
: //no clober
);
I know the example doesn't make much sense - but is it invalid?
I ask because i'm writing some assembly function that takes many input operands, each taking a general purpose register. since there are only 12 GPR's available on my architecture, with each input operand i get less "free" registers to work with. so do I really have to declare the input registers also as output in order to use them to "work" with them inside the function (even though i don't need theyr value outside the inline-assembly body? If so - can someone explain why?
hope the question is clear
thanks!
The compiler doesn't know x is clobbered (and I think there is no way to clobber an input register in a valid way). So it might reuse the register holding x later in the code assuming it still holds an unaltered value which isn't true since you changed it.