BigInt implementation #81
@ -26,45 +26,256 @@ object KBigIntegerRing: Ring<KBigInteger> {
|
|||||||
|
|||||||
|
|
||||||
override fun multiply(a: KBigInteger, b: KBigInteger): KBigInteger = a.times(b)
|
override fun multiply(a: KBigInteger, b: KBigInteger): KBigInteger = a.times(b)
|
||||||
|
|
||||||
operator fun String.unaryPlus(): KBigInteger = KBigInteger(this)!!
|
operator fun String.unaryPlus(): KBigInteger = this.toKBigInteger()!!
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
operator fun String.unaryMinus(): KBigInteger = -KBigInteger(this)!!
|
operator fun String.unaryMinus(): KBigInteger = -this.toKBigInteger()!!
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
@kotlin.ExperimentalUnsignedTypes
|
@kotlin.ExperimentalUnsignedTypes
|
||||||
class KBigInteger(sign: Int = 0, magnitude: Magnitude = Magnitude(0)):
|
class KBigInteger internal constructor(
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
RingElement<KBigInteger, KBigInteger, KBigIntegerRing>, Comparable<KBigInteger> {
|
private val sign: Byte = 0,
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
private val magnitude: Magnitude = Magnitude(0)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
): Comparable<KBigInteger> {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
constructor(x: Int) : this(x.sign, uintArrayOf(kotlin.math.abs(x).toUInt()))
|
constructor(x: Int) : this(x.sign.toByte(), uintArrayOf(kotlin.math.abs(x).toUInt()))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
constructor(x: Long) : this(x.sign, uintArrayOf(
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
constructor(x: Long) : this(x.sign.toByte(), stripLeadingZeros(uintArrayOf(
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
(kotlin.math.abs(x).toULong() and BASE).toUInt(),
|
(kotlin.math.abs(x).toULong() and BASE).toUInt(),
|
||||||
((kotlin.math.abs(x).toULong() shr BASE_SIZE) and BASE).toUInt()))
|
((kotlin.math.abs(x).toULong() shr BASE_SIZE) and BASE).toUInt())))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
val magnitude = stripLeadingZeros(magnitude)
|
override fun compareTo(other: KBigInteger): Int {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val sign = if (this.magnitude.isNotEmpty()) sign else 0
|
return when {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val sizeByte: Int = magnitude.size * BASE_SIZE / 4
|
(this.sign == 0.toByte()) and (other.sign == 0.toByte()) -> 0
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
this.sign < other.sign -> -1
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
this.sign > other.sign -> 1
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
else -> this.sign * compareMagnitudes(this.magnitude, other.magnitude)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
override val context: KBigIntegerRing get() = KBigIntegerRing
|
override fun equals(other: Any?): Boolean {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (other is KBigInteger) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return this.compareTo(other) == 0
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
else error("Can't compare KBigInteger to a different type")
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
override fun unwrap(): KBigInteger = this
|
override fun hashCode(): Int {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
override fun KBigInteger.wrap(): KBigInteger = this
|
return magnitude.hashCode() + this.sign
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
fun abs(): KBigInteger = if (sign == 0.toByte()) this else KBigInteger(1, magnitude)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun unaryMinus(): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return if (this.sign == 0.toByte()) this else KBigInteger((-this.sign).toByte(), this.magnitude)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun plus(b: KBigInteger): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return when {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
b.sign == 0.toByte() -> this
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
this.sign == 0.toByte() -> b
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
this == -b -> ZERO
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
this.sign == b.sign -> KBigInteger(this.sign, addMagnitudes(this.magnitude, b.magnitude))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
else -> {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val comp: Int = compareMagnitudes(this.magnitude, b.magnitude)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (comp == 1) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
KBigInteger(this.sign, subtractMagnitudes(this.magnitude, b.magnitude))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
} else {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
KBigInteger((-this.sign).toByte(), subtractMagnitudes(b.magnitude, this.magnitude))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun minus(b: KBigInteger): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return this + (-b)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun times(b: KBigInteger): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return when {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
this.sign == 0.toByte() -> ZERO
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
b.sign == 0.toByte() -> ZERO
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
// TODO: Karatsuba
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
else -> KBigInteger((this.sign * b.sign).toByte(), multiplyMagnitudes(this.magnitude, b.magnitude))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun times(other: UInt): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return when {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
this.sign == 0.toByte() -> ZERO
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
other == 0U -> ZERO
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
else -> KBigInteger(this.sign, multiplyMagnitudeByUInt(this.magnitude, other))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun times(other: Int): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return if (other > 0)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
this * kotlin.math.abs(other).toUInt()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
else
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
-this * kotlin.math.abs(other).toUInt()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun div(other: UInt): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return KBigInteger(this.sign, divideMagnitudeByUInt(this.magnitude, other))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun div(other: Int): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return KBigInteger((this.sign * other.sign).toByte(),
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
divideMagnitudeByUInt(this.magnitude, kotlin.math.abs(other).toUInt()))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
private fun division(other: KBigInteger): Pair<KBigInteger, KBigInteger> {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
// Long division algorithm:
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
// https://en.wikipedia.org/wiki/Division_algorithm#Integer_division_(unsigned)_with_remainder
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
// TODO: Implement more effective algorithm
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
var q: KBigInteger = ZERO
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
var r: KBigInteger = ZERO
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val bitSize = (BASE_SIZE * (this.magnitude.size - 1) + log2(this.magnitude.last().toFloat() + 1)).toInt()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
for (i in bitSize downTo 0) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
r = r shl 1
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
r = r or ((abs(this) shr i) and ONE)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (r >= abs(other)) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
r -= abs(other)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
q += (ONE shl i)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return Pair(KBigInteger((this.sign * other.sign).toByte(), q.magnitude), r)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun div(other: KBigInteger): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return this.division(other).first
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
infix fun shl(i: Int): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (this == ZERO) return ZERO
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (i == 0) return this
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val fullShifts = i / BASE_SIZE + 1
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val relShift = i % BASE_SIZE
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val shiftLeft = {x: UInt -> if (relShift >= 32) 0U else x shl relShift}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val shiftRight = {x: UInt -> if (BASE_SIZE - relShift >= 32) 0U else x shr (BASE_SIZE - relShift)}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val newMagnitude: Magnitude = Magnitude(this.magnitude.size + fullShifts)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
for (j in this.magnitude.indices) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
newMagnitude[j + fullShifts - 1] = shiftLeft(this.magnitude[j])
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (j != 0) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
newMagnitude[j + fullShifts - 1] = newMagnitude[j + fullShifts - 1] or shiftRight(this.magnitude[j - 1])
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
newMagnitude[this.magnitude.size + fullShifts - 1] = shiftRight(this.magnitude.last())
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return KBigInteger(this.sign, stripLeadingZeros(newMagnitude))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
infix fun shr(i: Int): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (this == ZERO) return ZERO
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (i == 0) return this
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val fullShifts = i / BASE_SIZE
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val relShift = i % BASE_SIZE
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val shiftRight = {x: UInt -> if (relShift >= 32) 0U else x shr relShift}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val shiftLeft = {x: UInt -> if (BASE_SIZE - relShift >= 32) 0U else x shl (BASE_SIZE - relShift)}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (this.magnitude.size - fullShifts <= 0) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return ZERO
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val newMagnitude: Magnitude = Magnitude(this.magnitude.size - fullShifts)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
for (j in fullShifts until this.magnitude.size) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
newMagnitude[j - fullShifts] = shiftRight(this.magnitude[j])
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (j != this.magnitude.size - 1) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
newMagnitude[j - fullShifts] = newMagnitude[j - fullShifts] or shiftLeft(this.magnitude[j + 1])
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return KBigInteger(this.sign, stripLeadingZeros(newMagnitude))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
infix fun or(other: KBigInteger): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (this == ZERO) return other;
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (other == ZERO) return this;
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val resSize = max(this.magnitude.size, other.magnitude.size)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val newMagnitude: Magnitude = Magnitude(resSize)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
for (i in 0 until resSize) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (i < this.magnitude.size) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
newMagnitude[i] = newMagnitude[i] or this.magnitude[i]
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (i < other.magnitude.size) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
newMagnitude[i] = newMagnitude[i] or other.magnitude[i]
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return KBigInteger(1, stripLeadingZeros(newMagnitude))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
infix fun and(other: KBigInteger): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if ((this == ZERO) or (other == ZERO)) return ZERO;
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val resSize = min(this.magnitude.size, other.magnitude.size)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val newMagnitude: Magnitude = Magnitude(resSize)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
for (i in 0 until resSize) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
newMagnitude[i] = this.magnitude[i] and other.magnitude[i]
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return KBigInteger(1, stripLeadingZeros(newMagnitude))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun rem(other: Int): Int {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val res = this - (this / other) * other
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return if (res == ZERO) 0 else res.sign * res.magnitude[0].toInt()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
operator fun rem(other: KBigInteger): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return this - (this / other) * other
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
fun modPow(exponent: KBigInteger, m: KBigInteger): KBigInteger {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return when {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
exponent == ZERO -> ONE
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
exponent % 2 == 1 -> (this * modPow(exponent - ONE, m)) % m
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
else -> {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val sqRoot = modPow(exponent / 2, m)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
(sqRoot * sqRoot) % m
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
override fun toString(): String {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (this.sign == 0.toByte()) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return "0x0"
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
var res: String = if (this.sign == (-1).toByte()) "-0x" else "0x"
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
var numberStarted = false
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
for (i in this.magnitude.size - 1 downTo 0) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
for (j in BASE_SIZE / 4 - 1 downTo 0) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
val curByte = (this.magnitude[i] shr 4 * j) and 0xfU
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
if (numberStarted or (curByte != 0U)) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
numberStarted = true
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
res += hexMapping[curByte]
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
return res
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
companion object {
|
companion object {
|
||||||
val BASE = 0xffffffffUL
|
const val BASE = 0xffffffffUL
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
const val BASE_SIZE: Int = 32
|
const val BASE_SIZE: Int = 32
|
||||||
val ZERO: KBigInteger = KBigInteger()
|
val ZERO: KBigInteger = KBigInteger()
|
||||||
val ONE: KBigInteger = KBigInteger(1)
|
val ONE: KBigInteger = KBigInteger(1)
|
||||||
|
|
||||||
private val hexMapping: HashMap<UInt, String> =
|
private val hexMapping: HashMap<UInt, String> =
|
||||||
hashMapOf(
|
hashMapOf(
|
||||||
0U to "0", 1U to "1", 2U to "2", 3U to "3", 4U to "4", 5U to "5", 6U to "6", 7U to "7", 8U to "8",
|
0U to "0", 1U to "1", 2U to "2", 3U to "3",
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
9U to "9", 10U to "a", 11U to "b", 12U to "c", 13U to "d", 14U to "e", 15U to "f"
|
4U to "4", 5U to "5", 6U to "6", 7U to "7",
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
8U to "8", 9U to "9", 10U to "a", 11U to "b",
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
12U to "c", 13U to "d", 14U to "e", 15U to "f"
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
)
|
)
|
||||||
|
|
||||||
private fun stripLeadingZeros(mag: Magnitude): Magnitude {
|
internal fun stripLeadingZeros(mag: Magnitude): Magnitude {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
// TODO: optimize performance
|
if (mag.isEmpty() || mag.last() != 0U) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (mag.isEmpty()) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return mag
|
return mag
|
||||||
}
|
}
|
||||||
var resSize: Int = mag.size - 1
|
var resSize: Int = mag.size - 1
|
||||||
@ -108,7 +319,7 @@ class KBigInteger(sign: Int = 0, magnitude: Magnitude = Magnitude(0)):
|
|||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
carry = (res shr BASE_SIZE)
|
carry = (res shr BASE_SIZE)
|
||||||
}
|
}
|
||||||
result[resultLength - 1] = carry.toUInt()
|
result[resultLength - 1] = carry.toUInt()
|
||||||
return result
|
return stripLeadingZeros(result)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
}
|
||||||
|
|
||||||
private fun subtractMagnitudes(mag1: Magnitude, mag2: Magnitude): Magnitude {
|
private fun subtractMagnitudes(mag1: Magnitude, mag2: Magnitude): Magnitude {
|
||||||
@ -127,7 +338,7 @@ class KBigInteger(sign: Int = 0, magnitude: Magnitude = Magnitude(0)):
|
|||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
result[i] = res.toUInt()
|
result[i] = res.toUInt()
|
||||||
}
|
}
|
||||||
|
|
||||||
return result
|
return stripLeadingZeros(result)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
}
|
||||||
|
|
||||||
private fun multiplyMagnitudeByUInt(mag: Magnitude, x: UInt): Magnitude {
|
private fun multiplyMagnitudeByUInt(mag: Magnitude, x: UInt): Magnitude {
|
||||||
@ -142,7 +353,7 @@ class KBigInteger(sign: Int = 0, magnitude: Magnitude = Magnitude(0)):
|
|||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
}
|
||||||
result[resultLength - 1] = (carry and BASE).toUInt()
|
result[resultLength - 1] = (carry and BASE).toUInt()
|
||||||
|
|
||||||
return result
|
return stripLeadingZeros(result)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
}
|
||||||
|
|
||||||
private fun multiplyMagnitudes(mag1: Magnitude, mag2: Magnitude): Magnitude {
|
private fun multiplyMagnitudes(mag1: Magnitude, mag2: Magnitude): Magnitude {
|
||||||
@ -159,7 +370,7 @@ class KBigInteger(sign: Int = 0, magnitude: Magnitude = Magnitude(0)):
|
|||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
result[i + mag2.size] = (carry and BASE).toUInt()
|
result[i + mag2.size] = (carry and BASE).toUInt()
|
||||||
}
|
}
|
||||||
|
|
||||||
return result
|
return stripLeadingZeros(result)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
}
|
||||||
|
|
||||||
private fun divideMagnitudeByUInt(mag: Magnitude, x: UInt): Magnitude {
|
private fun divideMagnitudeByUInt(mag: Magnitude, x: UInt): Magnitude {
|
||||||
@ -172,230 +383,15 @@ class KBigInteger(sign: Int = 0, magnitude: Magnitude = Magnitude(0)):
|
|||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
result[i] = (cur / x).toUInt()
|
result[i] = (cur / x).toUInt()
|
||||||
carry = cur % x
|
carry = cur % x
|
||||||
}
|
}
|
||||||
return result
|
return stripLeadingZeros(result)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
}
|
||||||
|
|
||||||
}
|
}
|
||||||
|
|
||||||
override fun compareTo(other: KBigInteger): Int {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return when {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
(this.sign == 0) and (other.sign == 0) -> 0
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
this.sign < other.sign -> -1
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
this.sign > other.sign -> 1
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
else -> this.sign * compareMagnitudes(this.magnitude, other.magnitude)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
override fun equals(other: Any?): Boolean {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (other is KBigInteger) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return this.compareTo(other) == 0
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
else error("Can't compare KBigInteger to a different type")
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
override fun hashCode(): Int {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return magnitude.hashCode() + this.sign
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
operator fun unaryMinus(): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return if (this.sign == 0) this else KBigInteger(-this.sign, this.magnitude)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
override operator fun plus(b: KBigInteger): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return when {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
b.sign == 0 -> this
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
this.sign == 0 -> b
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
this == -b -> ZERO
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
this.sign == b.sign -> KBigInteger(this.sign, addMagnitudes(this.magnitude, b.magnitude))
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
else -> {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val comp: Int = compareMagnitudes(this.magnitude, b.magnitude)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (comp == 1) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
KBigInteger(this.sign, subtractMagnitudes(this.magnitude, b.magnitude))
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
} else {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
KBigInteger(-this.sign, subtractMagnitudes(b.magnitude, this.magnitude))
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
override operator fun minus(b: KBigInteger): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return this + (-b)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
override operator fun times(b: KBigInteger): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return when {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
this.sign == 0 -> ZERO
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
b.sign == 0 -> ZERO
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
// TODO: Karatsuba
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
else -> KBigInteger(this.sign * b.sign, multiplyMagnitudes(this.magnitude, b.magnitude))
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
operator fun times(other: UInt): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return when {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
this.sign == 0 -> ZERO
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
other == 0U -> ZERO
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
else -> KBigInteger(this.sign, multiplyMagnitudeByUInt(this.magnitude, other))
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
operator fun times(other: Int): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return if (other > 0)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
this * kotlin.math.abs(other).toUInt()
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
else
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
-this * kotlin.math.abs(other).toUInt()
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
operator fun div(other: UInt): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return KBigInteger(this.sign, divideMagnitudeByUInt(this.magnitude, other))
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
operator fun div(other: Int): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return KBigInteger(this.sign * other.sign, divideMagnitudeByUInt(this.magnitude, kotlin.math.abs(other).toUInt()))
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
private fun division(other: KBigInteger): Pair<KBigInteger, KBigInteger> {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
// Long division algorithm:
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
// https://en.wikipedia.org/wiki/Division_algorithm#Integer_division_(unsigned)_with_remainder
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
// TODO: Implement more effective algorithm
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
var q: KBigInteger = ZERO
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
var r: KBigInteger = ZERO
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val bitSize = (BASE_SIZE * (this.magnitude.size - 1) + log2(this.magnitude.last().toFloat() + 1)).toInt()
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
for (i in bitSize downTo 0) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
r = r shl 1
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
r = r or ((abs(this) shr i) and ONE)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (r >= abs(other)) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
r -= abs(other)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
q += (ONE shl i)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return Pair(KBigInteger(this.sign * other.sign, q.magnitude), r)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
operator fun div(other: KBigInteger): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return this.division(other).first
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
infix fun shl(i: Int): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (this == ZERO) return ZERO
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (i == 0) return this
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val fullShifts = i / BASE_SIZE + 1
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val relShift = i % BASE_SIZE
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val shiftLeft = {x: UInt -> if (relShift >= 32) 0U else x shl relShift}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val shiftRight = {x: UInt -> if (BASE_SIZE - relShift >= 32) 0U else x shr (BASE_SIZE - relShift)}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val newMagnitude: Magnitude = Magnitude(this.magnitude.size + fullShifts)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
for (j in this.magnitude.indices) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
newMagnitude[j + fullShifts - 1] = shiftLeft(this.magnitude[j])
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (j != 0) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
newMagnitude[j + fullShifts - 1] = newMagnitude[j + fullShifts - 1] or shiftRight(this.magnitude[j - 1])
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
newMagnitude[this.magnitude.size + fullShifts - 1] = shiftRight(this.magnitude.last())
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return KBigInteger(this.sign, newMagnitude)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
infix fun shr(i: Int): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (this == ZERO) return ZERO
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (i == 0) return this
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val fullShifts = i / BASE_SIZE
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val relShift = i % BASE_SIZE
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val shiftRight = {x: UInt -> if (relShift >= 32) 0U else x shr relShift}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val shiftLeft = {x: UInt -> if (BASE_SIZE - relShift >= 32) 0U else x shl (BASE_SIZE - relShift)}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (this.magnitude.size - fullShifts <= 0) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return ZERO
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val newMagnitude: Magnitude = Magnitude(this.magnitude.size - fullShifts)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
for (j in fullShifts until this.magnitude.size) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
newMagnitude[j - fullShifts] = shiftRight(this.magnitude[j])
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (j != this.magnitude.size - 1) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
newMagnitude[j - fullShifts] = newMagnitude[j - fullShifts] or shiftLeft(this.magnitude[j + 1])
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return KBigInteger(this.sign, newMagnitude)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
infix fun or(other: KBigInteger): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (this == ZERO) return other;
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (other == ZERO) return this;
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val resSize = max(this.magnitude.size, other.magnitude.size)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val newMagnitude: Magnitude = Magnitude(resSize)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
for (i in 0 until resSize) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (i < this.magnitude.size) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
newMagnitude[i] = newMagnitude[i] or this.magnitude[i]
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (i < other.magnitude.size) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
newMagnitude[i] = newMagnitude[i] or other.magnitude[i]
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return KBigInteger(1, newMagnitude)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
infix fun and(other: KBigInteger): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if ((this == ZERO) or (other == ZERO)) return ZERO;
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val resSize = min(this.magnitude.size, other.magnitude.size)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val newMagnitude: Magnitude = Magnitude(resSize)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
for (i in 0 until resSize) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
newMagnitude[i] = this.magnitude[i] and other.magnitude[i]
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return KBigInteger(1, newMagnitude)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
operator fun rem(other: Int): Int {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val res = this - (this / other) * other
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return if (res == ZERO) 0 else res.sign * res.magnitude[0].toInt()
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
operator fun rem(other: KBigInteger): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return this - (this / other) * other
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
fun modPow(exponent: KBigInteger, m: KBigInteger): KBigInteger {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return when {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
exponent == ZERO -> ONE
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
exponent % 2 == 1 -> (this * modPow(exponent - ONE, m)) % m
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
else -> {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val sqRoot = modPow(exponent / 2, m)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
(sqRoot * sqRoot) % m
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
override fun toString(): String {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (this.sign == 0) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return "0x0"
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
var res: String = if (this.sign == -1) "-0x" else "0x"
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
var numberStarted = false
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
for (i in this.magnitude.size - 1 downTo 0) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
for (j in BASE_SIZE / 4 - 1 downTo 0) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val curByte = (this.magnitude[i] shr 4 * j) and 0xfU
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
if (numberStarted or (curByte != 0U)) {
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
numberStarted = true
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
res += hexMapping[curByte]
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return res
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
}
|
||||||
|
|
||||||
@kotlin.ExperimentalUnsignedTypes
|
@kotlin.ExperimentalUnsignedTypes
|
||||||
fun abs(x: KBigInteger): KBigInteger {
|
fun abs(x: KBigInteger): KBigInteger = x.abs()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
return if (x.sign == 0) x else KBigInteger(1, x.magnitude)
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
@kotlin.ExperimentalUnsignedTypes
|
@kotlin.ExperimentalUnsignedTypes
|
||||||
// Can't put it as constructor in class due to platform declaration clash with KBigInteger(Int)
|
// Can't put it as constructor in class due to platform declaration clash with KBigInteger(Int)
|
||||||
@ -405,26 +401,35 @@ fun KBigInteger(x: UInt): KBigInteger
|
|||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
@kotlin.ExperimentalUnsignedTypes
|
@kotlin.ExperimentalUnsignedTypes
|
||||||
// Can't put it as constructor in class due to platform declaration clash with KBigInteger(Long)
|
// Can't put it as constructor in class due to platform declaration clash with KBigInteger(Long)
|
||||||
fun KBigInteger(x: ULong): KBigInteger
|
fun KBigInteger(x: ULong): KBigInteger
|
||||||
= KBigInteger(1, uintArrayOf((x and KBigInteger.BASE).toUInt(), ((x shr KBigInteger.BASE_SIZE) and KBigInteger.BASE).toUInt()))
|
= KBigInteger(1,
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
KBigInteger.stripLeadingZeros(uintArrayOf(
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
(x and KBigInteger.BASE).toUInt(),
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
((x shr KBigInteger.BASE_SIZE) and KBigInteger.BASE).toUInt())
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
val hexChToInt = hashMapOf('0' to 0, '1' to 1, '2' to 2, '3' to 3, '4' to 4, '5' to 5, '6' to 6, '7' to 7,
|
val hexChToInt = hashMapOf(
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
'8' to 8, '9' to 9, 'A' to 10, 'B' to 11, 'C' to 12, 'D' to 13, 'E' to 14, 'F' to 15)
|
'0' to 0, '1' to 1, '2' to 2, '3' to 3,
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
'4' to 4, '5' to 5, '6' to 6, '7' to 7,
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
'8' to 8, '9' to 9, 'A' to 10, 'B' to 11,
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
'C' to 12, 'D' to 13, 'E' to 14, 'F' to 15
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
|
||||||
// Returns None if a valid number can not be read from a string
|
// Returns None if a valid number can not be read from a string
|
||||||
fun KBigInteger(s: String): KBigInteger? {
|
fun String.toKBigInteger(): KBigInteger? {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
val sign: Int
|
val sign: Int
|
||||||
val sPositive: String
|
val sPositive: String
|
||||||
when {
|
when {
|
||||||
s[0] == '+' -> {
|
this[0] == '+' -> {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
sign = +1
|
sign = +1
|
||||||
sPositive = s.substring(1)
|
sPositive = this.substring(1)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
}
|
||||||
s[0] == '-' -> {
|
this[0] == '-' -> {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
sign = -1
|
sign = -1
|
||||||
sPositive = s.substring(1)
|
sPositive = this.substring(1)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
}
|
}
|
||||||
else -> {
|
else -> {
|
||||||
sPositive = s
|
sPositive = this
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
sign = +1
|
sign = +1
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
@ -485,13 +485,13 @@ class KBigIntegerConversionsTest {
|
|||||||
|
|
||||||
@Test
|
@Test
|
||||||
fun testFromString_0x17ead2ffffd11223344() {
|
fun testFromString_0x17ead2ffffd11223344() {
|
||||||
val x = KBigInteger("0x17ead2ffffd11223344")!!
|
val x = "0x17ead2ffffd11223344".toKBigInteger()
|
||||||
assertEquals( "0x17ead2ffffd11223344", x.toString())
|
assertEquals( "0x17ead2ffffd11223344", x.toString())
|
||||||
}
|
}
|
||||||
|
|
||||||
@Test
|
@Test
|
||||||
fun testFromString_7059135710711894913860() {
|
fun testFromString_7059135710711894913860() {
|
||||||
val x = KBigInteger("-7059135710711894913860")
|
val x = "-7059135710711894913860".toKBigInteger()
|
||||||
assertEquals("-0x17ead2ffffd11223344", x.toString())
|
assertEquals("-0x17ead2ffffd11223344", x.toString())
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
@ -509,7 +509,7 @@ class KBigIntegerRingTest {
|
|||||||
fun testKBigIntegerRingSum_100_000_000__100_000_000() {
|
fun testKBigIntegerRingSum_100_000_000__100_000_000() {
|
||||||
KBigIntegerRing {
|
KBigIntegerRing {
|
||||||
val sum = +"100_000_000" + +"100_000_000"
|
val sum = +"100_000_000" + +"100_000_000"
|
||||||
assertEquals(sum, KBigInteger("200_000_000"))
|
assertEquals(sum, "200_000_000".toKBigInteger())
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
@ -517,7 +517,7 @@ class KBigIntegerRingTest {
|
|||||||
fun test_mul_3__4() {
|
fun test_mul_3__4() {
|
||||||
KBigIntegerRing {
|
KBigIntegerRing {
|
||||||
val prod = +"0x3000_0000_0000" * +"0x4000_0000_0000_0000_0000"
|
val prod = +"0x3000_0000_0000" * +"0x4000_0000_0000_0000_0000"
|
||||||
assertEquals(prod, KBigInteger("0xc00_0000_0000_0000_0000_0000_0000_0000"))
|
assertEquals(prod, "0xc00_0000_0000_0000_0000_0000_0000_0000".toKBigInteger())
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
Why use whole
Int
for simple three way flag? Could it be replaced by boolean? Enum?Why use whole
Int
for simple three way flag? Could it be replaced by boolean? Enum?Move to private constructor and move parameter checks to auxiliary builders.
Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class
Companion should be last declaration in the class
Also all internal values must be marked as private
Also all internal values must be marked as private
should be virtual if it is not performance-critical
should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members.
It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger()
Refactor to String.toBigInteger()
Now using Byte for that
Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)