Puzzled with VBA behavior: &H100 * &HBB generates an overflow error (Runtime Error '6' Overflow), while 16 ^ 2 * 187 does not. Suspect it's data-type coercion with the &H literal character; just was cleaner to read in the code using hex notation (color settings). Would like to understand what's behind it, if you can shed some light!!
MS Word VBA (VBA7) on 64-bit Office365 license.
It's because &H100 and &HBB default to Integer which cannot hold the expected result: 47872.
However, 16 ^ 2 defaults to Double and then 187 as well, and Double can easily hold 47872.
Convert to Long (or Currency or Decimal) when you expect larger integer results:
? CLng(&H100) * CLng(&HBB)
47872
Related
If I type for example Sqr(a ^ 2 + b ^ 2) there is no error. But when I type Sqr(a ^ 2 + b^ 2) it produces a compile error which I do not understand:
What is the function of ^ in VBA7 as opposed to _^ (underscore to show space) which denotes exponentiation?
This is a 64 bit issue.
^ can confuse the compiler as to whether an operator versus operand value as LongLong is being used.
This problem occurs because the circumflex character (^) is ambiguous in this context. For 64-bit versions of VBA, the circumflex has two meanings:
It can designate an exponent operation, such as x to the power of y ("x^y").
For 64-bit Office 2010 VBA editions only, it can designate that an operand value should be treated as a LongLong, 64-bit integer value data type (for example, "234^").
Consider the following scenario:
You have the 64-bit edition of Microsoft Office 2010 installed on your
computer. In the Visual Basic IDE, you create a new project.
In your Visual Basic for Applications (VBA) code, you type a statement
that resembles the following:
LongLongVar2 = LongLongVar1^IntegerVar
When you type x^y in the 64-bit Office 2010 VBA editions, the VBA IDE
editor does not know how to interpret the "x^" part of the string. In
this context, "x^" can be treated as being the LongLong data type. If
"x^" is interpreted in this manner, the string will produce an error
because there is no operator that is specified for the "y" value to
apply to the "x" value. If you type the string by using a space
between the value name and the circumflex (for example, x ^y), you
indicate that you intend the symbol to be an operator and not a data
type designator. By doing this, you can avoid the error condition.
Therefore, the example expression ... should be rewritten as follows:
LongLongVar2 = LongLongVar1 ^ IntegerVar
Using ^^ seems to still have some conflicts:
?(-1)^^2
"Compile Error: Expected: expression"
But I've found enclosing both terms in parentheses for ^ seems to work.
?(-1)^(2)
1
Same with variables:
foo = -1
bar = 2
?foo^^bar
"Compile Error: Type-declaration character does not match declared data type"
(foo)^(bar)
1
I need to Convert a string say '12/12/2013 14:30:56.583' to be converted in Date Format like 2013-12-12 14:30:56.583 in Informix database.
I Used following function
to_date('12/12/2013 14:30:56.583',"%d/%m/%Y %H:%M:%S.")
But its not accepting Milliseconds , Milliseconds are important to the resulting value.
The database version is important. The behaviour of %F was recently (11.70.xC8 and 12.10.xC2) changed. In previous versions the "." dot must probably be omitted as well as the "n" qualifier.
Regards
If you check the manual you will see is missing the milliseconds at the string format.
source: http://www-01.ibm.com/support/knowledgecenter/api/content/SSGU8G_12.1.0/com.ibm.sqls.doc/ids_sqs_1542.htm
%S Second as a 2-digit integer (00 through 61). The second value can
be up to 61 (instead of 59) to allow for the occasional leap second
and double leap second.
%Fn The value of the fraction of a second, with precision specified by
the unsigned integer n. The default value of n is 2; the range of n is
0 ≤ n ≤ 5. This value overrides any width or precision that is
specified between the % and F characters.
So, this probably will work:
to_date('12/12/2013 14:30:56.583',"%d/%m/%Y %H:%M:%S.%F3")
I’m not that familiar with Informix, but I think you may be able to use the standard to_date function to convert the string value to a date and then use an addMilliseconds function to add the milliseconds.
http://pic.dhe.ibm.com/infocenter/informix/v121/index.jsp?topic=%2Fcom.ibm.netpr.doc%2Fids_net_093.htm
How can I convert a char datatype into its utf-8 int representation in Processing?
So if I had an array ['a', 'b', 'c'] I'd like to obtain another array [61, 62, 63].
After my answer I figured out a much easier and more direct way of converting to the types of numbers you wanted. What you want for 'a' is 61 instead of 97 and so forth. That is not very hard seeing that 61 is the hexadecimal representation of the decimal 97. So all you need to do is feed your char into a specific method like so:
Integer.toHexString((int)'a');
If you have an array of chars like so:
char[] c = {'a', 'b', 'c', 'd'};
Then you can use the above thusly:
Integer.toHexString((int)c[0]);
and so on and so forth.
EDIT
As per v.k.'s example in the comments below, you can do the following in Processing:
char c = 'a';
The above will give you a hex representation of the character as a String.
// to save the hex representation as an int you need to parse it since hex() returns a String
int hexNum = PApplet.parseInt(hex(c));
// OR
int hexNum = int(c);
For the benefit of the OP and the commenter below. You will get 97 for 'a' even if you used my previous suggestion in the answer because 97 is the decimal representation of hexadecimal 61. Seeing that UTF-8 matches with the first 127 ASCII entries value for value, I don't see why one would expect anything different anyway. As for the UnsupportedEncodingException, a simple fix would be to wrap the statements in a try/catch block. However that is not necessary seeing that the above directly answers the question in a much simpler way.
what do you mean "utf-8 int"? UTF8 is a multi-byte encoding scheme for letters (technically, glyphs) represented as Unicode numbers. In your example you use trivial letters from the ASCII set, but that set has very little to do with a real unicode/utf8 question.
For simple letters, you can literally just int cast:
print((int)'a') -> 97
print((int)'A') -> 65
But you can't do that with characters outside the 16 bit char range. print((int)'二') works, (giving 20108, or 4E8C in hex) but print((int)'𠄢') will give a compile error because the character code for 𠄢 does not fit in 16 bits (it's supposed to be 131362, or 20122 in hex, which gets encoded as a three byte UTF-8 sequence 239+191+189)
So for Unicode characters with a code higher than 0xFFFF you can't use int casting, and you'll actually have to think hard about what you're decoding. If you want true Unicode point values, you'll have to literally decode the byte print, but the Processing IDE doesn't actually let you do that; it will tell you that "𠄢".length() is 1, when in real Java it's really actually 3. There is -in current Processing- no way to actually get the Unicode value for any character with a code higher than 0xFFFF.
update
Someone mentioned you actually wanted hex strings. If so, use the built in hex function.
println(hex((int)'a')) -> 00000061
and if you only want 2, 4, or 6 characters, just use substring:
println(hex((int)'a').substring(4)) -> 0061
I don't understand the next thing that happens using the sprintf command.
>> vpa(exp(1),53)
ans =
2.7182818284590455348848081484902650117874145507812500
>> e = 2.7182818284590455348848081484902650117874145507812500
e =
2.7183
>> sprintf('%0.53f', e)
ans =
2.71828182845904550000000000000000000000000000000000000
Why does sprintf show me the number e rounded instead of the number and I kept at the first place?
Variables are double precision by default in MATLAB, so the variable e that you create is limited to the precision of a double, which is about 16 digits. Even though you entered more digits, a double doesn't have the precision to accurately represent all those extra digits and rounds off to the nearest number it can represent.
EDIT: As explained in more detail by Andrew Janke in his answer to this follow-up question I posted, the number you chose for e just happens to be an exact decimal expansion of the binary value. In other words, it's the exactly-representable value that a nearby floating-point number would get rounded to. However, in this case anything more than approximately 16 digits past the decimal point is not considered significant since it can't really be represented accurately by a double-precision type. Therefore, functions like SPRINTF will automatically ignore these small values, printing zeroes instead.
Well, a simple question here
I am studying some assembly, and converting some assembly routines back to VB.NET
Now, There is a specific line of code I am having trouble with, in assembly, assume the following:
EBX = F0D04080
Then the following line gets executed
SHR EBX, 4
Which gives me the following:
EBX = 0F0D0408
Now, in VB.NET, i do the following
variable = variable >> 4
Which SHOULD give me the same... But it differs a SLIGHT bit, instead of the value 0F0D0408 I get FF0D0408
So what is happening here?
From the documentation of the >> operator:
In an arithmetic right shift, the bits shifted beyond the rightmost bit position are discarded, and the leftmost (sign) bit is propagated into the bit positions vacated at the left. This means that if pattern has a negative value, the vacated positions are set to one; otherwise they are set to zero.
If you are using a signed data type, F0B04080 has a negative sign (bit 1 at the start), which is copied to the vacated positions on the left.
This is not something specific to VB.NET, by the way: variable >> 4 is translated to the IL instruction shr, which is an "arithmetic shift" and preserves the sign, in contrast to the x86 assembly instruction SHR, which is an unsigned shift. To do an arithmetic shift in x86 assembler, SAR can be used.
To use an unsigned shift in VB.NET, you need to use an unsigned variable:
Dim variable As UInteger = &HF0D04080UI
The UI type character at the end of F0D04080 tells VB.NET that the literal is an unsigned integer (otherwise, it would be interpreted as a negative signed integer and the assignment would result in a compile-time error).
VB's >> operator does an arithmetic shift, which shifts in the sign bit rather than 0's.
variable = (variable >> shift_amt) And Not (Integer.MinValue >> (shift_amt - 1))
should give you an equivalent value, even if it is a bit long. Alternatively, you could use an unsigned integer (UInteger or UInt32), as there's no sign bit to shift.