I have a problem with following statement
trace(Number("1/2")) //output NaN
but
trace(Number("1.2")) //output 1.2
So, I am bit confused as why the first statement doesn't gives correct result?
It probably expects the value to be a number already, not a calculation. Try to parse this string: "1+2". It'll most likely result in NaN as well.
Edit: I've run a test
Number("1.2") = 1.2
Number("1+2") = NaN
Number("1/2") = NaN
So, as I said, the Number() constructor expects a number, not a calculation.
You can convert strings that are made up of numerical characters into actual Number data using the Number(). The way it works is that you pass the String value to the Number(), and in turn, this will create a Number version of the String that was passed to it.
trace(Number("1")/Number("2")); // Output 0.5
NaN is the output because you are trying to convert the String data to be used as Number data.
You have to trace like this because "/" operator is not a number.
You can only multiply or divide numbers, NOT strings. So in the act of trying to divide String data, we are implicitly coercing the values to change into Number data. We can't do that. We should explicitly convert the String data to Number data first, and then perform the arithmetic operation.
By enclosing the value inside quotation parks you are making it an explicit string.
It's like asking what is the number value of the word "this".
Not sure if this helps but remove the quotation marks and it makes sense.
trace(Number(1/2)); //output 0.5
Related
I want filter on integer array in postgresql but when I am executing below query its giving me malformed array literal error.
select * from querytesting where 1111111111 = any((jsondoc->>'PhoneNumber')::integer[]);
Open image for reference-
https://i.stack.imgur.com/Py3Z2.png
any(x) wants a PostgreSQL array as x. (jsondoc->>'PhoneNumber'), however, is giving you a text representation of a JSON array. A PostgreSQL array would look like this as text:
'{1,2,3}'
but the JSON version you get from ->> would look like:
'[1,2,3]'
You can't mix the two types of array.
You could use a JSON operator instead:
jsondoc->'PhoneNumber' #> 1111111111::text::jsonb
Using -> instead of ->> gives you a JSON array rather than text. Then you can see if the number you're looking for is in that array with #>. The double cast (::text::jsonb) is needed to convert the PostgreSQL number to a JSON number for the #> operator.
As an aside, storing phone numbers as numbers might not be the best idea. You don't do arithmetic on phone numbers so they're not really numbers at all, they're really strings that contain digit characters. Normalizing the phone number format to international standards and then treating them as strings will probably serve you better in the long term.
In chilkat activeX (my version: 9.5.0.86), when I create object with numeric property .emit() method returns JSON string with number where decimal part is separated with comma. This depends on my regional settings
here in Control panel. But this shouldn't be dependent on this, because this JSON RFC: https://www.ietf.org/rfc/rfc4627.txt says that numbers must always be separated by dot.
This code (in VFP)
oJson = CreateObject('Chilkat_9_5_0.JsonObject')
oJson.AddNumberAt(-1,"test1", 12.3)
?oJson.Emit()
when I have set comma in settings, output of this code is:
{"test1":12,3}
and when I have set dot, output is:
{"test1":12.3}
Is there a way how to setup chilkat, to always get numbers with dot?
It seems, that problem is with method AddNumberAt, because when I get json with load method
The 2nd argument to UpdateNumber should be a string.
See https://chilkatsoft.com/refdoc/xChilkatJsonObjectRef.html#method81
You passed a floating point number, which was coerced into a string by your programming language, and the coercion is what caused the comma to be used.
I have some code in json to get data from domoticz.
local Data = parsedJson["result"][1]["Data"]
print("Data:", Data)
The outcome;
2.700 kWh
How to get rid of the kWh ?
So the outcome will be 2.700
You can write a regular expression which accepts numbers and . only.
Not sure but you could try to cast the variable to float and it will preserve only the number with floating point
I have to read a file using octave which has the following format
0 0.232 0.565
2 0.232 name1
1 0.2314 0.2546
3 0.2455
4 0.2544 name2
Essentially the third column can be an string or a float while the first column is an integer and the second column is a float.
I have found a similar question here which requires me to install a package. I want to avoid installing new packages. Is there any solution using built-in functions ?
Yes, you can read it as string, and then convert it using the str2double function. If it is not a number, it will return NaN. However, you could not store numbers and strings in the same vector as they are not the same type.
A possible solution is to split the last vector in two new vectors, one containing strings, in which you set empty string where there was a number; the other vector containing the numbers, and zero or NaN where there was a string.
Reference : str2double
I'm trying to understand a simple basic concept regarding JSON strings. I'm running a simple test that looks like this:
$(document).ready(function() {
var last = 9;
var json1 = $.parseJSON('{"id":"10"}');
var json2 = $.parseJSON('{"id":10}');
if(json1.id > last)
alert("json1.id is greater than last");
if(json2.id > last)
alert("json2.id is greater than last");
});
Since the variable "last" is type int I'm trying to make a comparison between it and the "id" from two different JSON strings. json1 denotes the ten value as a string, whereas json2 denotes it as an integer value. When this is run, both alerts are executed. I did not expect that. I expected that the second alert would execute, but not the first one since ten is presented as a string.
I believe that the correct way to format an integer value in JSON is in json2, right?
Why is the first test executing the alert?
I'm trying to troubleshoot a larger project and thought the problem might be in the way the JSON string is formatted.
The documentation of Javascript's operators holds all the answers:
Strings are compared based on standard lexicographical ordering, using
Unicode values. In most cases, if the two operands are not of the same
type, JavaScript attempts to convert them to an appropriate type for
the comparison. This behavior generally results in comparing the
operands numerically. The sole exceptions to type conversion within
comparisons involve the === and !== operators, which perform strict
equality and inequality comparisons. These operators do not attempt to
convert the operands to compatible types before checking equality.
Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Expressions_and_Operators#Comparison_operators