I'm currently translating an application from actionscript-3 to Java code and got stuck with a variable assignment problem.
There is such block in as3 application:
var num:*=0;
...
num = 5.5;
As far as I understand AS3, variable is declared of an unknown type, which is resolved during the first assignment =0 meaning it will become int. Am I right?
So does that mean that by assigning 5.5 to it, the Number will be converted to int, and I will have num==5 in the result? Or will it become Number after assigning Number to it?
Thanks in advance.
Added:
Sorry, but I don't have any Flash environment to test it myself. I'm converting one of the utility methods from actionscript to Java and got stuck with this problem.
Added 2:
The question is, if num will contain 5 or 5.5 at the end of this block?
The standard datatypes for both integer and floating point data is Number. If you have 0 at the beginning, then it is a Number. Neither an int nor a double.
So, yes, the variable will contain 5.5 in the end.
Try tracing the number after second assignment, but I would guess that it will become Number.
Related
I want to perform an integer division in Octave (I'm using the latest version 5.1.0). I tired doing idivide(5, 2, "round") which should produce 3. The Documentation says for using idivide with round:
Calculate a ./ b with the fractional part rounded towards the nearest integer.
However, the result I get is 2.5000. What am I doing wrong?
Edit: sorry I used the wrong parameter when initially writing the question. Calling the function with fix works perfectly fine (e.g. idivide(5, 2, "fix") returns 2), I get the problem when using round.
Edit: The below is important for Matlab, in Octave the originally posed question (fix) gave the expected answer.
At least one of the input arguments must be an integer, hence this should work
idivide(5, int32(2), 'fix')
But be sure that this is what you want. idivide will return an integer class object which has various consequences if you aren't expecting it.
For example compare with an alternative solution which returns a double
idivide(5, int32(2), 'fix')*0.9
ans =
int32
2
fix(5/2)*0.9
ans =
1.8000
I have had to work in a project where we have an identifier in HEX.
Example, B900001752F10001, is received in a parser developed in JAVA in a SIGNED LONG variable. We store that variable in a SIGNED BIGINT variable in MySQL DB.
Every time we need the HEX Chain we use HEX(code) function and we get what is expected.
But when we have to provision the master table, we need to input valid codes, to achieve that we used something like:
Update employee set code=0xB900001752F10001 where main_employee_id=1002;
it worked in the past producing code to be stored in DB as
13330654997192441857
but now we are using the same exact instruction and we are getting code stored in DB as
-5116089076517109759
So Comparing those two numbers by using HEX function, those provide the same HEX NUMBER.
select HEX(-5116089076517109759), HEX(13330654997192441857)
0xB900001752F10001, 0xB900001752F10001
Could someone please provide ideas why this is happening? How we should handle this from the provisioning perspective we need to assure storing as 13330654997192441857 so when an authentication event happen codes match.
I have run without any other idea, I appreciate any help.
I think you have overflowed the datatype.
According to MySQL manual, signed bigint is in the range of
-9,223,372,036,854,775,808
to
9,223,372,036,854,775,807
Your number
18,446,744,073,709,551,615
has exceeded the above positive bound so it overflows and is
interpreted as a negative number.
Having that said, I think you may still be okay with your command -- it is only when you try to interpret the hex pattern as a number the result looks confusing.
Update employee set code=0xB900001752F10001 where main_employee_id=1002;
64bite machineļ¼top digit is sign bit,so the biggest num is 9,223,372,036,854,775,807,but if ur num more than it,the top digit will transform to be 1,so the num will be negative and its overflowed.
so ur 13330654997192441857 will become to 5116089076517109759.
I have this issue in converting a HEX string to Number in as3
I have a value
str = "24421bff100317"; decimal value = 10205787172373271
but when I parseInt it I get
parseInt(str, 16) = 10205787172373272
Can anyone please tell me what am I doing wrong here
Looks like adding one ("24421bff100318") works fine. I have to assume that means this is a case of precision error.
Because there are only a finite amount of numbers that can be represented with the memory available, there will be times that the computer is estimating. This is common when working with decimals and very large numbers. It's visible, for example, in this snippet where apparently the computer can't add basic decimals:
for(var i=0;i<3;i+=0.2){
trace(i);
}
There are a few workarounds if accuracy at this level is critical, namely using datatypes that store more information ("long" instead of "int" in Java - I believe "Number" might work in AS3 but I have not tested it for your scenario) or if that fails, breaking the numbers down into smaller parts and adding them together.
For further reading to understand this topic (since I do think it's fascinating), look up "precision errors" and "data types".
in xxxx.mxml (from flex) i have called the remote remote method (of java) the method return type is float
in the xxxx.mxml's remote objects result handler i need get the float values as Numeric.....or String..i tried with string...i did Alert.show to see the value some times i get exact value for eg, 0.5 is the value returning from java methid but here it will show 0.50000454...so on..how get the exact value?
It is because of the way floating point numbers are stored; basically they can't be stored precisely. A quick search in SO would reveal a lot of threads about this. Also read "What Every Computer Scientist Should Know About Floating-Point Arithmetic"
Thus the problem of getting the exact value boils down to what you define exact to be. Try rounding it to a given number of floating points at java end, convert the rounded number to a string (I'm not sure if this conversion would preserve the precision) and send that string.
It goes without saying that using hard-coded, hex literal pointers is a disaster:
int *i = 0xDEADBEEF;
// god knows if that location is available
However, what exactly is the danger in using hex literals as variable values?
int i = 0xDEADBEEF;
// what can go wrong?
If these values are indeed "dangerous" due to their use in various debugging scenarios, then this means that even if I do not use these literals, any program that during runtime happens to stumble upon one of these values might crash.
Anyone care to explain the real dangers of using hex literals?
Edit: just to clarify, I am not referring to the general use of constants in source code. I am specifically talking about debug-scenario issues that might come up to the use of hex values, with the specific example of 0xDEADBEEF.
There's no more danger in using a hex literal than any other kind of literal.
If your debugging session ends up executing data as code without you intending it to, you're in a world of pain anyway.
Of course, there's the normal "magic value" vs "well-named constant" code smell/cleanliness issue, but that's not really the sort of danger I think you're talking about.
With few exceptions, nothing is "constant".
We prefer to call them "slow variables" -- their value changes so slowly that we don't mind recompiling to change them.
However, we don't want to have many instances of 0x07 all through an application or a test script, where each instance has a different meaning.
We want to put a label on each constant that makes it totally unambiguous what it means.
if( x == 7 )
What does "7" mean in the above statement? Is it the same thing as
d = y / 7;
Is that the same meaning of "7"?
Test Cases are a slightly different problem. We don't need extensive, careful management of each instance of a numeric literal. Instead, we need documentation.
We can -- to an extent -- explain where "7" comes from by including a tiny bit of a hint in the code.
assertEquals( 7, someFunction(3,4), "Expected 7, see paragraph 7 of use case 7" );
A "constant" should be stated -- and named -- exactly once.
A "result" in a unit test isn't the same thing as a constant, and requires a little care in explaining where it came from.
A hex literal is no different than a decimal literal like 1. Any special significance of a value is due to the context of a particular program.
I believe the concern raised in the IP address formatting question earlier today was not related to the use of hex literals in general, but the specific use of 0xDEADBEEF. At least, that's the way I read it.
There is a concern with using 0xDEADBEEF in particular, though in my opinion it is a small one. The problem is that many debuggers and runtime systems have already co-opted this particular value as a marker value to indicate unallocated heap, bad pointers on the stack, etc.
I don't recall off the top of my head just which debugging and runtime systems use this particular value, but I have seen it used this way several times over the years. If you are debugging in one of these environments, the existence of the 0xDEADBEEF constant in your code will be indistinguishable from the values in unallocated RAM or whatever, so at best you will not have as useful RAM dumps, and at worst you will get warnings from the debugger.
Anyhow, that's what I think the original commenter meant when he told you it was bad for "use in various debugging scenarios."
There's no reason why you shouldn't assign 0xdeadbeef to a variable.
But woe betide the programmer who tries to assign decimal 3735928559, or octal 33653337357, or worst of all: binary 11011110101011011011111011101111.
Big Endian or Little Endian?
One danger is when constants are assigned to an array or structure with different sized members; the endian-ness of the compiler or machine (including JVM vs CLR) will affect the ordering of the bytes.
This issue is true of non-constant values, too, of course.
Here's an, admittedly contrived, example. What is the value of buffer[0] after the last line?
const int TEST[] = { 0x01BADA55, 0xDEADBEEF };
char buffer[BUFSZ];
memcpy( buffer, (void*)TEST, sizeof(TEST));
I don't see any problem with using it as a value. Its just a number after all.
There's no danger in using a hard-coded hex value for a pointer (like your first example) in the right context. In particular, when doing very low-level hardware development, this is the way you access memory-mapped registers. (Though it's best to give them names with a #define, for example.) But at the application level you shouldn't ever need to do an assignment like that.
I use CAFEBABE
I haven't seen it used by any debuggers before.
int *i = 0xDEADBEEF;
// god knows if that location is available
int i = 0xDEADBEEF;
// what can go wrong?
The danger that I see is the same in both cases: you've created a flag value that has no immediate context. There's nothing about i in either case that will let me know 100, 1000 or 10000 lines that there is a potentially critical flag value associated with it. What you've planted is a landmine bug that, if I don't remember to check for it in every possible use, I could be faced with a terrible debugging problem. Every use of i will now have to look like this:
if (i != 0xDEADBEEF) { // Curse the original designer to oblivion
// Actual useful work goes here
}
Repeat the above for all of the 7000 instances where you need to use i in your code.
Now, why is the above worse than this?
if (isIProperlyInitialized()) { // Which could just be a boolean
// Actual useful work goes here
}
At a minimum, I can spot several critical issues:
Spelling: I'm a terrible typist. How easily will you spot 0xDAEDBEEF in a code review? Or 0xDEADBEFF? On the other hand, I know that my compile will barf immediately on isIProperlyInitialised() (insert the obligatory s vs. z debate here).
Exposure of meaning. Rather than trying to hide your flags in the code, you've intentionally created a method that the rest of the code can see.
Opportunities for coupling. It's entirely possible that a pointer or reference is connected to a loosely defined cache. An initialization check could be overloaded to check first if the value is in cache, then to try to bring it back into cache and, if all that fails, return false.
In short, it's just as easy to write the code you really need as it is to create a mysterious magic value. The code-maintainer of the future (who quite likely will be you) will thank you.