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?
Related
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..)
In Microsoft Access 2013, I have 2 textboxes on a form containing Currency format and 2 decimals that I compare.
For example: $25,100.50
If the numbers are visually identical, I expect the comparison box to turn green. If they are visually different, I expect the comparison box to turn red. However, the box often turns red even though the number is visually identical. Obviously, it is comparing the rolled up decimals. If I make sure the format is currency, and the decimal places are the same, shouldn't that take care of it? How can I tweak this so that it works every time?
Instead of having the conditional formatting expression
Textbox1 = Textbox2
Use
Format(Textbox1,"Currency") = Format(Textbox2, "Currency")
I have a bar chart that show the count of number of models for each agency,
The problem is that I have a large difference between the values that makes the report to look not so good.
Does anyone have any ideas of a good way to resolve this problem?
Have you considered using a logarithmic scale?
With your chart Right-click the y-axis, and click Vertical Axis Properties.
In Axis Options, select Use logarithmic scale.
Leave the Log base text box as 10 (this is the scale most commonly used by logarithmic charts)
This will display a chart with a scale that goes up by a factor of 10 for each ‘unit’ up, so the distance between 1 and 10 is the same as that between 100 and 1000.
For example the shown dataset is displayed as this chart when using the logarithmic scale
This method is a simple and recognised way to clearly show values of widely different scales.
Update
If want an indicative bar for the vales that are 1 then you could use the expression
=iif(Fields!val.Value = 1, Fields!val.Value * 1.1, Fields!val.Value)
To make all values that are 1 equal to 1.1 so showing a tiny bar appearing a the bottom of the chart, as seen here
Unfortunately I don't know of a way to change that first 1 to a zero (formatting-wise). This is partly because you are now using a logarithmic scale and zero and negative values don't really exist. This is due to a fundamental property of logarithms in mathematics, that
LOG10(10)= 1
LOG10(1) = 0
LOG10(.1)=-1
Therefore, when you perform a log10 of zero, it just doesn't exist.
When we use RGBA in Html we use sth like this.
<div style="Background: rgba (x, x, x, 0.dd)">Some Content</div>
How many decimals can you go in the dd(opacity). Is it browser dependent? Or are its limits specified in HTML standards?
The specification says it is a <number> which is defined as:
zero or more digits followed by a dot (.) followed by one or more digits
So there is no limit specified in the CSS spec.
I'd be surprised if any human eye could distinguish beyond two decimal places though.
The value can be any number between 0.0 and 1.0.
The resolution depends on the color space resolution which typically is 8-bit (future may offer higher resolutions such as 10- and 12-bit, although I doubt that will happen anytime soon, but that is why a fraction is used instead of a byte value).
The value is multiplied with the byte value so it is limited what numbers you want to use and the final value is rounded to closest integer value:
Internal byte value = round(alpha * 255);
(or an increment of 1 / 256 = 0.00390625)
to give you actual change of the final byte value and the visual appearance (assuming solid background).
I made a small script here which gives you the result from using various numbers of decimals in the fraction value - as you can see when you are at 3 decimals the values start to be similar and therefor not so useful.
ONLINE GENERATED TABLES HERE
The loop to generate the table looks like this in general:
for (; i < 1; i += 0.1) {
num = Math.round(i * 255, 10);
...
}
The opacity property has a value set to two decimals.
All current browsers recognize this, the context is a little different for IE8 and below.
Let's say I have this glutIdleFunc going in the background of an OpenGL scene containing a little creature with multiple, radially arranged legs that "pulsate":
void PulsateLegs(void)
{
lowerLegsRot = (lowerLegsRot + 1)%360;
glutPostRedisplay();
}
...where the lowerLegsRot value is used like this in the display function:
glRotatef((GLfloat)lowerLegsRot, 1.0, 0.0, 0.0);
It's hard to visualize without seeing what the little fellow actually looks like, but it's clear that this function is making the legs spin all the way around repeatedly. I want to limit this spin to a certain range (say, -15 to 50 degrees), and, furthermore, to make the legs go back and forth within the range, like a pendulum.
Since I'm going for a 65 degree swath, I tried just changing "%360" to "%65" as a first step. But this made the legs go way too fast, and I cannot use a lower increment value if I want to use modulus, which only works on ints.
Is there another way to achieve the desired first-step behavior? More importantly, how can I make the legs go back and forth? It's kind of hard to conceptualize with a function that is getting called multiple times (vs. just using a loop structure that takes care of everything, which I tried before I realized this!)
and I cannot use a lower increment value if I want to use modulus, which only works on ints.
The % operator is broken anyway. You should not use integers, but floats, and use the fmod (double) or fmodf (float) function.