I have an array of decimal values like 0.0047, -45.34 etc. Is there a way I can add this in verilog and automatically view it's 16 bit converted value?
You can use 'real' but you can not synthesize it. You have to find a binary representation for your numbers either floating point or fixed point. You have to define a range for your numbers and also a precision as binary representation of real number is often an approximation.
I did some calculations. You have a positive and negative number so you need a sign bit. Leaves 15 bits for the values. You want to have at least 45, that requires 6 bits. leaves 9 bits for the fraction. The closest you can get to 0.0047 is then 0.0046875. Your range is then -63.998 .... +63.998
Related
We have some weird calculation scenario in Microsoft excel, this simple addition operation resulting 1 at 13 decimal digit whereby it should be zero
But when i extract the value in formula the result is correct (both formula value is the same but the result is different)
From human understanding addition calculation will reduce the decimal digit rather than add it.
Is this by design or bugs ?
I strongly guess that this is a gap from the limited precision of floating point numbers. Accuracy of digital numbers is limited. Numbers in excel are saved in binary format(but displayed in decimal format). This means that the "0" is not as protected as in the decimal system. Usually Excel tries to cover this up for examples like yours.
Also, if your numbers derive from complex calculations (e.g. square-roots), the accuracy can be limited as most functions use approximation with limited iterations to give a result.
You can find more information about floating point arithmetic here. The blog is about pythin but the way it works is similar.
https://docs.python.org/3/tutorial/floatingpoint.html
How does excel determine what to number to display? specifically the number of decimal places
for example:
50.98, when stored as a single-precision float is 50.979999542236328125
50.979999 is also stored as the exact same single-precision float
(binary rep. 01000010010010111110101110000101, taken from here: https://www.h-schmidt.net/FloatConverter/IEEE754.html)
when i type 50.98 & 50.979999 into 2 cells, change format to number, and extend out the decimal places using the formatting button
it represents them exactly as 50.98 & 50.979999, as i originally typed.
how is that working? is excel storing the exact text i typed and not (directly) storing the float data type at all?
if it stores it as a double, how does it preserve the exact precision i originally typed in that case?
i can't find documentation outlining how this works.
Note its not causing me any problems, i just need an explanation for differences in how excel displays vs calculations based on those values.
it represents them exactly as 50.98 & 50.979999, as i originally typed.
Excel is padding with zeros after 15 significant decimal digits.
The internal number is encoded with a high enough binary precision such that limiting output to 15 deimcal places, the original typed in decimal values appear to be exactly that.
=2/3 is an informative example showing this limit and exposing the binary internals by carefully extracting out a bit at a time.
As displayed in one cell, decimal output rounds to 15 places, padding with zero after that.
0.66666666666666700000000
The below does a binary conversion of =2/3 and forms 0.101010101010101010101010101010101010101010101010101012, exactly what is expected if Excel used a binary64. (Below)
OP's observations are consistent with using binary64 and rounding output as decimal text to 15 significant digits.
Cell A3: =FLOOR(B2*A$1,1), Cell B3 = =B2*A$1 - A3
Hypothesis: When displaying a number, Excel first converts a number to a decimal numeral with at most 15 significant digits even if more are requested. If additional digits are requested, they are filled in as zeros. (In addition, Excel may apply other alterations depending on context.)
In Microsoft Excel 2008 for Mac, I entered =1+22*POWER(2,-52) in A1 and =1+23*POWER(2,-52) in A2. Using IEEE-754 binary64, these should generate the numbers 1.000000000000004884981308350688777863979339599609375 and 1.0000000000000051070259132757200859487056732177734375. Entering =A1-1 and =A2-1 in B1 and B2 and setting these to Number format with 30 decimal places shows “0.000000000000004884981308350690” and “0.000000000000005107025913275720”, which is consistent with IEEE-754 binary64. So we have some assurance the numbers above were indeed generated and stored in Excel.
Setting A1 and A2 to Number format with 20 decimal places shows “1.00000000000000000000” and “1.00000000000001000000”.
Clearly, if Excel were displaying the actual numbers with 20 decimal places, it would show “1.000000000000004885” and “1.000000000000005107”. It does not. The display we see is consistent with converting the numbers using 15 decimal digits (significant digits, not just those after the decimal point) and then padding with zeros.
Converting 50.98 to the IEEE-754 binary64 format yields 50.97999999999999687361196265555918216705322265625. Displaying this with 15 decimal digits yields 50.9800000000000.
how to generate auto number from 0,000000000000000000000000000001 till 0,999999999999999999999999999999 at excel and the format cell is number ?
i've tried for dragging mouse , but i guess thats so terrible
You're out of luck.
Excel uses a 64 bit double precision IEEE754 floating point type for numbers (along with some clever rounding tricks). That gives you 53 bits of precision which loosely translates to 15 decimal significant figures of accuracy.
You will not be able to descriminate between numbers with such a small interval between them, if the total range is between 0 and 1.
(There's also the small matter of there not being enough space in a workbook to represent all those numbers.)
I need to convert floats into numbers that resemble measurements from a ruler. For example: 3.75 needs to be converted into 3 and 3/4. However, this is harder than it would seem at first, because I need to keep the denominator in a form that is easily translated into a ruler measurement by a human. Essentially, the denominator should only be powers of 2, up to 16. I don't want a fraction like 3/5 because 5'ths aren't marked on a ruler. I have figured out how to limit the denominator from going above 16, but I can't figure out how to keep the denominator a power of 2.
Answers in python or c++ is preferred.
extract integer part, so you have fraction part less than 1.
find nearest 16th of fraction: multiply by 16 and round to nearest integer. Have some policy to break ties (e.g. round to even). I believe this step can't introduce floating point arithmetic error because you are multiplying by a power of 2.
reduce n/16 to lowest terms (cancel out common multiples of 2). I guess you need to compute the greatest common divisor. In Python that's fractions.gcd, dunno about C++.
I did what Jhecht said because it seemed easy to do with python dictionary.
input a
88888888
99999999
end
export excel a.xlsx, replace
Then, if I open the excel file, the numbers are shown as 8.89e+07 and 1.00e+08. How can I restore these to the original numbers. Do I have to do this in Excel? Is there any way to prevent Stata from converting those numbers to the "scientific" format?
The effect of your input command is to read those numbers into variables of float type. But there aren't enough bits in a float to hold 99999999 exactly. This is well documented.
See e.g. the help for data types:
"floats have about 7 digits of accuracy; the magnitude of the number does not matter. Thus, 1234567 can be stored perfectly as a float, as can 1234567e+20. The number 123456789, however, would be rounded to 123456792. In general, this rounding does not matter.
If you are storing identification numbers, the rounding could matter. If the
identification numbers are integers and take 9 digits or less, store them as longs;
otherwise, store them as doubles. doubles have 16 digits of accuracy."
So you degraded your data by using an inappropriate data type. That is the issue, not export excel.