I'm using TryStrToFloat to convert string to Double variables. Everything works fine until string doesn't looks like '21e'. I get result of conversion 21.
It seems to me that compiler treats '21e' like number 21e0. String 21e1 gives result 210.
When I use Val function conversion works better. String '21e' gives error, but now '21e1' gives 210, '21e-1' gives number 2,1 etc.
How to make correct working of conversion. Should I detect letter 'e' in text, or is any simply way to convert ?
The documentation says:
Use TryStrToFloat to convert a string, S, to a floating-point value. S must consist of an optional sign (+ or -), a string of digits with an optional decimal point, and an optional mantissa. The mantissa consists of 'E' or 'e' followed by an optional sign (+ or -) and a whole number. Leading and trailing blanks are ignored.
Your input does not satisfy the conditions and so should be treated as an error.
You did not say so explicitly, but I presume that you claim that:
TryStrToFloat('21e', val)
returns True. If so, this is a bug and should be reported to Embarcadero. If you need to work around this then I suggest you code your own function that detects this case and handles it correctly.
On the other hand, if that function call returns False the function is behaving as designed and your mistake is to read the value in val.
Update
I can confirm that TryStrToFloat('21e', val) returns True. I tested on XE7 update 1. I submitted the following bug report to Embarcadero: https://quality.embarcadero.com/browse/RSP-9814
Related
I'm importing some JSON files into my Parse.com project, and I keep getting the error "invalid key:value pair".
It states that there is an unexpected "8".
Here's an example of my JSON:
}
"Manufacturer":"Manufacturer",
"Model":"THIS IS A STRING",
"Description":"",
"ItemNumber":"Number12345",
"UPC":083456789012,
"Cost":"$0.00",
"DealerPrice":" $0.00 ",
"MSRP":" $0.00 ",
}
If I update the JSON by either removing the 0 from "UPC":083456789012, or converting it to "UPC":"083456789012", it becomes valid.
Can JSON really not accept an integer that begins with 0, or is there a way around the problem?
A leading 0 indicates an octal number in JavaScript. An octal number cannot contain an 8; therefore, that number is invalid.
Moreover, JSON doesn't (officially) support octal numbers, so formally the JSON is invalid, even if the number would not contain an 8. Some parsers do support it though, which may lead to some confusion. Other parsers will recognize it as an invalid sequence and will throw an error, although the exact explanation they give may differ.
Solution: If you have a number, don't ever store it with leading zeroes. If you have a value that needs to have a leading zero, don't treat it as a number, but as a string. Store it with quotes around it.
In this case, you've got a UPC which needs to be 12 digits long and may contain leading zeroes. I think the best way to store it is as a string.
It is debatable, though. If you treat it as a barcode, seeing the leading 0 as an integral part of it, then string makes sense. Other types of barcodes can even contain alphabetic characters.
On the other hand. A UPC is a number, and the fact that it's left-padded with zeroes to 12 digits could be seen as a display property. Actually, if you left-pad it to 13 digits by adding an extra 0, you've got an EAN code, because EAN is a superset of UPC.
If you have a monetary amount, you might display it as € 7.30, while you store it as 7.3, so it could also make sense to store a product code as a number.
But that decision is up to you. I can only advice you to use a string, which is my personal preference for these codes, and if you choose a number, then you'll have to remove the 0 to make it work.
One of the more confusing parts of JavaScript is that if a number starts with a 0 that isn't immediately followed by a ., it represents an octal, not a decimal.
JSON borrows from JavaScript syntax but avoids confusing features, so simply bans numbers with leading zeros (unless then are followed by a .) outright.
Even if this wasn't the case, there would be no reason to expect the 0 to still be in the number when it was parsed since 02 and 2 are just difference representations of the same number (if you force decimal).
If the leading zero is important to your data, then you probably have a string and not a number.
"UPC":"083456789012"
A product code is an identifier, not something you do maths with. It should be a string.
Formally, it is because JSON uses DecimalIntegerLiteral in its JSONNumber production:
JSONNumber ::
-_opt DecimalIntegerLiteral JSONFraction_opt ExponentPart_opt
And DecimalIntegerLiteral may only start with 0 if it is 0:
DecimalIntegerLiteral ::
0
NonZeroDigit DecimalDigits_opt
The rationale behind is is probably:
In the JSON Grammar - to reuse constructs from the main ECMAScript grammar.
In the main ECMAScript grammar - to make it easier to distinguish DecimalIntegerLiteral from HexIntegerLiteral and OctalIntegerLiteral. OctalIntegerLiteral in the first place.
See this productions:
HexIntegerLiteral ::
0x HexDigit
0X HexDigit
HexIntegerLiteral HexDigit
...
OctalIntegerLiteral ::
0 OctalDigit
OctalIntegerLiteral OctalDigit
The UPC should be in string format. For the future you may also get other type of UPC such as GS128 or string based product identification codes. Set your DB column to be string.
If an integer start with 0 in JavaScript it is considered to be the Octal (base 8) value of the integer instead of the decimal (base 10) value. For example:
var a = 065; //Octal Value
var b = 53; //Decimal Value
a == b; //true
I think the easiest way to send your number by JSON is send your number as string.
I would like to ask something about data types in Lua.
I get from serial link some message (command:value) like this:
tmp_string = "BRAKE:1"
then I parse this string to command and value in two different functions (one is for command and other one is for value). This is function for parsing value
function parser(value)
index = string.find(value, ":")
result = value.sub(value, index+1)
return result
end
I would like to now what sort of data type result is? If I use string match it works.
...if string.match(state, "1") then...
However it also works when I do something like this
x = (state*65536)/3.2808)
I thought the result is string, but I don't understand why it works also with numerical operations. Thank you in advance.
Lua 5.3 Reference Manual, §3.4.1 - Arithmetic Operators
With the exception of exponentiation and float division, the arithmetic operators work as follows: If both operands are integers, the operation is performed over integers and the result is an integer. Otherwise, if both operands are numbers or strings that can be converted to numbers (see §3.4.3), then they are converted to floats, the operation is performed following the usual rules for floating-point arithmetic (usually the IEEE 754 standard), and the result is a float.
Emphasis is mine.
When dealing with operations, Lua will attempt to convert string operands to floats, and if it works - it works. If it fails, you get an error.
>| '55' / 2
<| 27.5
>| 'foo' / 2
<| error: [string "return 'foo' / 2"]:1: attempt to perform arithmetic on a string value
If you want to be explicit about this (and safe) use tonumber, and handle the nil-case.
If you need to know the type of a value in Lua, you can pass the variable to type and check the resulting string.
so basically I have some input possibilities for the user where should only numbers be accepted, otherwise the user will be alerted his input was incorrect.
the input is considered a String when I read it out using a callback.
now I want to check whether the string(which SHOULD contain numbers) actually DOES ONLY contain numbers, but I didnt find a solution implemented already.
i tried
theString isInteger
-is never true for the string
theString asNumber
- ignores letters, but I want to have a clear output wether letters are included in the string or not
theString isNumber
- always false
In Squeak and Pharo, you have the message #isAllDigits that does exactly what you want:
'1233248539487523' isAllDigits "--> true"
You can use a regular expression to check that the string contains only numbers:
theString matchesRegex: '\d+'
or a more complex regular expression to also allow an optional sign and decimal point:
theString matchesRegex: '-?\\d+(\\.\\d+)?'
Unfortunately, I could not locate messages 'isAllDigits' or 'matchesRegex'on Cincom Smalltalk.
However, what you could do is extract a word from the string and convert it to a number using asNumber.
So, if the returned value is 0(zero) it means that either the number is actually a 0(which could e checked with an additional condition) or string did not contain a digit/number.
This should work with many Smalltalks dialects:
(aString detect: [:c| c isDigit not ]) isNil ifTrue: [ "it's a number" ].
When the actual data type of a variable will be decided?
For ex:
x=10 here x will hold integer
x="Hello" here x will hold string
My basic question is msgbox "2"+"3" is 23 because these are strings and + is for concatenation so the result is 23
Then how the result of msgbox "2"*"3" becomes 6? where the string will be converted to integers and returns 6
If you are talking about using Visual Basic (you have not specified a language) then here is what I believe is happening:
The MsgBox function is expecting a and Object to turn into a String. (or at least it is trying to convert a String before it is displayed). Since "+" is a legit operator for concatenation, the first example can be directly converted to a String and returned.
In the second example, the asterisk is not a legit String operator, so it then has to attempt to convert your String segments into Integers. It does, then multiplies them, then the MsgBox converts the numerical expression back into a String and displays it.
I've a question about Fortran 77 and I've not been able to find a solution.
I'm trying to store an array of strings defined as the following:
character matname(255)*255
Which is an array of 255 strings of length 255.
Later I read the list of names from a file and I set the content of the array like this:
matname(matcount) = mname
EDIT: Actually mname value is hardcoded as mname = 'AIR' of type character*255, it is a parameter of a function matadd() which executes the previous line. But this is only for testing, in the future it will be read from a file.
Later on I want to print it with:
write(*,*) matname(matidx)
But it seems to print all the 255 characters, it prints the string I assigned and a lot of garbage.
So that is my question, how can I know the length of the string stored?
Should I have another array with all the lengths?
And how can I know the length of the string read?
Thanks.
You can use this function to get the length (without blank tail)
integer function strlen(st)
integer i
character st*(*)
i = len(st)
do while (st(i:i) .eq. ' ')
i = i - 1
enddo
strlen = i
return
end
Got from here: http://www.ibiblio.org/pub/languages/fortran/ch2-13.html
PS: When you say: matname(matidx) it gets the whole string(256) chars... so that is your string plus blanks or garbage
The function Timotei posted will give you the length of the string as long as the part of the string you are interested in only contains spaces, which, if you are assigning the values in the program should be true as FORTRAN is supposed to initialize the variables to be empty and for characters that means a space.
However, if you are reading in from a file you might pick up other control characters at the end of the lines (particularly carriage return and/or line feed characters, \r and/or \n depending on your OS). You should also toss those out in the function to get the correct string length. Otherwise you could get some funny print statements as those characters are printed as well.
Here is my version of the function that checks for alternate white space characters at the end besides spaces.
function strlen(st)
integer i,strlen
character st*(*)
i = len(st)
do while ((st(i:i).eq.' ').or.(st(i:i).eq.'\r').or.
+ (st(i:i).eq.'\n').or.(st(i:i).eq.'\t'))
i = i - 1
enddo
strlen = i
return
end
If there are other characters in the "garbage" section this still won't work completely.
Assuming that it does work for your data, however, you can then change your write statement to look like this:
write(*,*) matname(matidx)(1:strlen(matname(matidx)))
and it will print out just the actual string.
As to whether or not you should use another array to hold the lengths of the string, that is up to you. the strlen() function is O(n) whereas looking up the length in a table is O(1). If you find yourself computing the lengths of these static strings often, it may improve performance to compute the length once when they are read in, store them in an array and look them up if you need them. However, if you don't notice the slowdown, I wouldn't worry about it.
Depending on the compiler that you are using, you may be able to use the trim() intrinsic function to remove any leading/trailing spaces from a string, then process it as you normally would, i.e.
character(len=25) :: my_string
my_string = 'AIR'
write (*,*) ':', trim(my_string), ':'
should print :AIR:.
Edit:
Better yet, it looks like there is a len_trim() function that returns the length of a string after it has been trimmed.
intel and Compaq Visual Fortran have the intrinsic function LEN_TRIM(STRING) which returns the length without trailing blanks or spaces.
If you want to suppress leading blanks or spaces, use "Adjust Left" i.e. ADJUSTF(STRING)
In these FORTRANs I also note a useful feature: If you pass a string in to a function or subroutine as an argument, and inside the subroutine it is declared as CHARACTER*(*), then
using the LEN(STRING) function in the subroutine retruns the actual string length passed in, and not the length of the string as declared in the calling program.
Example:
CHARACTER*1000 STRING
.
.
CALL SUBNAM(STRING(1:72)
SUBROUTINE SYBNAM(STRING)
CHARACTER*(*) STRING
LEN(STRING) will be 72, not 1000