integer

问题 I am new to scala and I am finding the need to convert a boolean value to an integer. I know i can use something like if (x) 1 else 0 but I would like to know if there is a preferred method, or something built into the framework (ie toInt() ) 回答1: If you want to mix Boolean and Int operation use an implicit as above but without creating a class: implicit def bool2int(b:Boolean) = if (b) 1 else 0 scala> false:Int res4: Int = 0 scala> true:Int res5: Int = 1 scala> val b=true b: Boolean = true

问题 I checked the document that long = int64 has range more than 900,000,000,000,000 Here is my code: int r = 99; long test1 = r*r*r*r*r; at runtime it gives me 919,965,907 instead of the correct 9,509,900,499. another test long test2 = 99*99*99*99*99; It refuses to compile, saying integer overflow. But if i do this long test3 = 10100200300; This works fine. 回答1: The problem is that the literal "99" is being treated as an int. If you add "L" it will treat it as a long. To fix your compilation

问题 I'd like to divide two Int values in Haskell and obtain the result as a Float . I tried doing it like this: foo :: Int -> Int -> Float foo a b = fromRational $ a % b but GHC (version 6.12.1) tells me "Couldn't match expected type 'Integer' against inferred type 'Int'" regarding the a in the expression. I understand why: the fromRational call requires (%) to produce a Ratio Integer , so the operands need to be of type Integer rather than Int . But the values I'm dividing are nowhere near the

问题 I know that I can use Fixnum#to_s to represent integers as strings in binary format. However 1.to_s(2) produces 1 and I want it to produce 00000001 . How can I make all the returned strings have zeros as a fill up to the 8 character? I could use something like: binary = "#{'0' * (8 - (1.to_s(2)).size)}#{1.to_s(2)}" if (1.to_s(2)).size < 8 but that doesn't seem very elegant. 回答1: Use string format. "%08b" % 1 # => "00000001" 回答2: Using String#rjust: 1.to_s(2).rjust(8, '0') => "00000001" 回答3:

问题 I want to store a 64bit (8 byte) big integer to a nodejs buffer object in big endian format. The problem about this task is that nodejs buffer only supports writing 32bit integers as maximum (with buf.write32UInt32BE(value, offset)). So I thought, why can't we just split the 64bit integer? var buf = new Buffer(8); buf.fill(0) // clear all bytes of the buffer console.log(buf); // outputs <Buffer 00 00 00 00 00 00 00 00> var int = 0xffff; // as dezimal: 65535 buf.write32UInt32BE(0xff, 4); //

问题 how does one write a hexadecimal integer literal that is equal to Int.MIN_VALUE (which is -2147483648 in decimal) in Kotlin? AFAIK, an Int is 4 bytes...and sometimes it seems like 2's complement is used to represent integers...but I'm not sure. I've tried the following hex literals to help myself understand the system: 0xFFFFFFFF but this is a Long , not an Int 0xFFFFFFFF.toInt() which is -1 -0xFFFFFFFF.toInt() which is 1 0x7FFFFFFF which is 2147483647 which is Int.MAX_VALUE -0x7FFFFFFF which

问题 This question already has answers here : What is the difference between conversion specifiers %i and %d in formatted IO functions (*printf / *scanf) (4 answers) Closed 6 years ago . OK I was looking into number formatting and I found that you could use %d or %i to format an integer. For example: number = 8 print "your number is %i." % number or number = 8 print "your number is %d." % number But what is the difference? I mean i found something but it was total jibberish. Anyone speak Mild-Code

问题 The compiler complains about this code: HashMap<String,int> userName2ind = new HashMap<String,int>(); for (int i=0; i<=players.length; i++) { userName2ind.put(orderedUserNames[i],i+1); } It writes "unexpected type" and point on int . If I replace int by String and i+1 by i+"1" , the compilation goes OK. What is wrong with in here? 回答1: It's fine with Integer , but not okay with int - Java generics only work with reference types, basically :( Try this - although be aware it will box everything

问题 while ((1U << i) < nSize) { i++; } Any particular reason to use 1U instead of 1 ? 回答1: On most compliers, both will give a result with the same representation. However, according to the C specification, the result of a bit shift operation on a signed argument gives implementation-defined results, so in theory 1U << i is more portable than 1 << i . In practice all C compilers you'll ever encounter treat signed left shifts the same as unsigned left shifts. The other reason is that if nSize is

问题 In redis, The range of values supported by HINCRBY is limited to 64 bit signed integers. And I'd like to know how big can that 64 bit signed integer be. 回答1: This article is good for more information about this topic: http://en.wikipedia.org/wiki/Integer_(computer_science) So the answer to the question should be: From -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807, or from −(2^63) to 2^63 − 1 The highest positive number stored in a signed int is represented binary as ----- 63 ones --