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..)
Related
I am trying to increase the size of checkbox in MS Access and I know that the default checkbox size cannot be increased.
However, I tried to achieve this by creating an input box and following what is listed here:
http://allenbrowne.com/ser-52.html
I am confused about this step:
Hold down the Alt key, and type 0168 on the numeric keypad (the character for False)
Holding alt key and typing that does not give me a "X" in report view. It gives a very small question mark.
Can I no longer use the method described in the blog above to create a bigger checkbox?
Technique from that blog is simply setting format on a numeric value where character shown depends on whether number is positive or negative. First position is for positive number and second position is for negative. Since True is -1 in a Yes/No field, second position character will be displayed.
If Alt+ is too difficult or other symbols are preferred, another way to get special characters is to copy/paste from Windows Character Map utility.
Instead of using Wingdings font to display symbols, can show alpha characters by setting Format property of textbox with:
To show Y or N: \N;\Y
To show X or nothing: ;\X
Same result can be achieved with an IIf() conditional expression in textbox ControlSource or query calculated field. Difference is the calculated result is the alpha character whereas setting format property does not alter what is actually in the field/textbox.
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.
EDIT: The chart is fixed when I use a stacked chart instead of a stacked percentage chart, but this still doesn't tell me what is wrong with using the percentage chart.
I have a stacked percentage chart which is going from 0 to 10000% instead of 0 to 100%. It appears as if the values are formatted correctly (they add up to 1.01 due to rounding), and even dividing all the values by 100 in the query does not change it.
This is how the chart renders:
with the following Vertical Axis Properties:
I have a table below (with identical number formatting but with 2 percentage points), however that displays as expected:
Finally, here is the raw data set with an additional sum column not reflected in SSRS:
Has anyone come across this issue before? If I manually set the range of the chart from 0-100% (0-1) I can only see that bottom blue series.
Yep. I've seen exactly this. The numbers that the percent chart axis generates are in the range 0 to 100. But when you apply the number formatting as a percent, then the numbers are multiplied by 100 for display.
The trick to fix/work around this is to set the display format to only add the percent sign, not really format the number as a percent. Happily, this requires just one character:
In the Number format for the axis, switch the Category to "Custom." If you just switched from Percentage, you will see something similar to 0%.
Insert a backslash before the percent symbol: 0\% to indicate that you need a literal percent symbol, not to format the number as a percent (multiplied by 100.)
Voila.
I am having a problem with getting a stacked area chart to display the right data in SSRS 2005.
On my Y axis, I want a scale from 50% to 100%.
On my X axis I have a set of dates formatted in a style that was necessary for the report (so varchar).
My data consists of 3 data fields which are decimal numbers and contained between 0 and 1, each with a specific date.
My problem is the scale of the Y-axis. I have set the maximum value to 100, the minimum to 50, the interval to 5, and the format to "p" for percentages.
On the preview in the layout tab, this all appears fine (Y-axis starting at 50% up to 100%).
However whenever I generate an actual report it goes from 5000% to 10000% for some reason. I have no idea how this is happening and it completely ruins the report.
I have tried tinkering in the properties for several hours but to no avail.
If this has happened to anyone and they have found a solution, or if anyone has any suggestions I would be very grateful.
Thanks.
When you use percentages, everything factors by 100.
If you want to format and display a value as 50% , it needs to be 0.5 unformatted. Percentages are therefore values between 0 and 1.
Excel and pretty much every other tool works that way.
If your values are all stored as percentages already, then you might just want to append the % symbol at the end of your values. Or better, divide everything by 100.
50 per cent means just that anyway; it means 50 per hundred (cent means 100) so 50/100 is another way of writing 50%.
I'm trying to diagnose and fix a bug which boils down to X/Y yielding an unstable result when X and Y are small:
In this case, both cx and patharea increase smoothly. Their ratio is a smooth asymptote at high numbers, but erratic for "small" numbers. The obvious first thought is that we're reaching the limit of floating point accuracy, but the actual numbers themselves are nowhere near it. ActionScript "Number" types are IEE 754 double-precision floats, so should have 15 decimal digits of precision (if I read it right).
Some typical values of the denominator (patharea):
0.0000000002119123
0.0000000002137313
0.0000000002137313
0.0000000002155502
0.0000000002182787
0.0000000002200977
0.0000000002210072
And the numerator (cx):
0.0000000922932995
0.0000000930474444
0.0000000930582124
0.0000000938123574
0.0000000950458711
0.0000000958000159
0.0000000962901528
0.0000000970442977
0.0000000977984426
Each of these increases monotonically, but the ratio is chaotic as seen above.
At larger numbers it settles down to a smooth hyperbola.
So, my question: what's the correct way to deal with very small numbers when you need to divide one by another?
I thought of multiplying numerator and/or denominator by 1000 in advance, but couldn't quite work it out.
The actual code in question is the recalculate() function here. It computes the centroid of a polygon, but when the polygon is tiny, the centroid jumps erratically around the place, and can end up a long distance from the polygon. The data series above are the result of moving one node of the polygon in a consistent direction (by hand, which is why it's not perfectly smooth).
This is Adobe Flex 4.5.
I believe the problem most likely is caused by the following line in your code:
sc = (lx*latp-lon*ly)*paint.map.scalefactor;
If your polygon is very small, then lx and lon are almost the same, as are ly and latp. They are both very large compared to the result, so you are subtracting two numbers that are almost equal.
To get around this, we can make use of the fact that:
x1*y2-x2*y1 = (x2+(x1-x2))*y2 - x2*(y2+(y1-y2))
= x2*y2 + (x1-x2)*y2 - x2*y2 - x2*(y2-y1)
= (x1-x2)*y2 - x2*(y2-y1)
So, try this:
dlon = lx - lon
dlat = ly - latp
sc = (dlon*latp-lon*dlat)*paint.map.scalefactor;
The value is mathematically the same, but the terms are an order of magnitude smaller, so the error should be an order of magnitude smaller as well.
Jeffrey Sax has correctly identified the basic issue - loss of precision from combining terms that are (much) larger than the final result.
The suggested rewriting eliminates part of the problem - apparently sufficient for the actual case, given the happy response.
You may find, however, that if the polygon becomes again (much) smaller and/or farther away from the origin, inaccuracy will show up again. In the rewritten formula the terms are still quite a bit larger than their difference.
Furthermore, there's another 'combining-large&comparable-numbers-with-different-signs'-issue in the algorithm. The various 'sc' values in subsequent cycles of the iteration over the edges of the polygon effectively combine into a final number that is (much) smaller than the individual sc(i) are. (if you have a convex polygon you will find that there is one contiguous sequence of positive values, and one contiguous sequence of negative values, in non-convex polygons the negatives and positives may be intertwined).
What the algorithm is doing, effectively, is computing the area of the polygon by adding areas of triangles spanned by the edges and the origin, where some of the terms are negative (whenever an edge is traversed clockwise, viewing it from the origin) and some positive (anti-clockwise walk over the edge).
You get rid of ALL the loss-of-precision issues by defining the origin at one of the polygon's corners, say (lx,ly) and then adding the triangle-surfaces spanned by the edges and that corner (so: transforming lon to (lon-lx) and latp to (latp-ly) - with the additional bonus that you need to process two triangles less, because obviously the edges that link to the chosen origin-corner yield zero surfaces.
For the area-part that's all. For the centroid-part, you will of course have to "transform back" the result to the original frame, i.e. adding (lx,ly) at the end.