parseInt returns undefined - facebook

Facebook's code changes on Tuesday night have impacted how parseInt works in FBJS. Where I previously used it to convert decimal numbers to straight integers, now it always returns undefined.
For example:
return parseInt(decimalnum);
no longer works. Anyone figured out how we are supposed to round to integers now? Thanks.

Thanks for the report. It's fixed on trunk now; it should be out tomorrow unless there's another push later today.

I suspect that decimalnum is not defined in your function. Try replacing your return with return decimalnum; -- you may still be returning undefined.
parseInt is not for rounding - it actually takes the integer component of a number, or coerces a string to be a number. If you want to round, use Math.round. Depending on your usage, you may find Math.floor or Math.ceil useful.
Math.floor()
Math.ceil()
Math.round()
parseInt()

Did you try parseInt(decimalnum, 10); ?

Related

Division between two integers returns .0 - Flutter

I state that I am new with Flutter.
I would like to do 50/2
I try with the DartPad
print((50/2).toString()); // return 25
I try the Flutter debugger build that I installed in a Pixel 4 emulator
print((50/2).toString()); // return 25.0
Why does the ".0" return?
Was I wrong to do something?
Is everything normal and is it kind of a code conversion?
How can I get it without ".0"?
ps. This is a case but I'm also talking about more complex situations where instead of doing a precise division, I could divide two variables (which maybe are not int but double) and / or do other operations. I've already evaluated things like toStringAsPrecision, it works for the single case but messes up the string if it contains true decimals.
ps2. The only solution that came to my mind is to replace the .toString with a custom extension method that eliminates superfluous zeroes (also considering the decimal point)
If you want to skip the .0 you should use truncating division a~/b. Answer is explained here : How to do Integer division in Dart?

Converting a UNIX timestamp into a Date object in Elm

As the title reads, how can I convert a UNIX timestamp, e.g. 1458297862, into a Date object in Elm?
Date.fromString does not seem to accept it, and Date.fromTime gives the wrong answer.
You can use Date.fromTime, but you have to multiply that value by 1000.
This gives you the date you'd expect:
Date.fromTime 1458297862000
I came across this answer and it didn't quite work in 0.18.
I found that Date.fromTime wouldn't accept arbitrary integers. The reason is that it's expecting floats, so you'd really want:
Date.fromTime (toFloat 1458297862000)

srandom(time(NULL)) giving warning - pointer to integer without a cast

In iPhone (Xcode 4), using the function,
srandom(time(NULL));
both srand and srandom is giving this warning. But when running its working fine.
Why I am getting the warning in one of my class file? I have used that in other files, but no warning.
Warning: passing argument 1 of 'srand' makes integer from pointer
without a cast
However, using arc4random() can solve this problem. But in most example srand() is used in this way and nobody complains. Thats why I am confused.
Because srand is expecting an integer and time() is returning a pointer (from the looks of your particular error). Casting explicitly to an int will make it go away. Or perhaps reading the pointer to get the actual time value might be what you are looking for instead. Not 100% certain of time's return value here, but I'd double check to make sure it is indeed returning a tics value instead of a pointer to a time_t object that will remain mostly the same over time.
According to what I just read, it's supposed to return a time_t value, which when cast as an int, is the number of seconds elapsed since 1972ish. So not a pointer usually, but in your case it may be. Either way, add either a dereference and a cast, or just a cast if you can get it to return the time_t directly.

Why is pow() reporting an infinite value in this case?

I am using the pow() function like this in my application:
float IValuePlusOne = (pow(2.25,120));
but it is reporting back an infinite value, instead of the correct result. I even tried the long long and long double data types but couldn't get them to produce the proper output.
Is there any other data type I need to use or do I need to make some other changes in my code?
As others have pointed out, you're losing precision and reducing the size of value you can represent by casting to a float. Running the following code:
double IValuePlusOne = pow(2.25,120.0);
NSLog(#"Test value: %f", IValuePlusOne);
on my iPhone gives the output:
Test value: 1827688475348373523156051712429585892114432.000000
which looks to be correct (1.827x10^42).
If you want to do calculations on values that a double can't hold, use NSDecimalNumber.

Ambiguity of function overloading - Integers vs. Doubles

Suppose I wish to have 2 functions, one that generates a random integer within a given range, and one that generates a random double within a given range.
int GetRandomNumber( int min, int max );
double GetRandomNumber( double min, double max );
Notice that the method names are the same. I'm trying to decide whether to name the functions that or...
int GetRandomInteger( int min, int max );
double GetRandomDouble( double min, double max );
The first option has the benefit of the user not having to worry about which one they are calling. They can just call GetRandomNumber with integers or doubles and get a result.
The second option is more explicit in the names, but it reveals unneeded information to the caller.
I know this is petty, but I care about petty things.
Edit: How would C++ behave regarding implicit conversion.
Example:
GetRandomNumber( 1, 1 );
This could be implicitly converted for the GetRandomNumber function for the double version. Obviously I don't want this to occur. Will C++ use the int version before the double version?
I prefer your second example, it is explicit and leaves no ambiguity in interpretation. It is better to err on the side of being explicit in method names to clearly illuminate the purpose and function of that member.
The only downside to your approach is that you have coupled the name of the method to the return type which is not ideal in the event that you want to change the return type of one of these methods. However in that case I would be better to add a new method and not break compatibility in your API anyways.
I prefer the second version. I like overloading a function when ultimately the two functions do the same thing; in this case they return different types so they're not quite the same thing. Another possibility if your language supports it is to define it as a generic/template method, like:
T GetRandom<T>(T min, T max);
A function name should tell what the function does; I do not see a point in cramming the types into the names. So definitely go for overloading - that's what it is for.
I prefer the overloaded method. Look at the Math.Min() method in .NET. It has 11 overloads: int, double, byte, etc.
I usually prefer the first example because it doesn't pollute the namespace. For example when calling it, if I pass ints, I'm expecting to get back an int. If I pass in doubles, I probably expect to get back a double. The compiler will give you an error if you write:
//this causes an error
double d = GetRandomNumber(1,10);
so it's not really a big issue. and you can always cast the arguments if you need an int but have doubles for input...
In some of languages you can not vary the return type of overloaded functions this would require the second example.
Assuming C++, the second also avoids problems with ambiguity. If you said:
GetRandomNumber( 1, 5.0 );
which one should be used? In fact, it is a compilation error.
I think the ideal solution would be
Int32.GetRandom(int min, int max)
Double.GetRandom(double min, double max)
but, alas, static extension method are not possible (yet?).
The .net Framwork seems to favor the first option (System.Math class):
public static decimal Abs(decimal value)
public static int Abs(int value)
Like Andrew, I would personally favor the second option to avoid ambiguity, although I do think this is a matter of taste.