I have the following Problem:
I want to check if a string is an 64 Bit Integer.
I can not use the [string is integer $str] method since it only works with 32 bit integers.
At http://wiki.tcl.tk/10166 I found the solution with [string is entier $str] but this does not work in tcl8.5 I get the following error message:
bad class "entier": must be alnum, alpha, ascii, control, boolean, digit, double, false, graph, integer, list, lower, print, punct, space, true, upper, wideinteger, wordchar, or xdigit
Does tcl8.5 not support this method?
And can I check for 64 bit Integers?
In Tcl 8.5, string is doesn't support the entier class (which checks for general integers — the name comes from French, and was picked because everything else better was taken for something else already). However, the wideinteger class is supported, and does exactly the check for a 64-bit integer on all supported platforms; plain old string is integer might really be 32-bit or 64-bit depending on the CPU architecture.
Don't forget to use -strict unless you want an empty string to be accepted as a valid value. (There are a few cases where that's desirable, but usually it isn't. It's a minor specification botch from years ago.)
Related
In Java architects of the language used prefixes like L/l for long numbers to make parsing easier and to differentiate Int vs Long constants. I am making a deserialisation library for TOML and received a request from the user not only to support easy-parsing to Long, but also to Int numbers depending on the string input.
So during the parsing I need to understand if the string in the input is Byte/Short/Int or Long and select a proper type automatically for an input.
This leads me to a question: is there any library in Kotlin (my library is MPP) that can help me to check if ? Like Math does it in Java. I am pretty sure that there should be some obvious library or algorithm for it, so I do not want to implement my yet another one.
If you will propose not a library, but a good algorithm for determine a type of an integer number by the string input - that will also be fine for me. But better it would be some known-algorithm.
We should not also forget about UNSIGNED int that are there in Kotlin but missing in Java
You can parse the positive part of an integer. If your integer is larger, than Int.MAX_VALUE it becomes negative. So when it becomes negative, you know there is an overflow.
Int.MAX_VALUE + 1 // produces a negative value
You can also try this library for parsing. https://github.com/tiksem/KotlinSpirit
val errorCode = int.compile().parseWithResult("3453534435543543345345").errorCode
errorCode will be ParseCode.INT_OUT_OF_BOUNDS
I want to show a 64-bit number as string. The problem is that my hardware doesn't support 64-bit number, just 32-bit.
So, I have the 64-bit number splitted into two 32-bit number (High and low part).
Example: 64-bit number : 12345678987654321 (002B DC54 6291 F4B1h)
32-bit low part: 1653732529 (6291 F4B1h)
32-bit high part: 2874452 (002B DC54h)
I think the solution to my problem would be showing this number as string.
It is possible?
Thanks.
yes you can use an array of 32 bit uints or even lower bit-width ...
for printing you can use this:
hex to dec
so first print a hex string which is easy on any bit-width (as you just stack up the lower bit-widths prints together from MSW to LSW) and then convert the hex text to dec text...
With this chained array of units you can do the math operations like this:
Cant make value propagate through carry
Doing operation on array of uints is much much more faster than on strings ...
but if you insist yes you can use string representation too ...
There are also hybrid representation like BCD that are suitable for this but your MCU would need to have support for it ...
Depending on your language of choice, the language may allow you to use greater-than-32bit integers, even on 32bits architectures (like python).
If that is the case the problem becomes trivial: compute the value, then compute the corresponding hex string.
I'm actually using a module from HP that get's the BIOS version of a system. It was easy to convert a string to an integer on some systems because it only had one decimal point. But now I'm running into some systems that has BIOS version with two decimal points and I can no longer use [int] or [decimal] or [double] etc..
So if I have string that has a value of "02.01.06" and I try to change that type to an integer, it fails to do so.
Example:
[int]$InstalledBiosVersion = Get-HPBiosVersion
Cannot convert value "02.01.06" to type "System.Int32". Error: "Input string was not in a correct format.
I need to change the string to an integer because I'm comparing bios versions that installed on the system(s) to what is the latest version available. So if one number is -lt the other, the bios is out of date.
Any ideas?
Never mind, I ended up just removing the two digits and the . and then converting it to a decimal.
[decimal]$InstalledBiosVersion = (Get-HPBiosVersion).Remove(0,4)
I have started to create XSD and found in couple of examples for xs:integer and xs:int.
What is the difference between xs:integer and xs:int?
When I should use xs:integer?
When I should use xs:int?
The difference is the following:
xs:int is a signed 32-bit integer.
xs:integer is an integer unbounded value.
See for details https://web.archive.org/web/20151117073716/http://www.w3schools.com/schema/schema_dtypes_numeric.asp
For example, XJC (Java) generates Integer for xs:int and BigInteger for xs:integer.
The bottom line: use xs:int if you want to work cross platforms and be sure that your numbers will pass without a problem.
If you want bigger numbers – use xs:long instead of xs:integer (it will be generated to Long).
The xs:integer type is a restriction of xs:decimal, with the fractionDigits facet set to zero and with a lexical space which forbids the decimal point and trailing zeroes which would otherwise be legal. It has no minimum or maximum value, though implementations running in machines of finite size are not required to be able to accept arbitrarily large or small values. (They are required to support values with 16 decimal digits.)
The xs:int type is a restriction of xs:long, with the maxInclusive facet set to 2147483647 and the minInclusive facet to -2147483648. (As you can see, it will fit conveniently into a two-complement 32-bit signed-integer field; xs:long fits in a 64-bit signed-integer field.)
The usual rule is: use the one that matches what you want to say. If the constraint on an element or attribute is that its value must be an integer, xs:integer says that concisely. If the constraint is that the value must be an integer that can be expressed with at most 32 bits in twos-complement representation, use xs:int. (A secondary but sometimes important concern is whether your tool chain works better with one than with the other. For data that will live longer than your tool chain, it's wise to listen to the data first; for data that exists solely to feed the tool chain, and which will be of no interest if you change your tool chain, there's no reason not to listen to the tool chain.)
I would just add a note of pedantry that may be important to some people: it's not correct to say that xs:int "is" a signed 32-bit integer. That form of words implies an implementation in memory (or registers, etc) within a binary digital computer. XML is character-based and would implement the maximum 32-bit signed value as "2147483647" (my quotes, of course), which is a lot more than 32 bits! What IS true is that xs:int is (indirectly) a restriction of xs:integer which sets the maximum and minimum allowed values to be the same as the corresponding implementation-imposed limits of a 32-bit integer with a sign bit.
We have an alpha numeric string (up to 32 characters) and we want to transform it to an integer (bigint). Now we're looking for an algorithm to do that. Collision isn't bad (therefor we use an bigint to prevent this a little bit), important thing is, that the calculated integers are constantly distributed over bigint range and the calculated integer is always the same for a given string.
This page has a few. You'll need to port to 64bit, but that should be trivial. A C# port of SBDM hash is here. Another page of hash functions here
Most programming languages come with a built-in construct or a standard library call to do this. Without knowing the language, I don't think anyone can help you.
Yes, a "hash" should be the right description for my problem. I know, that there is CRC32, but it only provides an 32-bit int (in PHP) and this 32-bit integers are at least 10 characters long, so a huge range of integer number is unused!?
Mostly, we have a short string like "PX38IEK" or an 36 character UUID like "24868d36-a150-11df-8882-d8d385ffc39c", so the strings are arbitrary, yes.
It doesn't has to be reversible (so collisions aren't bad). It also doesn't matter what int a string is converted to, my only wish is, that the full bigint range is used as best as possible.