I am wondering if there is any way to represent infinity (or a sufficiently high number) in MS Excel.
I am particularly looking for something like Double.POSITIVE_INFINITY or Double.MAX_VALUE in Java.
I like to use 1e99 as it gives the largest number with the fewest keystrokes but I believe the absolute maximum is actually 9.99999E+307. At that stage of the number spectrum I don't think there is much difference as far as Excel is concerned.
I think it's worth adding that, Infinity as well as other special values can be returned from a vba function (How do you get VB6 to initialize doubles with +infinity, -infinity and NaN?):
Function Infinity(Optional Recalc) As Double
On Error Resume Next
Infinity = 1/0
End Function
When entered as a cell formula a large number is shown (2^1024). You can set a conditional format to show "+Infinity" as a number format with a formula condition:
=AND(ISNUMBER(A1),A1>2^1023*(2-2^-52))
A dummy argument containing a dynamic reference can be inserted so that values are recalculated when the workbook is opened, for example:
=Infinity(IF(,) IF(,))
With LibreOffice 6 I use 1.79769313486231E+308 that seems the largest number it allows me to enter, but I miss not having an exact representation of +- infinite, also because I suspect the number above is implementation specific...
This is an other point that makes me think that spreadsheets are great for visualising, editing and simple computations on tabular data, but for doing more complex operations/modelling a real programming language is a must...
Related
In Excel, I have two large columns of values that are usually identical in size and sequence. I want a hash for each column to check that the columns are in fact identical (with pretty good probability).
I have an MD5 hash algorithm which gives a has for a single string, but I want something for a large (about 20k) set of values). This would be slow.
I can use a simple function like this:
hash = mean + stdev + skewness
In VBA, this looks like:
Function hash(x As Range)
Application.Volatile
hash = Application.WorksheetFunction.StDev(x) + Application.WorksheetFunction.Skew(x) + Application.WorksheetFunction.Average(x)
End Function
and this gives me some confidence that the columns are the same in terms of magnitudes; but sometimes the values are identical but not in the correct order, and my hash cannot detect this. I need my hash to be able to detect wrong ordering.
I do not require 'anonymizing' or 'randomizing' of the data- there is no issue of privacy etc. In fact, a kind of 'proportional' hash that returns a small value for small errors and a large value for large errors would be extremely useful. Given that some rounding errors may result in small differences that I do not care about, the MD5 algorithm sometimes gives me false warnings.
Unfortunately the data is within excel (because it is the result of previous excel manipulations), and so a VBA function that would keep me in Excel, and allow me to proceed once the columns have been verified, would be best. So I'd like a function of the form
Of course, I could just compare the excel columns by making another column, and perform a large boolean AND (cellA1 =cellB1, cellA2=B2) etc. But this would be tedious and inefficient. I actually have thousands of these columns to compare in order to find bugs.
Any ideas?
The easiest way to compare two columns for near-equality is to use the worksheet function SUMXMY2(). This computes the squared-Euclidean distance between two ranges, thought of as vectors in higher-dimensional space. For example, to check if A1:A20000 is very close to B1:B20000, us the comparison
SUMXMY2(A1:A20000, B1:B20000) < tol
where tol is an error threshold which determines how much round-off error you are willing to tolerate.
Your original idea of using hashing could be useful in some circumstances. To make it tolerant of round-off error, look into the theory of Locality-sensitive hashing rather than cryptographical hashes such as MD5. Any such algorithm if implemented in VBA would be somewhat slow, but depending on what you are trying to do they could be useful.
I am working on a spreadsheet for a client that calculates values and shows them as fractions after a good amount of deductions. We were running some test after I had it all set and ready and they ran a certain number through the spread sheet. I'll try to beak it down as easily as possible (any value with brackets is user input. So Width is [94.5(94 1/2)] that number get subtracted by 7.5312(7 17/32 that equals 86.9688(86 31/32) that number is then divided by [3] which then equals 28.9896(28 95/96) This is where the problem is though. 95/96 is not a "real" fraction is there a way I can round numbers like this down to 64ths? They were expecting 63/64ths Even though the math is correct they need it to round down in those cases.
The If statement is this:
=IF(E4=1,(K4-F19)/1,IF(E4=2,(K4-G19)/2,IF(E4=3,(K4-H19)/3,IF(E4=4,(K4-I19)/4,IF(E4=5,(K4-J19)/5,IF(E4=6,(K4-K19)/6,IF(E4=7,(K4-L19)/7,IF(E4=8,(K4-M19)/8,IF(E4=9,(K4-N19)/9,IF(E4=10,(K4-O19)/10,0))))))))))
This is a single part of the IF statement:
=IF(E4=1,(K4-F19)/1
Is there a way around this or are they SOL(Sorta Outta Luck)?
Thanks for any insight.
Assuming in A1, please try:
=ROUNDDOWN(A1*64,0)/64
with suitable formatting.
This ensures that all results are multiples of 1/64.
I wrote a user-defined function for fractions to be displayed with superscripted & subscripted digits (available in Unicode), with denominator no more than the user wants to. I could basically turn π into ²²/₇ with "=Fraction(PI(),30)", since no other fraction would be closer to π with a denominator smaller than or equal to 30.
Then I'm thinking of writing an InvFraction function as well, to get from a string generated by the Fraction function into an actual number. As you can imagine, though, the value is not π anymore, but 3.142857... (i.e. ²²/₇). So I'm postponing the writing until I remove that sense of chasing a ghost I'm feeling about it.
I saw that one could make the Fraction function generate a size-2 array of values, then through the index function, let the user decide which one to display, or enter the Fraction function as an array function covering 2 cells. Neither one is ideal from my perspective, the first option because the second value, which could be π, gets lost through the index choice and is no longer retrievable, the second option because it forces two cells to contain the data (though I guess I COULD end up living with it).
I also thought of using user-defined types containing the string value for the fraction and the double value for the original input, but I noticed they don't work in the actual sheet, then informally confirmed the info there: Call VBA function that returns custom type from spreadsheet
Anyone would have any idea at how to tackle this? Thanks anyways for having taken the time to read.
Edit: To put it simply, if I were to program the InvFraction function as I conceived it with the tools and ideas I have, I could only manage to have “=InvFraction(Fraction(PI(),30))” to equal 3.142857... (22 divided by 7), but I would rather like it to generate 3.14159265... (π).
To make the sale to my customer I need to import numbers from a report into an Excel document. For example the number coming in will be 14.182392. The only reason for my guy not to buy the product is because he only wants to view 14.182 on the Excel sheet. Okay so the other catch is, the number CANNOT be rounded in any shape or form.
So what I need is a way to just show so much of number, WITHOUT ROUNDING.
Is this possible? Any ideas of how I could get around this would be fantastic.
Please try:
=TEXT(INT(A1)+VALUE(LEFT(MOD(A1,1),5)),"00.000")
Firstly =TRUNC is a better answer (much shorter). My version was connected with uncertainty in your requirement (it is odd!) and in the hope it might be easier to adjust if not exactly what you/your boss wanted.
TRUNC literally just truncates the decimals (no rounding!) to a length to suit (ie 3 if to show nn.182 given nn.182392 or say nn.182999).
LEFT may also be a better choice, but that depends upon knowing how large the integer part of your number is. =LEFT(A1,6) would display 14.189 given say 14.189999 in A1. However it would show 1.4189 given 1.4189999 in A1 (ie four decimal places).
The formula above combines text manipulation with number manipulation.:
INT takes just the integer value (here 14.)
MOD takes just the modulus – the residual that is not an integer after division, in this case by 1. So just the .182392 part. LEFT is then applied here in a similar way to as used above, but without needing to concern oneself with the length of the integer part of the source value (ie 14 or 1 etc does not matter).
VALUE then converts the result back into numeric format (string manipulation functions such as LEFT always return text format) so our abbreviated decimal string can then be added to our integer.
Finally, the TEXT part is for formatting but is hard or impossible to justify! About the only use is that it displays the result left-justified in the cell – perhaps a little warning that the number displayed is not the “true” value (eg it won’t SUM) because, as a result of a formula, it won’t be marked with a little green warning triangle.
The displayed values can use the TRUNC function like this,
=TRUNC(A1, 3)
But you must use A1 in any calculations to retain the precision of the raw value.
Easiest way I know:
=LEFT(A1; x)
where x = the amount of characters You want. Mind that the dot counts as a character as well.
I am having problems with the CountIf Function in Excel.
=COUNTIF(A:A,A2)
The A column consists of these items:
0107791489614255200011140926107503100513
0107791489614255200011140926107503100457
0107791489614255200011140926107503100518
0107791489614255200011140926107503100503
0107791489614255200011140926107503100519
0107791489614255200011140926107503100444
0107791489614255200011140926107503100521
0107791489614255200011140926107503100438
0107791489614255200011140926107503100449
0107791489614255200011140926107503100443
0107791489614255200011140926107503100501
0107791489614255200011140926107503100455
the formula results to 12, even though these set of strings are not really the same at all. It counts these strings as similar strings, I am thinking this is related to its string length?
What do you guys think? I appreciate your help.
+1, A good question. Not really a bug but a feature!
This is due to Excel implicitly converting the inputs to its internal numeric type and losing precision in doing so. Excel's internal numeric type is an IEEE floating point double precision number. (Although it does clever things with formatting and error propagation so it appears to get sums like 1/3 + 1/3 + 1/3 correct).
As they are so similar they all compare as mutually equal.
One remedy would be to prefix each string with ' (single quotation) which will prevent the conversion to the numeric type. Then the COUNTIF value returns 1. (At least in my version of Excel; 2013).
Preceding the strings with a single apostrophe will not remedy the situation. COUNTIF is designed to interpret data as numerical, where possible, irrespective of the datatype of the values in question. This is sometimes helpful, sometimes (as here) not.
SUMPRODUCT does not exhibit this property:
=SUMPRODUCT(0+($A$1:$A$12=A2))
will return 1, as desired.
Regards