How can we simplify (a&b)*(c&b)?
where '&' is bitwise and also * represents product.
Or find b in [L,R] such that (a&b)*(c&b) is maximum?
Assume unsigned. Look at a & mask a bit will be set if it is set in both a and the mask. A zero in the mask will never make the result larger but could make it smaller, if the corresponding bit in a was set.
so:
(a&b)*(c&b) will never be larger than a*c which is achieved when all bits in b is set.
If b should be as small as possible you could clear all the bits which will not decrement either a or c, i.e. a bit set in either one of them:
b = a | c
Related
Is there a way, using pure CSS to fetch the numeric value without pulling back the unit too?
e.g. say I have a CSS variable defined as :root {--maxWidth: 100px;}. If I want to get the ratio of that value to my viewport's width I can't as calc(100vw / var(--maxWidth)) would fail as you can't divide a number with units by another number with units; even where they're the same unit.
I can get around this example case by omitting the units from my variable (e.g. :root {--maxWidth: 100;}), but I'm wondering how to do this in cases where you can't.
More specifically, I want to get the ratio / conversion value for 1vw to 1px so that I can write code which uses px values, then use transform: scale(var(--horizontalRatio), var(--verticalRatio)) to resize everything to fit perfectly in the viewport; but to do that I need a way to convert between pixels and viewport units.
There is a way to work around this; everywhere I set a size in pixels I could instead set the size to calc(100vw * X/var(--maxWidthInPx)) where X is the size in pixels of what I'm setting and --maxWdithInPx is a numeric only value giving the max width of the static px size. However, that means putting these little equations everywhere, rather than just having 1 place where things get scaled.
I've found several javascript solutions for this; but I need something that's CSS only.
In the near (or a far) future this will be possible using only CSS. The specification has changed to allow the division and multiplication of different types.
You can read the following:
At a * sub-expression, multiply the types of the left and right arguments. The sub-expression’s type is the returned result.
At a / sub-expression, let left type be the result of finding the types of its left argument, and right type be the result of finding the types of its right argument and then inverting it.
The sub-expression’s type is the result of multiplying the left type and right type.
As you can see, there are new rules that defines how types are multiplied and how the result is calculated so I am pretty sure what you want is possible but there is no implementation for this to test.
The current specification is more restrictive:
At *, check that at least one side is <number>. If both sides are <integer>, resolve to <integer>. Otherwise, resolve to the type of the other side.
At /, check that the right side is <number>. If the left side is <integer>, resolve to <number>. Otherwise, resolve to the type of the left side.
If an operator does not pass the above checks, the expression is invalid
I am currently working on a program where I try to experimentally come up with an ordering of elements, then compare to a given ordering. For instance:
Experimental: A, C, B, F, E, D
Given: A, B, C, D, E, F
At the end I am trying to find some metric by which I can measure how close my experimental ordering is to the given ordering. I know that all of the same elements will be present in both. Is the number of elements in the correct position divided by the total number of elements in the list the best I can do? Thanks!
I think this largely depends on how you define similarity between two sequences. I will give you some ideas and then define the corresponding distance function.
Just the correct positions matter: In this case you just count the number of correctly positioned elements (as you proposed in your question)
The difference to the desired position is important: You could sum up the differences of the position in the experimental to the position in the given sequence for each character
The ranking between elements is important: Here you could count how many pairs of elements are in correct order (similar to Kendall rank correlation). Beside this one there are a couple more rank correlation measures.
The cost to transform one list into the other: In this case you would have to calculate the minimum number of swaps in order to get from one list to the other. If you also care about how far elements are from their desired position you could only allow for swaps of adjacent elements. Computing this, is a little more complicated, but this geeksforgeeks might help.
If you want to have a distance between 0 and 1 you would have to normalize the results. I am sure there are more, these are just the ones I could think of from the top of my head.
I am trying to include a simple density calculation in access 2016, but the form returns a value of 0 if the input dimensions (mass or sphere diameter) are < 0.5. The field works fine for larger dimensions, so I assume that the smaller values are getting rounded to 0 somewhere along the way, but I can't figure out where.
For the inputs in my table, I have Field Names "green mass", "green pole", and "green equator" where the data type for each is set to "number," the Field Size is set to "single" (vs. double or decimal), and the Decimal Places is set to 4 digits
The resulting density is displayed in the Field "apparent green density" where the data type is set to "calculated," the Result Type is set to "single" and the Decimal Places is set to 4 digits.
After looking at various access forums and websites, I'm pretty sure I want to use single or double as my field size, but I've also tried decimal and byte and integer I keep getting 0.
Can anyone explain why this isn't working?
The equation is below. It's a bit complicated because it's a 3-part If statement (if dimensions for a sphere are given, caclulate density of a sphere, if dimensions of a disc are give, calculate density of a disc, if dimensions of a cube...) All three cases work for large dimensions (>0.5), but all 3 result in 0 for dimensions <0.5.
IIf([GreenPole],[GreenMass]/(3.14159265359/6*2.54^3*(([GreenPole]+[GreenEquator])/2)^3),IIf([GreenDia],([GreenMass]/(3.14159265359*([GreenDia]/2)^2*[GreenHeight]*2.54^3)),IIf([GreenLength],[GreenMass]/([GreenLength]*[GreenWidth]*[GreenThickness]*2.54^3),0)))
The first part of the equation for density of a sphere, is:
`IIf([GreenPole],[GreenMass]/(3.14159265359/6*2.54^3*(([GreenPole]+[GreenEquator])/2)^3),0)
Oliver Jacot-Descombes got me started in the right direction. I don't have much experience at all with coding, but I think what happened is that field identified in my IIf statement is somehow transformed into a boolean or yes/ no field and anything less than 0.5 is rounded to a no and the result of the truepart is then 0.
I modified the code to:
IIf([GreenPole]>0,[GreenMass]/(3.14159265359/6*2.54^3*(([GreenPole]+[GreenEquator])/2)^3),0)
And everything works now. (I also modified the second and third IIf statments to IIf([GreenLength]>0 and IIF([GreenDia]>0..)
If I want to see in fast what is the result of a code that does shifting (left/right) I usually write down the binary representation and do the shifting.
But for e.g. shifts of 4 it is actually faster to do it write the hex representation and move the character/digit 1 place to the left/right?
Are there any other tricks for this?
Essentially, shifting 4 bits is removing 1 hex because each hex digit is 4 bits in binary. So shifting 8 bits would be like removing 2 hex, and so on.
If you wanted, you could also do the same type of shift with octal, although instead of 4 bits we would be using 3.
Alternately, if you wish to see the translation in decimal rather than octal or hex, you can view shifting as a way to represent division and multiplication.
With shifting left, you can use x1 << x2 as a form of multiplication by 2^x2.
With shifting right, you can use x1 >> x2 as a form of division by 2^x2. Keep note, this will work for positive numbers, not negative.
I've implemented some functions according to the HSL->RGB and HSV->RGB algorithms.
They mostly work fine, but I'm not sure what is the right thing to do then a color component overflows as a result of the conversion.
E.g., the red component ends up being 1.2 whereas the allowed range is [0..1]. If I multiply that by 255 I will obviously get a value that is invalid in the RGB world.
What is the correct way of handling this -- truncating (if > 1 then set to 1) or wrapping around (if > 1 then substract 1)?
It is not possible that the values R, G and B come out of their range if you have properly implemented standard algorithms and inputs are in their ranges.
What algorithms you've implemented?