How to draw the slant operator for fractions using flex boxes? - webkit

I want to draw the slant operator for fractions. i e. bevelled operator on mfrac. How can draw that using flex boxes. For example: a/b instead of normal fraction. I want idea for implementation of the former one. that is for the type a/b using c++.

Related

How do you map values in LabVIEW? Is there a best way or convention?

I have an angle in degrees, and need to map it to a voltage.
i.e. left: -360 degrees = 0V, straight: 0 degrees = 5V, right: 360 degrees = 10V.
How do you map values in LabVIEW?
I found scaling under the numeric pallet but they seem to be very specific (e.g. for a thermistor) with no generic block.
If the mapping you want is described by a mathematical formula, just implement that calculation using LabVIEW functions. In your case, assuming it's a linear relationship, the formula is voltage = (angle + 360) / 72 .
You could code this in LabVIEW with an Add function followed by a Divide function, or if you think it's clearer written out as a formula then you could use a Formula Node.
If you need to use this calculation in more than one place in your application, make it into a subVI.
Looks like you're trying to read a analog gauge value! Actually it's very simple.
Build a lookup Table
Perform Interpolation followed by thresholding.
Refer the VI Snippet (Just paste this image into your block diagram).
Sample Output:

Explaining the different types in Metal and SIMD

When working with Metal, I find there's a bewildering number of types and it's not always clear to me which type I should be using in which context.
In Apple's Metal Shading Language Specification, there's a pretty clear table of which types are supported within a Metal shader file. However, there's plenty of sample code available that seems to use additional types that are part of SIMD. On the macOS (Objective-C) side of things, the Metal types are not available but the SIMD ones are and I'm not sure which ones I'm supposed to be used.
For example:
In the Metal Spec, there's float2 that is described as a "vector" data type representing two floating components.
On the app side, the following all seem to be used or represented in some capacity:
float2, which is typedef ::simd_float2 float2 in vector_types.h
Noted: "In C or Objective-C, this type is available as simd_float2."
vector_float2, which is typedef simd_float2 vector_float2
Noted: "This type is deprecated; you should use simd_float2 or simd::float2 instead"
simd_float2, which is typedef __attribute__((__ext_vector_type__(2))) float simd_float2
::simd_float2 and simd::float2 ?
A similar situation exists for matrix types:
matrix_float4x4, simd_float4x4, ::simd_float4x4 and float4x4,
Could someone please shed some light on why there are so many typedefs with seemingly overlapping functionality? If you were writing a new application today (2018) in Objective-C / Objective-C++, which type should you use to represent two floating values (x/y) and which type for matrix transforms that can be shared between app code and Metal?
The types with vector_ and matrix_ prefixes have been deprecated in favor of those with the simd_ prefix, so the general guidance (using float4 as an example) would be:
In C code, use the simd_float4 type. (You have to include the prefix unless you provide your own typedef, since C doesn't have namespaces.)
Same for Objective-C.
In C++ code, use the simd::float4 type, which you can shorten to float4 by using namespace simd;.
Same for Objective-C++.
In Metal code, use the float4 type, since float4 is a fundamental type in the Metal Shading Language [1].
In Swift code, use the float4 type, since the simd_ types are typealiased to shorter names.
Update: In Swift 5, float4 and related types have been deprecated in favor of SIMD4<Float> and related types.
These types are all fundamentally equivalent, and all have the same size and alignment characteristics so you can use them across languages. That is, in fact, one of the design goals of the simd framework.
I'll leave a discussion of packed types to another day, since you didn't ask.
[1] Metal is an unusual case since it defines float4 in the global namespace, then imports it into the metal namespace, which is also exported as the simd namespace. It additionally aliases float4 as vector_float4. So, you can use any of the above names for this vector type (except simd_float4). Prefer float4.
which type should you use to represent two floating values (x/y)
If you can avoid it, don't use a single SIMD vector to represent a single geometry x,y vector if you're using CPU SIMD.
CPU SIMD works best when you have many of the same thing in each SIMD vector, because they're actually stores in 16-byte or 32-byte vector registers where "vertical" operations between two vectors are cheap (packed add or multiply), but "horizontal" operations can mostly only be done with a shuffle + a vertical operation.
For example a vector of 4 x values and another vector of 4 y values lets you do 4 dot-products or 4 cross-products in parallel with no shuffling, so the overall throughput is significantly more dot-products per clock cycle than if you had a vector of [x1, y1, x2, y2].
See https://stackoverflow.com/tags/sse/info, and especially these slides: SIMD at Insomniac Games (GDC 2015) for more about planning your data layout and program design for doing many similar operations in parallel instead of trying to accelerate single operations.
The one exception to this rule is if you're only adding / subtracting to translate coordinates, because that's still purely a vertical operation even with an array-of-structs. And thus fine for CPU short-vector SIMD based on 16-byte vectors. (e.g. the 2nd element in one vector only interacts with the 2nd element in another vector, so no shuffling is needed.)
GPU SIMD is different, and I think has no problem with interleaved data. I'm not a GPU expert.
(I don't use Objective C or Metal, so I can't help you with the details of their type names, just what the underlying CPU hardware is good at. That's basically the same for x86 SSE/AVX, ARM NEON / AArch64 SIMD, or PowerPC Altivec. Horizontal operations are slower.)

What is the main difference between float4 and half4 in fragment shader function?

I try to set render pipeline and MTKView color attachment pixel format of MTLPixelFormatRGBA16Float.
However, it seem same with MTLPixelFormatBGRA8Unorm_sRGB.
I just want to make the render color range higher(HDR).
Is the return type of the fragment function important?
What should I set to realize a high dynamic range in metal ?
Based on this Metal Shading Language Specification
float:
A 32-bit floating-point. The float data type must conform to the IEEE
754 single precision storage format.
Full float precision is generally used for world space positions, texture coordinates, or scalar computations involving complex functions such as trigonometry or power/exponentiation.
half:
A 16-bit floating-point. The half data type must conform to the IEEE
754 binary16 storage format.
Half precision is useful for short vectors, directions, object space positions, high dynamic range colors.

gmock: Testing two float vectors

I am trying to write a test for a vector.
For STL containers, I tried:
EXPECT_THAT(float_vec1, ElementsAreArray(float_vec2));
However I need to insert a margin.
Is there an ElementsAreArray equivalent of FloatNear(a_float, max_abs_error)?
Yes, I've used the Pointwise container matcher, which you can give a matcher and an expected container (any STL container and is compatible with non-dynamically allocated c-style arrays).
EXPECT_THAT(float_vec1, Pointwise(matcher, float_vec2))
For the matcher You can use FloatEq() which uses ULP-based float comparisons.
EXPECT_THAT(float_vec1, Pointwise(FloatEq(), float_vec2))
However, I've found it is easier to use FloatNear(float max_abs_error) just to define my own floating point error like you want.
float ferr = 1e-5;
EXPECT_THAT(float_vec1,
Pointwise(FloatNear(ferr), float_vec2));

Texture format for cellular automata in OpenGL ES 2.0

I need some quick advice.
I would like to simulate a cellular automata (from A Simple, Efficient Method
for Realistic Animation of Clouds) on the GPU. However, I am limited to OpenGL ES 2.0 shaders (in WebGL) which does not support any bitwise operations.
Since every cell in this cellular automata represents a boolean value, storing 1 bit per cell would have been the ideal. So what is the most efficient way of representing this data in OpenGL's texture formats? Are there any tricks or should I just stick with a straight-forward RGBA texture?
EDIT: Here's my thoughts so far...
At the moment I'm thinking of going with either plain GL_RGBA8, GL_RGBA4 or GL_RGB5_A1:
Possibly I could pick GL_RGBA8, and try to extract the original bits using floating point ops. E.g. x*255.0 gives an approximate integer value. However, extracting the individual bits is a bit of a pain (i.e. dividing by 2 and rounding a couple times). Also I'm wary of precision problems.
If I pick GL_RGBA4, I could store 1.0 or 0.0 per component, but then I could probably also try the same trick as before with GL_RGBA8. In this case, it's only x*15.0. Not sure if it would be faster or not seeing as there should be fewer ops to extract the bits but less information per texture read.
Using GL_RGB5_A1 I could try and see if I can pack my cells together with some additional information like a color per voxel where the alpha channel stores the 1 bit cell state.
Create a second texture and use it as a lookup table. In each 256x256 block of the texture you can represent one boolean operation where the inputs are represented by the row/column and the output is the texture value. Actually in each RGBA texture you can represent four boolean operations per 256x256 region. Beware texture compression and MIP maps, though!